Docker Engine v29: Foundational Updates for the Future

Docker Engine v29 is a foundational release that sets the stage for the future of the Docker platform. While it may not introduce many flashy new features, it includes several significant under-the-hood changes designed to simplify architecture and improve ecosystem alignment. These updates are primarily for Linux users running Docker Engine (Community Edition) directly on their hosts. Docker Desktop users will automatically receive these Engine updates in future Desktop releases and do not need to take any action.

Key changes in Docker Engine v29 include:

• Minimum API version update
• The containerd image store is now the default for new installations.
• Migration to Go modules
• Experimental Support for nftables

These changes collectively enhance maintainability, developer experience, and interoperability across the container ecosystem.

Minimum API Version Update

Docker versions older than v25 have reached end-of-life. Consequently, the minimum API version has been increased to 1.44 (Moby v25).

If you encounter the following error, you will need to update to a newer client or follow the mitigation steps provided to override the minimum version:

Error response from daemon: client version 1.43 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version

Override the minimum API version

There are two methods to launch dockerd with a lower minimum API version. Additional information is available on docs.docker.com.

Using flags when starting dockerd

Launch dockerd with the DOCKER_MIN_API_VERSION environment variable set to the previous value. For example:

DOCKER_MIN_API_VERSION=1.24 dockerd

Using a JSON configuration file — daemon.json

Set min-api-version in your daemon.json file:

{
  "min-api-version": "1.24"
}

Containerd Image Store Becomes the Default

Why This Change Was Made

The containerd runtime originated as a core component of Docker Engine before being split out and donated to the Cloud Native Computing Foundation (CNCF). It has since become the industry-standard container runtime, powering Kubernetes and many other platforms.

While Docker integrated containerd for container execution years ago, it continued to utilize the graph driver storage backend for managing image layers. Meanwhile, containerd evolved its own image content store and snapshotter framework, designed for modularity, performance, and ecosystem alignment.

To ensure stability and a smooth transition, Docker has been gradually migrating to the containerd image store. Docker Desktop has already used the containerd image store as the default for most of the past year. With Docker Engine v29, this migration takes a significant step forward by becoming the default in the Moby engine for new installations.

What it is

As of Docker Engine v29, the containerd image store is now the default for image layer and content management for new installations.

Legacy graph drivers are still available but are now deprecated. New installations can still opt out of the containerd image store if issues arise.

Why This Matters

This shift brings several important benefits:

• Simplified architecture: Both execution and storage now leverage containerd, reducing duplication and internal complexity.
• Unlocks new feature possibilities, such as:
  • Snapshotter innovations
  • Lazy pulling of image content
  • Remote content stores
  • Peer-to-peer distribution
• Ecosystem alignment: Brings Docker Engine in sync with containerd-based platforms like Kubernetes, thereby improving interoperability.
• Future-proofing: Enables faster innovation in image layer handling and runtime behavior.

We acknowledge that this change may cause some disruption, as the containerd image store approaches content and layer management differently from existing storage drivers. However, this transition is ultimately a positive one, enabling a more consistent, modular, and predictable container experience.

Migration Path

To be clear, these changes only impact new installations; existing users will not be forced to migrate to containerd. However, you can choose to start your migration now and opt-in.

We are actively working on a comprehensive migration guide to assist teams in transitioning their existing content to the containerd image store.

What’s Next

The graph driver backend will be removed in a future release.

Docker will continue to evolve the image store experience, leveraging the full capabilities of containerd’s ecosystem. Expect to see enhanced content management, multi-snapshotter support, and faster pull/push workflows in the future.

Moby Migrates to Go Modules

Why This Change Was Made

Go modules have been the community standard for dependency management since 2019. However, until now, the Moby project used a legacy vendoring system. Avoiding Go modules led to:

• Constant maintenance churn due to workarounds for tooling assumptions.
• Confusing workflows for contributors.
• Compatibility issues with newer Go tools and ecosystem practices.

Simply put, resisting the adoption of Go modules was creating unnecessary difficulties for everyone involved.

What It Is

The Moby codebase is now fully module-aware, managed using go.mod. This translates to cleaner dependency management and improved interoperability for tools and contributors. External clients, API libraries, and SDKs will find the Moby codebase easier to consume and integrate with.

What It’s Not

This is not a user-facing feature; you will not observe any UI or command changes. However, it does affect developers who consume Docker’s Go APIs.

Important for Go Developers

If you are consuming the Docker client or API packages in your own Go projects:

• The old module path github.com/docker/docker will no longer receive updates.
• To stay current with Docker Engine releases, you must switch to importing from github.com/moby/moby.

Experimental Support for nftables

Why This Change Was Made

For bridge and overlay networks on Linux, Docker Engine currently creates firewall rules using iptables and ip6tables. In most cases, these commands are linked to iptables-nft and ip6tables-nft, meaning Docker’s rules are translated to nftables behind the scenes.

However, OS distributions are beginning to deprecate support for iptables. It is therefore timely for Docker Engine to directly create its own nftables rules.

What It Is

This release introduces opt-in support for creating nftables rules instead of iptables. The rules are functionally equivalent, but there are some differences to be aware of, particularly if you use the DOCKER-USER chain in iptables.

On a host that uses firewalld, iptables rules are created via firewalld’s deprecated "direct" interface. This is not necessary for nftables because rules are organized into separate tables, each with its own base chains. Docker will still set up firewalld zones and policies for its devices, but it creates nftables rules directly, similar to how it operates on a host without firewalld.

What It’s Not

In this initial version, nftables support is considered "experimental." Please exercise caution when deploying it in a production environment.

Swarm support is planned for a future release. Currently, it is not possible to enable Docker Engine’s nftables support on a node with Swarm enabled.

In a future release, nftables will become the default firewall backend, and iptables support will be deprecated.

Future Work

In addition to adding planned Swarm support, there is scope for efficiency improvements. For example, the rules themselves could make more extensive use of nftables features, particularly sets of ports.

These changes will be prioritized based on the feedback received. If you would like to contribute, please let us know!

Try It Out

To enable nftables support, start dockerd with the option --firewall-backend=nftables.

After a reboot, you may need to enable IP Forwarding on the host. If you are using the DOCKER-USER iptables chain, it will need to be migrated. For more information, refer to Docker’s documentation on nftables.

We are actively seeking feedback. If you encounter issues, please report them at github.com/moby/moby/issues.

Getting Started with Engine v29

As previously mentioned, this post is primarily for Linux users running Docker Engine (Community Edition) directly on their hosts. Docker Desktop users do not need to take any action, as Engine updates are automatically included in upcoming Desktop releases.

To install Docker Engine on your host or update an existing installation, please follow the guide for your specific OS.

For additional information about this release:

• Release notes for Engine v29
• Documentation