Is Docker Dead? No, But Here's What Changed
Every few months, someone publishes a “Docker is dead” article. It gets shared widely. Engineers on social media argue about it. Then everyone goes back to typing docker build and docker run.
The cycle has been repeating since at least 2020, when Kubernetes deprecated Docker as a container runtime. It’s 2026 now, and Docker is still everywhere.
So is Docker dead?
No. But the landscape has genuinely shifted, and pretending nothing changed is just as wrong as declaring Docker obsolete.
What People Mean When They Say “Docker Is Dead”
Usually they mean one of three things, and it’s worth separating them because the answer is different for each.
1. “Docker as a Kubernetes runtime is dead”
This is true, and has been for years.
Kubernetes deprecated dockershim in v1.20 (December 2020) and removed it entirely in v1.24 (May 2022). Modern Kubernetes clusters use containerd or CRI-O as their container runtime.
This was never really about Docker being bad. It was about Docker being too much. Docker includes a CLI, a daemon, an API, image building, networking, logging, and a container runtime. Kubernetes only needed the runtime part. Containerd gives Kubernetes exactly what it needs without the overhead.
If you’re managing Kubernetes clusters and still thinking about Docker at the runtime level, you’re several years behind.
2. “Docker as a development tool is dead”
This is wrong.
Docker Desktop, the Docker CLI, Docker Compose — these tools are used by millions of developers daily. According to the 2025 Stack Overflow survey, Docker remains the most popular development tool among professional developers, ahead of Git.
For local development, building images, running databases, spinning up multi-service environments — Docker’s developer experience is still the best in class. Nothing else comes close in terms of ecosystem, documentation, and familiarity.
3. “Docker the company is dead”
Also wrong. Docker Inc. had a rough period between 2019-2021, selling off its enterprise business and pivoting to developer tools. But since introducing Docker Desktop subscriptions and Docker Scout (a supply chain security tool), the company has stabilized. They’re profitable and shipping features.
What Actually Changed
The real story isn’t about Docker dying. It’s about the container ecosystem fragmenting into specialized layers where Docker used to own everything.
containerd Won the Runtime Layer
containerd (originally extracted from Docker itself) is now the default container runtime for:
- Kubernetes (most distributions)
- AWS ECS and EKS
- Google GKE
- Azure AKS
- Most cloud container services
It’s lighter than Docker, purpose-built for orchestration platforms, and backed by the CNCF. In production Kubernetes environments, containerd is the de facto standard.
containerd 2.0, released in late 2025, brought improved plugin architecture, better sandbox support, and tighter integration with container security tools. It’s mature, stable infrastructure.
CRI-O Holds the Red Hat Ecosystem
CRI-O is Kubernetes-native by design — it implements the Container Runtime Interface (CRI) and nothing else. It’s the default runtime for OpenShift and any Red Hat-based Kubernetes deployment.
If you’re in an enterprise Red Hat environment, you’re probably running CRI-O whether you know it or not.
Podman Took the “Docker Without Docker” Niche
Podman has been gaining adoption steadily, particularly in environments that want Docker-compatible CLI behavior without the Docker daemon.
The key difference: Podman is daemonless. There’s no background process managing containers. Each container runs as a direct child process of the user session. This has real security benefits — no root daemon means a smaller attack surface.
Podman also supports rootless containers out of the box, something Docker added later and still treats as somewhat experimental.
For many server-side use cases (CI/CD, batch processing, security-sensitive environments), Podman is a legitimate alternative to Docker.
nerdctl Bridges containerd and Developer UX
nerdctl is a relatively new tool that provides a Docker-compatible CLI on top of containerd. Think of it as “Docker commands, containerd runtime.”
It supports Docker Compose files, image building (via BuildKit), and most Docker CLI flags. For teams that want to standardize on containerd across both development and production, nerdctl provides a migration path that doesn’t require learning new commands.
The Runtime Doesn’t Matter (For Most People)
Here’s the thing that gets lost in the Docker vs. containerd vs. CRI-O debate: for most engineers, the runtime is irrelevant.
You build an OCI-compliant container image. That image runs on Docker, containerd, CRI-O, Podman, or anything else that implements the OCI runtime spec. The image format is the same. The behavior is the same.
The container image is the universal artifact. The runtime is an implementation detail.
If you’re a developer building applications, you interact with:
- A
Dockerfile(or Buildkit, or Buildpacks) - A container image registry
docker runor equivalent
Whether the thing executing your container is Docker, containerd, or CRI-O is abstracted away by your orchestration platform.
The people who care deeply about the runtime layer are:
- Platform engineers managing Kubernetes clusters
- Security teams auditing the container stack
- Cloud providers building managed services
Everyone else just builds images and deploys them.
Where Docker Still Wins
Despite the fragmentation, Docker maintains clear advantages in specific areas:
Developer Experience
docker compose up is still the fastest way to spin up a multi-service development environment. The compose spec, the volume management, the networking defaults — it all just works. Podman has compose support, but it’s not as polished.
Ecosystem and Documentation
Every tutorial, every Stack Overflow answer, every blog post about containers uses Docker. The ecosystem effect is massive. When a junior engineer needs to containerize an application, they Google it and find Docker instructions.
Image Building
Docker’s integration with BuildKit provides the best image building experience: layer caching, multi-stage builds, build secrets, SSH forwarding during builds. Other tools can build OCI images, but Docker’s builder is the most mature.
Desktop Experience
Docker Desktop provides a GUI, built-in Kubernetes, volume management, and extension support. For developers who want containers without deep CLI knowledge, it’s unmatched.
Where Docker Doesn’t Win Anymore
Production Kubernetes
If you’re running containers in Kubernetes, you’re running containerd or CRI-O. Docker is not in the picture and hasn’t been for years.
Security-Sensitive Environments
Docker’s daemon architecture (a root-level background process managing all containers) is a security concern that Podman’s daemonless architecture avoids entirely. For environments with strict security requirements, Podman is often the better choice.
Minimal Server Deployments
On servers that only need to run containers (no building, no development tooling), installing full Docker is overkill. containerd + nerdctl or Podman gives you container execution without the overhead.
My Take
Docker is not dead. It’s not dying. But it’s no longer the entire story.
The correct mental model in 2026 is:
- Docker = best-in-class development tool for building and running containers locally
- containerd = the production runtime that powers Kubernetes and cloud platforms
- CRI-O = the alternative production runtime for Red Hat/OpenShift environments
- Podman = the security-conscious alternative for server-side container execution
- OCI images = the universal format that makes the runtime choice irrelevant to most people
If you’re a developer, keep using Docker. It’s the right tool.
If you’re a platform engineer, understand containerd and CRI-O. They’re what your clusters actually run.
If you’re building the container strategy for a new project, start with this question: who is the user?
Developers? Docker. Kubernetes clusters? containerd. Security-first servers? Podman. Everything? OCI images that run anywhere.
The Real Lesson
The “Is Docker dead?” debate misses the point entirely.
The actual story is that the container ecosystem matured. What used to be a single tool (Docker) became a stack of specialized components — image formats, build tools, runtimes, orchestrators — each optimized for its layer.
Docker’s contribution was not the daemon or the CLI. It was the mental model: build once, run anywhere, in an isolated, reproducible environment.
That mental model is more alive than ever.
It’s just running on containerd.