[{"data":1,"prerenderedAt":175},["ShallowReactive",2],{"seo-verification":3,"blog-docker-v29-migration-vps-breaking-changes-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"id":7,"slug":8,"title":9,"excerpt":10,"readTime":11,"views":12,"isPinned":13,"publishedAt":14,"category":15,"categories":20,"featuredImage":22,"bgImage":23,"posterImage":24,"relatedSolution":22,"intro":25,"sections":26,"ctaTitle":130,"ctaBody":131,"ctaButton":132,"ctaUrl":133,"relatedPosts":134},247,"docker-v29-migration-vps-breaking-changes","Docker v29 on VPS: migrate without breaking your stacks","Docker Engine v29 changes the minimum API version, the network backend, and the image store. Migration guide for agencies managing a fleet of client VPS.",11,0,false,"2026-08-12T00:00:00+00:00",{"id":16,"name":17,"slug":18,"color":19,"icon":18},3,"Deployment","deploiement","bg-success\u002F10 text-success",[21],{"id":16,"name":17,"slug":18,"color":19,"icon":18},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdocker-v29-migration-vps-breaking-changes-poster.svg","Docker Engine v29, released in March 2026, changes three foundations simultaneously: minimum API version, nftables network backend, and containerd image store. An unprepared VPS receiving this update breaks silently — docker-compose v1 standalone stops working, Dockge no longer starts, and the iptables rules your stacks relied on disappear. This guide helps you detect what is broken, migrate cleanly, and prevent the next `apt upgrade` from becoming a client incident at 2 a.m.",[27,31,42,45,55,64,73,82,102,106,109,127],{"type":28,"title":29,"body":30},"h2","Why Docker v29 breaks existing stacks — and why now","An agency managing a fleet of client VPS is caught in a particular bind: the upstream update (Docker, Ubuntu, Debian) arrives from outside, regardless of who administers the server. When a client VPS receives `apt upgrade` without oversight, three breaking changes arrive simultaneously.\n\n**First break — minimum API version.** Docker Engine v29 raises the minimum API version to `1.44`. Clients still running the old `docker-compose` v1 standalone binary (`\u002Fusr\u002Flocal\u002Fbin\u002Fdocker-compose`) fail immediately: their client code is compiled for earlier API versions, and the daemon refuses the connection with an incompatibility message.\n\n**Second break — nftables network backend.** Docker v29 enables nftables by default instead of iptables to manage Docker network firewall rules. Third-party scripts that inspect iptables chains directly (monitoring scripts, custom firewalls, certain UFW rules) no longer see Docker rules — not because they disappeared, but because they now live in nftables.\n\n**Third break — containerd image store.** The image storage backend switches to the containerd store. Opt-in since v29, it will become the default in v30. On a migrated server, existing images remain accessible but the cache path changes, which can surprise scripts that inspect `\u002Fvar\u002Flib\u002Fdocker\u002Fimage` directly.\n\nThe classic objection — \"our clients manage their own VPS\" — provides no protection. The break comes from outside, and the agency is who the client calls when their site stops responding.",{"type":32,"title":33,"items":34},"ul","What this guide enables you to do",[35,36,37,38,39,40,41],"**Detect the API version** tension between your `docker` client and the VPS daemon, before the next command produces a cryptic error.","**Identify in 30 seconds** whether a VPS is still running `docker-compose` v1 standalone — the binary deprecated since Docker Desktop 3.6 and removed from official packages.","**Migrate to the `docker compose` v2 plugin** with the exact two commands, then verify your existing `docker-compose.yml` files work without syntax changes.","**Understand the nftables impact** on your stacks: what continues to work (Docker networks), what can break (your scripts reading iptables), and the diagnostic command that settles it.","**Enable or defer the containerd store** based on your migration timeline, with the exact configuration key and verification command.","**Evaluate the compatibility** of Dockge, Portainer, and CasaOS App Store with v29, so you do not discover incompatibility during a client incident.","**Prepare your client VPS fleet** so the next `apt upgrade` is a planned event, not a late-night emergency.",{"type":28,"title":43,"body":44},"Prerequisites before starting","This guide applies to any VPS running Ubuntu 22.04\u002F24.04 or Debian 11\u002F12 with Docker Engine installed from the official Docker Inc. repositories (not the distribution's `docker.io` package). You need SSH access as root or sudo. No service interruption is required for the diagnostic steps; migrating the compose plugin takes a few seconds during which `docker compose` commands are unavailable. Take a VPS snapshot before modifying `\u002Fetc\u002Fdocker\u002Fdaemon.json` if you enable the containerd store — restoring in case of issues takes less than five minutes with a VPS that offers on-demand snapshots.",{"type":46,"title":47,"steps":48},"steps","Step 1 — Diagnose the API version",[49,52],{"title":50,"body":51},"Check the client and daemon API versions","On each VPS to audit, run the following two commands:\n\n```bash\ndocker version --format '{{.Client.APIVersion}}'\ndocker version --format '{{.Server.APIVersion}}'\n```\n\nIf the client version is below `1.44` and the daemon is running v29, you will get an error on the next commands. The `1.44` threshold is the minimum accepted by Docker Engine v29: a client compiled for `1.43` or earlier fails with `Error response from daemon: client version 1.43 is too old. Minimum supported API version is 1.44, please upgrade your client`.\n\nIf both lines show `1.44` or higher, your client is compatible. Proceed to the next step.",{"title":53,"body":54},"Detect the presence of docker-compose v1 standalone","The `docker-compose` command with a hyphen and the `docker compose` command without a hyphen are not the same thing. v1 is a standalone Python binary, v2 is a Go plugin integrated into the Docker CLI.\n\n```bash\nwhich docker-compose && docker-compose --version\n```\n\nIf the command returns a path in `\u002Fusr\u002Flocal\u002Fbin\u002F` or `\u002Fusr\u002Fbin\u002F` with a version `1.x.x`, you have the deprecated standalone binary. After the Docker v29 update, this binary returns `docker-compose: command not found` if the package was removed, or the API error described above if it is still present.\n\n```bash\ndocker compose version\n```\n\nIf this command returns `Docker Compose version v2.x.x`, the v2 plugin is already present. Both can coexist temporarily, but the goal is to use only the v2 plugin.",{"type":46,"title":56,"steps":57},"Step 2 — Migrate from docker-compose v1 to the v2 plugin",[58,61],{"title":59,"body":60},"Remove the v1 binary and install the plugin","```bash\napt remove docker-compose\napt install docker-compose-plugin\n```\n\nOn a Debian or Ubuntu VPS using the official Docker Inc. repositories (`download.docker.com`), the `docker-compose-plugin` package is available without additional configuration. If `apt remove docker-compose` responds `Package not found`, the binary was installed manually: locate it with `which docker-compose` and delete the file.\n\nPost-migration verification:\n\n```bash\ndocker compose version\n# Docker Compose version v2.36.0\n```",{"title":62,"body":63},"Verify syntax compatibility of your existing Compose files","The vast majority of `docker-compose.yml` files written for v1 work without modification with the v2 plugin. The only syntax breaks concern `version:` directives above `\"3.8\"` (ignored in v2, not blocking) and the `--compatibility` option (removed). Validate your existing files:\n\n```bash\ndocker compose config\n```\n\nThis command resolves environment variables, validates syntax, and displays the resolved configuration. An error-free output means your file is compatible.\n\nIf your team uses shell scripts with `docker-compose` (hyphen), add a compatibility alias in `\u002Fetc\u002Fbash.bashrc` on the VPS:\n\n```bash\nalias docker-compose='docker compose'\n```\n\nThis alias does not fix scripts that call `docker-compose` in absolute in a cron or systemd service — audit those separately.",{"type":46,"title":65,"steps":66},"Step 3 — Understand and adapt to the nftables network backend change",[67,70],{"title":68,"body":69},"Verify that Docker networks still work","The good news: `docker network` works correctly with nftables. Inter-container traffic, NAT, and port exposure continue to work. What changes is the underlying tool that writes the rules.\n\n```bash\ndocker network ls\n```\n\nYour existing bridge networks are still listed. To verify that a container is receiving traffic on the expected port, test directly:\n\n```bash\ncurl -s http:\u002F\u002Flocalhost:8080\u002Fhealth\n```\n\nIf the response is correct, the Docker data plane works regardless of the backend.",{"title":71,"body":72},"Diagnose the impact on your iptables scripts","The problem arises when a third-party script (monitoring, Ansible, UFW rules) inspects `iptables` to verify Docker rules are present:\n\n```bash\niptables -L DOCKER 2>&1\n```\n\nWith the nftables backend, this chain is empty or absent. The script returns an error while Docker works perfectly. This is not a Docker failure — your audit tool is no longer looking in the right place.\n\nTo inspect the actual rules:\n\n```bash\nnft list ruleset | grep -A 20 'docker'\n```\n\nIf your monitoring scripts or Ansible playbooks check for Docker-specific iptables rules, adapt them to query nftables instead of inferring a failure.",{"type":46,"title":74,"steps":75},"Step 4 — Evaluate and enable the containerd image store",[76,79],{"title":77,"body":78},"Check the current storage driver","```bash\ndocker info | grep 'Storage Driver'\n```\n\nOn a VPS updated to v29 without configuration changes, you typically get `Storage Driver: overlay2`. The containerd store is opt-in on v29 — it is not enabled automatically. It will become the default on v30.",{"title":80,"body":81},"Enable the containerd store (opt-in, recommended before v30)","To enable the containerd store on v29 and prepare the migration before it is imposed in v30, add the following key to `\u002Fetc\u002Fdocker\u002Fdaemon.json`:\n\n```bash\n{\n  \"features\": {\n    \"containerd-snapshotter\": true\n  }\n}\n```\n\nRestart the daemon:\n\n```bash\nsystemctl restart docker\n```\n\nVerification:\n\n```bash\ndocker info | grep 'Storage Driver'\n# Storage Driver: overlayfs\n```\n\n**Note**: existing images pulled under `overlay2` remain available, but new layers are written in containerd format. If you need to revert, remove the key and restart — images in the new format will no longer be accessible without the containerd backend. This is why a snapshot before this step is recommended.",{"type":83,"title":84,"headers":85,"rows":89},"comparison","Third-party tool compatibility with Docker Engine v29",[86,87,88],"Tool","v29 compatibility status","Recommended action",[90,94,98],[91,92,93],"**Dockge** (up to 1.4.1 included)","Not compatible: the Dockge daemon calls API routes removed in v29. The panel no longer starts after the Docker update.","Update Dockge to version 1.4.2 or higher, which targets API v1.44. Check Dockge release notes before `apt upgrade` on a VPS hosting it.",[95,96,97],"**Portainer** (Community Edition \u003C 2.21)","Partially compatible: the interface works, but standalone Docker environments may show errors on network views. Version 2.21 fixes the nftables calls.","Update Portainer via `docker pull portainer\u002Fportainer-ce:latest` then `docker compose up -d` before upgrading Docker Engine.",[99,100,101],"**CasaOS App Store**","Partial compatibility documented: deployed apps continue to work, but the app manager may report errors when inspecting images if the containerd store is enabled. No corrective version announced as of 2026-08.","Keep the containerd store opted out (v29 default) on CasaOS VPS until a corrective version. Test on a copy environment before any update.",{"type":103,"title":104,"body":105},"tip","Test the migration on a snapshot before touching production","A VPS with root access and snapshots lets you validate each step of this migration without risk. Create a snapshot named `before-docker-v29`, perform the full migration, validate your stacks, then delete the snapshot. If something goes wrong mid-way, restoring brings the VPS back to its initial state in under five minutes. This is exactly the use case on-demand snapshots cover: testing a risky system update on an exact copy, not on a client's production server.",{"type":28,"title":107,"body":108},"Troubleshooting — real errors and remedies","The following scenarios cover the majority of incidents observed during Docker v29 migrations on VPS fleets.",{"type":46,"title":110,"steps":111},"Common error scenarios",[112,115,118,121,124],{"title":113,"body":114},"Error: `client version X.XX is too old. Minimum supported API version is 1.44`","**Cause**: the `docker-compose` v1 standalone binary is still present and attempts to communicate with the v29 daemon.\n\n**Remedy**:\n\n```bash\napt remove docker-compose\napt install docker-compose-plugin\ndocker compose version\n```\n\nIf the binary was installed manually (outside apt), find it:\n\n```bash\nwhich docker-compose\nrm \u002Fusr\u002Flocal\u002Fbin\u002Fdocker-compose\n```",{"title":116,"body":117},"Error: `docker-compose: command not found` after `apt upgrade`","**Cause**: the `docker-compose` package (v1) was removed during the update, and the v2 plugin was not installed.\n\n**Remedy**:\n\n```bash\napt install docker-compose-plugin\n```\n\nThen verify that your scripts calling `docker-compose` (with hyphen) now use `docker compose` (without hyphen), or set the system alias.",{"title":119,"body":120},"Error: `iptables: No chain\u002Ftarget\u002Fmatch by that name` in a monitoring script","**Cause**: your script inspects the `DOCKER` chain in iptables, but Docker v29 with nftables no longer writes it there.\n\n**Remedy**: replace the iptables check with an nftables check:\n\n```bash\nnft list ruleset | grep -c 'docker'\n```\n\nIf the count is above zero, Docker rules are present in nftables. Or use `docker network inspect bridge` to verify the data plane state directly from Docker, without depending on the network backend.",{"title":122,"body":123},"Dockge no longer starts after the update","**Cause**: Dockge 1.4.1 and earlier call API routes absent from Docker Engine v29.\n\n**Remedy**:\n\n```bash\ncd \u002Fopt\u002Fdockge\ndocker compose pull\ndocker compose up -d\n```\n\nIf the `latest` tag of the Dockge image is already at 1.4.2 or higher, this command suffices. Otherwise, edit your Dockge `docker-compose.yml` to point to the corrective version tag before relaunching.",{"title":125,"body":126},"Containers no longer respond on their ports after daemon restart","**Cause**: on the first restart of `dockerd` in nftables mode, NAT rules are rewritten in the correct backend, but some distributions have a conflict between the `iptables-legacy` service and nftables that delays rule setup.\n\n**Remedy**:\n\n```bash\nsystemctl stop docker\nsystemctl disable iptables\nsystemctl start docker\n```\n\nThen verify containers are restarted (`docker compose up -d`) and ports are exposed (`docker ps --format 'table {{.Names}}\\t{{.Ports}}').",{"type":28,"title":128,"body":129},"Preparing your fleet to avoid the next incident","A well-managed Docker v29 migration is not a one-off event — it is an opportunity to put in place the reflexes that prevent the next late-night emergency.\n\n**Lock the Docker version in `apt`.** On client VPS, prevent Docker from updating automatically during unsupervised `apt upgrade` runs:\n\n```bash\napt-mark hold docker-ce docker-ce-cli containerd.io\n```\n\nUnlock (`apt-mark unhold`) only when you are ready to migrate, after testing on a snapshot.\n\n**Automate fleet auditing.** An Ansible playbook that checks the Docker API version on each VPS takes under an hour to write and gives you a dashboard of your fleet's exposure before each major Docker release.\n\n**Integrate Docker migration into your patch routine.** The procedure described here — snapshot, API check, compose migration, nftables test, stack validation — documents as a runbook and replays at each major release.","VPS ready for Docker v29 — with snapshots and root access","An agency managing multiple client VPS needs a homogeneous Docker infrastructure, versioned and prepared for upstream updates. ServOrbit provides VPS with root access, dedicated IPv4, and snapshots — so every migration is tested first on a copy environment, not on a client's production server.","See VPS Cloud plans","\u002Fsolutions\u002Fagences",[135,145,161],{"id":136,"slug":137,"title":138,"excerpt":139,"readTime":11,"views":12,"isPinned":13,"publishedAt":140,"category":141,"categories":142,"featuredImage":22,"bgImage":23,"posterImage":144,"relatedSolution":22},229,"docker-compose-production-checklist","Docker Compose in Production: 10-Point Checklist","10 Docker Compose settings to verify before any production deployment: restart, healthchecks, limits, secrets and logs.","2026-08-06T00:00:00+00:00",{"id":16,"name":17,"slug":18,"color":19,"icon":18},[143],{"id":16,"name":17,"slug":18,"color":19,"icon":18},"\u002Fblog\u002Fcovers\u002Fdocker-compose-production-checklist-poster.svg",{"id":146,"slug":147,"title":148,"excerpt":149,"readTime":150,"views":12,"isPinned":13,"publishedAt":151,"category":152,"categories":158,"featuredImage":22,"bgImage":23,"posterImage":160,"relatedSolution":22},224,"routine-correctifs-apps-self-hosted","Self-hosted apps: the patching routine","Inventory, security advisories, a patch window, backups and post-checks: the routine most self-hosted estates are missing.",4,"2026-08-05T00:00:00+00:00",{"id":153,"name":154,"slug":155,"color":156,"icon":157},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[159],{"id":153,"name":154,"slug":155,"color":156,"icon":157},"\u002Fblog\u002Fcovers\u002Froutine-correctifs-apps-self-hosted-poster.svg",{"id":162,"slug":163,"title":164,"excerpt":165,"readTime":11,"views":12,"isPinned":13,"publishedAt":166,"category":167,"categories":172,"featuredImage":22,"bgImage":23,"posterImage":174,"relatedSolution":22},236,"ansible-automatiser-serveurs-vps","Automating VPS Server Management with Ansible","Learn how to automate VPS fleet management with Ansible: inventory, playbooks, roles and Vault for a reproducible, auditable infrastructure.","2026-08-08T00:00:00+00:00",{"id":168,"name":169,"slug":170,"color":171,"icon":170},2,"Automation","automatisation","bg-brand-action\u002F10 text-brand-action",[173],{"id":168,"name":169,"slug":170,"color":171,"icon":170},"\u002Fblog\u002Fcovers\u002Fansible-automatiser-serveurs-vps-poster.svg",1786536100650]