Docker v29, and the fall-out

5 min read
December 21, 2025
December 22, 2025
Last updated:
December 22, 2025
Neil Cresswell
Neil Cresswell
,
Portainer CEO
Follow on LinkedIn
Table of Contents

Share this post
This is some text inside of a div block.

Key takeaways

When Docker Engine v29 landed, it raised the minimum supported API version to 1.44. That single change broke a massive chunk of the Docker ecosystem, including ours.

Older versions of Portainer (anything before 2.33.5) were hardcoded to use API versions up to 1.41. Docker 29 rejected those connections outright. Environments wouldn't load, requests failed, and unless users were watching logs closely, it looked like everything just stopped working. We shipped fixes fast: 2.33.5 in the LTS track, 2.36.0 in STS. We upped the supported API version. But not every project was in a position to do the same.

Traefik broke in the same way. The Docker provider was pinned to API v1.24. Anyone running Traefik behind Docker 29 saw errors flood the logs. Fixed in v3.6.1, after they added proper negotiation logic.

CapRover had a similar issue. Its backend used docker-modem pegged at API v1.43. One version short. Docker 29 rejected it, and the dashboard refused to start. They patched it in v1.14.1.

Watchtower didn’t make it. The official image still uses a Docker client pinned to API v1.25. Once Docker 29 hit, Watchtower broke. Users saw infinite loops of version errors. No patch. No update. It’s been unmaintained for over two years. Some moved to forks, others hacked around it with DOCKER_API_VERSION. But in terms of official support; it's done.

Dockge also broke. Lightweight Compose dashboard, still actively used, but no patch for Docker 29. Anyone running the latest engine found the backend refused to connect. Still broken as of now.

CasaOS? Same story. Their App Store manager was compiled against Docker API v1.43. Just under the line. Once Docker 29 rolled out, it couldn’t talk to the daemon anymore. No apps, no dashboards. Community floated workarounds, but nothing’s landed upstream.

Yacht, billed as a modern Portainer alternative, is likely broken too. It uses dockerode, the same client CapRover had to patch. But Yacht hasn’t been actively maintained since mid-2023. No fix has been posted. If it’s running against Docker 29, odds are it fails for the same reason: embedded client too old, no negotiation, hard stop.

Swarmpit never had a chance. That project is already archived. It uses the Docker API heavily to monitor containers and services in Swarm. With the daemon now requiring API v1.44, anything compiled against older clients just fails. No updates are coming; the project’s been dead for a while. Docker 29 didn’t just break it; it buried it.

LazyDocker was affected too. Its Go-based Docker client couldn’t negotiate high enough, so connections failed. But the maintainers responded, v0.24.2 shipped with API 1.52 support. It works again.

Testcontainers (Java) broke hard in CI pipelines. Its docker-java dependency defaulted to API 1.32. Docker 29 rejected it. Everything failed. They fixed it in v2.0.2, but until then, people were scrambling to patch over it.

JetBrains IDEs, same deal. Their Docker plugin started throwing 400s. The embedded client wasn’t compliant. Later builds fixed it, but for a while, users had to either downgrade Docker or override daemon settings to keep things functional.

cAdvisor? Also broke. Older builds used outdated Docker clients. Metrics collection just stopped working. Fixed in v0.53.0, but anyone relying on older builds or embedded versions in other stacks saw their dashboards go blank.

The pattern here is obvious: Docker 29 didn’t just enforce a new API floor. It exposed which tools are actually maintained and which ones are just... still running because Docker used to be lenient.

That leniency is gone now.

Everything that assumed the daemon would always tolerate legacy clients is dead in the water. A bunch of "working" tools turned out to be unmaintained, unmonitored, or abandoned. Docker 29 forced them into the open.

It also made the separation clear. The tools that adapted (Traefik, Portainer, CapRover, LazyDocker, Testcontainers) survived because they’re maintained. The rest (Watchtower, Dockge, CasaOS, Yacht, Swarmpit) effectively got decommissioned.

This wasn’t just a version bump. It was a cleanup. If your tool talks to Docker and isn’t being updated, it no longer works. Simple as that.

Infrastructure Moves Fast. Stay Ahead.

Subscribe to our monthly newsletter

Conclusion

Neil Cresswell
Portainer CEO
Follow on LinkedIn

Neil Cresswell is the co-founder and CEO of Portainer, a popular platform that simplifies container management for Docker, Kubernetes, and edge environments. A veteran of over 25 years in IT, he began his career with 12 years at IBM before leading VMware consulting at ViFX across Asia-Pacific and serving as CEO for cloud service providers. Frustrated by the lack of usable tooling for “containers as a service,” he created Portainer to make container technology accessible to everyone. Under his leadership, Portainer has grown from an open-source UI into an enterprise-ready platform used globally.

Try Portainer for Your Team

Tip  / Call out