Docker 29 quietly changed two defaults — the reinstall will surprise you, not the upgrade
Docker Engine 29 has been out since November. I ignored it, the way you ignore a major-version bump on a box that's working fine — "foundation release, no flashy features, I'll get to it." Then I actually read what its two new defaults do, and realised that on a machine like mine — one VPS, Coolify, a handful of containers — the danger isn't in upgrading. It's in reinstalling, and in flipping one tempting switch.
What "foundation release" actually means
Docker's own words: v29 is "a foundational release that sets the stage for the future," light on features, heavy on "under-the-hood changes." It shipped 29.0.0 on 10 November 2025; the current patch as I write is 29.6.2 (16 July 2026, a security fix). The two changes that matter for a solo operator are the image store and the firewall backend, and both are the kind of thing that's invisible until it isn't.
The containerd image store is now the default — for fresh installs
New installs of v29 default to the containerd image store instead of the old overlay2 one. This is good long-term: it's what unlocks multi-platform images, lazy pulling, and alignment with how Kubernetes already works. docker save and load even gained --platform selection.
The trap is the word "fresh." Existing installs are not auto-migrated — upgrade in place and you keep overlay2 and all your images, nothing moves. But if you switch stores (or rebuild the box from scratch), the daemon points at a different, initially empty store, and your existing containers and images appear to vanish until you repopulate them — re-pull, or save/load across. They're not gone; the daemon is just looking in a new drawer. Flip back to overlay2 and they reappear. But if you've ever rebuilt a VPS at 2am expecting docker compose up to just find your images, this is a genuinely nasty surprise to meet then.
The nftables backend: do not flip this on your prod box
v29 adds an experimental nftables firewall backend (--firewall-backend=nftables), and Docker has said plainly that nftables will eventually become the default and iptables support will be deprecated, because distros are moving that way. Fine, someday. Not today, and not on a box that matters, and here's the concrete reason:
- There is no
DOCKER-USERchain in nftables mode. Every "add my custom rules to DOCKER-USER" tutorial and script you've ever used simply has nothing to attach to. - ACCEPT rules that override Docker's DROP rules stop working — an accept in one chain doesn't halt processing in another.
- A leftover
DROPpolicy on your iptables FORWARD chain will silently black-hole packets that Docker's nftables rules already accepted, because the two subsystems don't coordinate.
On a VPS where Coolify manages Docker's networking and you may have your own firewall rules layered on, that's a recipe for locking yourself out or quietly breaking container connectivity. It's experimental for a reason. Leave the firewall backend on iptables.
A "foundation release" is one where nothing new shows up in the UI and two things change underneath you. Those are exactly the upgrades worth reading the notes for, because the surprises are all below the waterline.
A couple of other things that'll bite scripts
The minimum API version went up to 1.44, so anything talking to the daemon with a pre-v25 client now errors out. Legacy graph drivers are deprecated (still present in 29, gone later). And if you have any Go tooling hitting the daemon, the module path moved from github.com/docker/docker to github.com/moby/moby/client. None of these are dramatic on a single box, but they're the sort of thing that fails a CI job you forgot you had.
What I'm actually doing
On the box that runs this blog: a plain in-place engine upgrade is comparatively safe, because it changes neither the image store nor the firewall backend — you stay on overlay2 and iptables until you deliberately opt in. So I'll take the security patches. What I will not do is enable the nftables backend, or migrate the image store on a live host before Docker ships its official migration guide. And I've made a note to myself in big letters: if I ever rebuild this VPS from scratch, the fresh install lands on the containerd store by default, so keep registry copies of anything I care about and expect to re-pull. The upgrade is boring. The reinstall is the one that'll surprise you.