Announcing Mirantis Container Runtime 29: IPv6 Enhancements, containerd Image Store, and Expanded Runtime Capabilities

Mirantis has released Mirantis Container Runtime (MCR) 29, delivering a new set of capabilities designed to further enhance the enterprise container runtime experience.

As an active member of the open source Moby community, Mirantis continues to collaborate with upstream contributors to evolve the platform. MCR 29 incorporates all features and fixes from Moby versions 26 through 29. 

In addition to upstream Moby enhancements, MCR 29 also includes broader improvements across the runtime and supporting ecosystem. This article highlights updates that we believe will deliver significant value.

Key Updates in MCR 29

Minimum API Version Support

To support continued innovation and reduce constraints imposed by legacy compatibility requirements, the minimum supported API version has been increased to 1.40 (corresponding to MCR 19.03), up from version 1.13.

This change enables future development without being limited by outdated interfaces, while still maintaining flexibility for interoperability across supported versions.

Before upgrading to MCR 29, ensure that all interacting components in your environment are compatible with this minimum API version. This means all MCR instances should be running at least version 19.03 to ensure full functionality.

Overlay Network Address Usage Statistics

Managing IP address space in overlay networks can be challenging, particularly as environments scale. MCR 29 introduces address allocation statistics, making it easier to monitor utilization and avoid exhaustion.

This information is now available via docker network inspect under the Status -> IPAM section:

$ docker network inspect bridge
[
    {
        "Name": "bridge",
<... snip ...>
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "IPRange": "",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
<... snip ...>
        "Status": {
            "IPAM": {
                "Subnets": {
                    "172.17.0.0/16": {
                        "IPsInUse": 3,
                        "DynamicIPsAvailable": 65533
                    }
                }
            }
        }
    }
]

In this example, a /16 subnet (65,536 total addresses) is configured. Three addresses are in use: the gateway, a reserved address, and the broadcast address. This leaves 65,533 addresses available for allocation.

As allocations change, these values update dynamically, enabling proactive monitoring and corrective action before address exhaustion occurs.

Note: IPv6 address usage is not tracked. Given the enormous size of IPv6 address spaces (a /64 provides over 18 quintillion addresses), such tracking is neither practical nor necessary.

IPv6 Support Improvements

As IPv6 adoption accelerates, MCR 29 introduces several enhancements to improve compatibility and usability in IPv6 environments.

• ip6tables enabled by default: Previously experimental support is now stable and enabled automatically, ensuring consistent behavior between IPv4 and IPv6; IPv6 Linux operating system support is leveraged by MCR for the best customer experience.

• Automatic ULA prefix assignment: If no IPv6 prefix is configured, MCR now assigns a Unique Local Address (ULA) prefix automatically. This simplifies setup and enables IPv6 networking without manual subnet configuration. If you prefer to manually manage your subnets, you can still continue to do so.

• Direct IPv6 routing support: The bridge network driver now supports direct-to-container routing using com.docker.network.bridge.gateway_mode_ipv6=routed=routed

Because IPv6 eliminates the need for NAT, containers can be directly addressable via standard routing. This simplifies networking but also requires careful firewall configuration, as NAT is no longer implicitly providing isolation.

These updates help MCR integrate more seamlessly into modern IPv6-native environments.

containerd Image Store (Now Production-Ready)

The containerd image store, previously experimental, is now production-ready and enabled by default for new installations.

This new image store introduces several advantages over legacy graph drivers:

• Native support for multi-platform images

• Support for Wasm (WebAssembly) containers

• Pluggable snapshotters for advanced capabilities such as lazy pulling and performance optimizations

These benefits come with increased storage requirements, as both compressed and uncompressed image layers are stored. Before enabling the containerd image store, review containerd documentation for disk space considerations and snapshotter requirements.

For existing deployments, behavior will not change automatically. Upgraded environments will continue using the existing image store unless the containerd-snapshotter feature is explicitly enabled.

Swarm Service Memory Control

MCR has long supported advanced memory management options at the daemon level. 

With the release of MCR 29, additional resource constraint configurations from the core daemon are now also available for use with Swarm via docker service create.

Newly supported options include:

• memory-swap - Control how disk space is used when physical memory is exhausted, which may negatively impact the performance of the service

• memory-swappiness - Control the amount of anonymous pages which can be swapped to disk by the OS kernel

• oom-score-adj - Control how services are terminated in out-of-memory situations

Memory management is inherently complex, and the interoperation of these (and other) configuration values is intricate. Proper tuning allows you to optimize service behavior under varying memory conditions and ensure predictable application performance.

As always, additional details are available via docker service create --help.

Experimental Windows Server 2025 Support

With the release of Windows Server 2025, many users are eager to adopt the latest platform. However, container support on Windows 2025 is currently limited due to upstream constraints.

Containerization on Windows relies on the Microsoft-maintained hcsshim project, which provides core container runtime functionality. At present the hcsshim project has removed Windows 2025 from their CI test matrix based on “known regressions in Ws2025 networking.”

As a result:

• MCR and Moby have also removed Windows 2025 from their CI test matrices

• Microsoft Azure Kubernetes Service (AKS) continues to list Windows 2025 support as preview-only as of early 2026

• No production-grade support is currently available across the ecosystem

Mirantis has begun exploratory work for Windows 2025 in MCR 29. However, due to the closed nature of the Windows platform, resolving these issues requires upstream changes beyond Mirantis’ control.

Customers may experiment with MCR 29 on Windows 2025, but no formal support or guarantees are provided at this time. Mirantis continues to monitor developments and contribute to upstream efforts. As the ecosystem matures, support for Windows 2025 will be incorporated into future MCR releases.

Looking Ahead

MCR 29 continues Mirantis’ commitment to delivering a secure, enterprise-grade container runtime while staying closely aligned with upstream innovation.

From improved IPv6 support to enhanced observability and expanded Swarm capabilities, this release brings meaningful updates that help operators manage modern container environments more effectively.

We encourage you to try out MCR 29 and explore these new capabilities. For additional details, configuration guidance, and upgrade considerations, take a look at the latest documentation for more details. As always, we welcome feedback and look forward to continuing collaboration with the community!