Last checked and updated on 05 Jun 2026
What Is New in Docker Engine 1.11
Docker Engine 1.11 is a foundational release that splits the monolithic daemon into separate, more focused components. This architectural shift paves the way for more stable and modular container runtimes.
| Category | Key Changes |
|---|---|
| New Features | Daemon split into dockerd and containerd, Live Restore, User Namespaces |
| Improvements | Builder cache invalidation, docker run with --stop-signal, Compose file v2 |
| Runtime & Networking | Built-in runc, experimental docker stack commands |
| Security | User Namespaces support, PID limit support |
Why was the Docker Daemon split up?
The core change in 1.11 is the decomposition of the Docker Daemon into two binaries: dockerd and containerd. This separation of concerns is a big deal for production environments.
dockerd handles the high-level Docker API and client communication. containerd is a dedicated subsystem that manages the container lifecycle (start, stop, pause, rm). This makes the entire system more resilient and easier to update individual components without downtime.
How does Live Restore keep my containers running?
The new Live Restore feature allows containers to continue running even if the Docker Daemon itself becomes unavailable or needs to be restarted. This is crucial for minimizing service interruptions during daemon upgrades or patches.
You enable it with the --live-restore daemon flag. In practice, this means your application's uptime is no longer tightly coupled to the management daemon's state, which is a significant step forward for operational stability.
What are the security improvements with User Namespaces?
User Namespaces support moved out of experimental status, providing a powerful isolation mechanism. It allows you to map root inside a container to a non-root user on the host system.
This drastically reduces the attack surface. If a process breaks out of the container, it has the privileges of a high-numbered, non-privileged user on the host instead of actual root, making lateral movement much harder.
How has the build process improved?
Builder cache invalidation got smarter. The docker build process became more efficient at reusing the cache layer when you change an ADD or COPY instruction.
It now only invalidates the cache if the actual checksum of the file being added has changed, not just the command itself. This saves a ton of time during development cycles where you're frequently iterating on code and rebuilding images.
FAQ
Does upgrading to 1.11 break my existing containers or commands?
No, the change to dockerd and containerd is entirely under the hood. The standard docker CLI commands you use daily remain exactly the same, preserving full backward compatibility.
How do I enable the Live Restore feature?
You need to configure it on the daemon. Edit your daemon.json file to include { "live-restore": true } or start dockerd with the --live-restore flag. A daemon restart is required to activate it.
What is the practical benefit of the new --stop-signal flag for docker run?
It gives you more control over how your container shuts down. You can specify which signal is sent to the container's PID 1 to stop it (e.g., SIGTERM, SIGKILL), which is essential for ensuring your applications terminate gracefully.
Is runc now a requirement for Docker?
Yes, runc is now the default container runtime and is bundled directly with Docker Engine. This adoption of the OCI-standard runtime solidifies Docker's commitment to open container standards.
What are the new experimental docker stack commands?
These commands (deploy, rm, ps, services) provide a native Docker CLI experience for managing distributed application stacks defined in a Compose file, foreshadowing the future of Docker Swarm integration.