Docker's Golden Age Is Over: Why Developers Are Moving to Podman and containerd

Nearly a decade of Docker

I was digging through an old project directory the other day and noticed something. At some point my fingers started typing podman run instead of docker run. I never made a decision about it. The habit just changed. Then I looked at some recent numbers and realized it wasn't just me.

For close to ten years, Docker was containers. Docker Hub became the default registry every developer had bookmarked. Docker Desktop shipped to 3.3 million machines. "Dockerize it" turned into shorthand for modernizing an application. Back when I was wrapping legacy systems in containers at a bank, packaging something in Docker felt like getting halfway to done.

The mood is different now. Docker isn't dead. But its absolute grip is over. And this didn't happen overnight — it's a few structural decisions stacking up one after another.

The moment Kubernetes ended the relationship

The decisive hit landed in May 2022 with Kubernetes v1.24. dockershim was removed, and the bridge connecting Docker to Kubernetes was gone.

The fallout was immediate. Datadog's analysis showed Docker runtime usage dropping from 88% to 65% in a single year — 23 points. Over the same period containerd went from 23% to 53%, up 30 points. Sysdig's report put Docker's share as a Kubernetes runtime down 37%.

Technically this was always going to happen. Docker was never designed to run inside Kubernetes. That's why dockershim existed as a translation layer in the middle — take the incoming call, convert it to the Docker engine's API, hand the result back.

If you operate this stuff, a middle layer like that is a permanent headache. When something breaks, ownership gets one step blurrier, and you've got one more surface to debug. The industry followed Kubernetes in stripping out an unnecessary abstraction because of operational cost, not principle.

The license change that sped up the exodus

August 2021: Docker changed its commercial licensing, and the drift picked up speed. Companies with more than 250 employees or over $10M in revenue could no longer use Docker Desktop for free. The new pricing: Pro at $5 per user per month, Team at $7, Business at $21.

Docker's CEO pointed to "hundreds of thousands of seats converting to paid" as a win. From the company's side, monetization worked. The open source ecosystem reacted in the opposite direction. Instead of paying, people built alternatives.

Worth being precise about why. People didn't leave because the money hurt. Once a tool gets labeled "something they can start charging for at any time," decision-makers file it under potential risk. The licensing policy can change again. That uncertainty is what actually drove people out.

The main Docker Desktop alternatives:

도구	가격	특징
Rancher Desktop	무료	Kubernetes 내장, containerd 지원
Podman Desktop	무료	데몬리스, 루트리스
OrbStack	월 $8 (Mac)	가볍고 빠름
Colima	무료	CLI 전용, macOS/Linux

Docker's limits from a security angle

Docker's architecture still carries the shape of past security incidents. The Docker daemon runs as root, so once the daemon is compromised, the whole host is exposed. One container's problem has a path to the entire node.

Newer alternatives like Podman go daemonless. Containers run as ordinary user processes. That looks like a feature difference on paper, but in regulated industries it's hardening into a compliance requirement. It's getting harder to sit in an audit and explain why a root daemon is running on every node.

Recent security research is fairly grim. 87% of Docker images contain high or critical vulnerabilities, and 75% of container breaches involve privilege escalation. Docker Desktop alone had 6 critical CVEs across 2024–2025.

How much trust Podman's security model has earned shows up in one fact: it's the default container engine in Red Hat Enterprise Linux 8+. A conservative enterprise OS does not change its defaults lightly.

Performance and resource usage, in practice

Docker's convenience has a bill attached. That always-on daemon eats 140-180MB of RAM sitting idle.

Real benchmarks (as of 2026): containerd starts containers 15-20% faster than Docker, and Podman uses roughly 30% less memory. CPU overhead runs 10-15% better on the daemonless side.

If you develop locally with 20 containers up, Docker's "daemon tax" quietly takes the resources of about two microservices. On one laptop you might never feel it. Multiply across tens or hundreds of nodes and it's a different conversation. Operating costs always work this way — a small constant meets scale and grows teeth.

The practical alternatives in 2026

1. Podman (security first)

Daemonless, so there's no central process, and rootless by default, so containers run as a normal user. Docker compatibility is decent enough that a single alias docker=podman keeps 90% of your existing workflow running. podman generate kube spits out Kubernetes YAML on the spot. Good fit for security-sensitive teams and regulated industries.

2. containerd + nerdctl (the production standard)

It's the runtime Kubernetes actually uses, so there's nothing extra in the way. Dropping the translation layer buys 15-20% faster startup. CNCF project, adopted by AWS, GCP, and Azure. This is the production and CI/CD pipeline answer.

3. Rancher Desktop (free desktop replacement)

No license cost, so you can pull Docker Desktop out entirely. K3s ships built in for local Kubernetes testing, and you pick containerd or the Docker engine as the runtime. Fits enterprise developers and anyone learning Kubernetes.

One thing to keep in mind when picking tools. Those three aren't competing so much as splitting the job. Whatever you run on the desktop, the production runtime is converging on containerd anyway. So rather than trying to standardize on one thing, slot in whatever fits each stage: build, local, production.

The new workflow settling in

Docker isn't disappearing. Its role is being split up. The standard 2026 workflow looks like this:

1. 빌드: Docker BuildKit 또는 Buildah
2. 로컬 개발: Podman Desktop 또는 Rancher Desktop
3. 프로덕션 배포: containerd 또는 CRI-O via Kubernetes
4. 관리: 가벼운 CLI 도구

Docker usage climbed to 71% in the Stack Overflow 2026 developer survey, but that number is easy to misread. Most of it means development environments. Production runtimes already moved to containerd. Docker stayed at the developer's fingertips and stepped aside in the operations infrastructure. What one name used to do is being divided among several tools.

If you're thinking about migrating

The container ecosystem isn't a zero-sum game. It's going through maturation. Docker did the hardest part — making containers mainstream — and the industry moved on to sanding down security, cost, and performance on top of that.

If you're still running the Docker runtime in production, you're probably paying for unnecessary complexity, extra security surface, and infrastructure cost equal to the daemon tax. The good news is the migration tooling is mature now and the data backing the decision is clear. This isn't a call to rip everything out at once, though. Swapping a runtime pulls in your build pipeline, image registry, and logging and monitoring integrations, so moving in stages with verification at each step is the safe path.

containerd already owns production, and Podman keeps gaining ground on the desktop. The container revolution Docker started is still alive. It just stopped belonging to one company. I think that's what naturally happens when a technology gets mature enough. The moment a tool becomes a standard, the company that built it loses control of it.