✍️ 필사 모드: Docker Desktop Alternatives 2026 — Podman / OrbStack / Colima / Finch / Rancher Desktop Deep-Dive Comparison
English- Prologue — Why Are We Talking About Docker Alternatives Again
- Chapter 1 · The Real Components Behind a Docker Architecture Diagram
- Chapter 2 · containerd / runc / CRI-O — The Real Standard at the Bottom
- Chapter 3 · Podman + Buildah + Skopeo — Red Hats Daemonless Stack
- Chapter 4 · nerdctl — containerd With a Docker CLI
- Chapter 5 · Lima / Colima — The Linux VM Starting Point on Mac
- Chapter 6 · OrbStack — Commercial, Fast, Lightweight
- Chapter 7 · Finch — AWSs Open-Source Integrated Bundle
- Chapter 8 · Rancher Desktop — Optimal for Kubernetes Users
- Chapter 9 · Podman Desktop Deep Dive — Daemonless With a GUI
- Chapter 10 · Apple Container Framework — What Native Containers on Mac Mean
- Chapter 11 · Which Should Your Team Pick — Decision Tree
- Chapter 12 · References
Prologue — Why Are We Talking About Docker Alternatives Again
August 31, 2021. Docker Inc. announced the "Docker Subscription Service Agreement," declaring that Docker Desktop now required a paid subscription for commercial use at companies with 250+ employees or 10M USD+ revenue. That single line of terms fractured the entire container tooling ecosystem. Before that announcement "Docker" was synonymous with "containers." After it, "Docker" became unmistakably "one product from one company called Docker Inc."
Five years later, in May 2026, the landscape looks entirely different.
- Podman Desktop has matured into the 1.20.x line under Red Hats sponsorship, differentiated by daemonless architecture and rootless containers.
- OrbStack has become the de facto standard on Mac. Commercial, but memory usage is roughly one-third of Docker Desktops, and startup time is under two seconds.
- Finch is AWSs open-source integrated bundle. Lima + containerd + nerdctl + BuildKit, all in one package.
- Colima is the free default for those who want zero cost. Lima-based, installable via Homebrew.
- Rancher Desktop remains, post-SUSE acquisition, the friendliest option for Kubernetes-heavy developers.
- Apple Container Framework, announced at WWDC 2025, marks macOS itself adopting a first-class container runtime. As of May 2026, it ships with macOS 15.4 and later.
- And beneath all of them, containerd has become the real industry standard — a CNCF Graduated project, Kubernetes default runtime, and the engine that every tool above invokes one way or another.
This article compares these seven tools on the same axes. We examine their internal structure, performance characteristics, trade-offs, and which one fits which team. Numbers and feature flags are correct as of May 2026; in six months pricing may shift, but the framework for choosing should still hold.
Docker is not going away. What has changed is that Docker is now one option among many. We have moved from "Docker vs. everything else" to "the container tool that fits my team."
Chapter 1 · The Real Components Behind a Docker Architecture Diagram
Before we say "Docker alternative," we should decompose Docker itself into its five real components. Only then does "alternative" mean anything.
Component 1 · Container Runtime The low-level code that actually runs containers. It manipulates Linux namespaces, cgroups, and capabilities. Docker invokes containerd internally, and containerd in turn invokes runc. Options: 1) runc — OCI reference implementation in Go. 2) crun — Red Hats C implementation, faster and smaller. 3) kata-containers — VM-based isolation.
Component 2 · Runtime Daemon The long-running process that drives the runtime. Docker has dockerd, with containerd beneath it. Podmans signature difference is having no daemon at all. nerdctl talks to containerd directly.
Component 3 · CLI / Client
What the user types. docker, podman, nerdctl, finch, crictl. Most of these provide a Docker-compatible interface — run, build, pull, push, ps, images, exec, logs.
Component 4 · Image Builder Converts a Dockerfile into an OCI image. 1) classic builder — Dockers old, single-threaded builder. 2) BuildKit — Dockers modern builder; parallel, with cache mounts and secret mounts. 3) Buildah — Red Hat, daemonless, supports shell-script-style builds. 4) kaniko — Google, runs inside Kubernetes clusters.
Component 5 · VM Layer (macOS/Windows only) Containers depend on Linux kernel features, so on macOS and Windows you need a Linux VM. 1) Hyperkit / VZ — Docker Desktops old/new backend. 2) Lima — what Colima, Finch, and Rancher Desktop all build on. 3) WSL2 — Windows. 4) Apple Virtualization Framework — the engine of OrbStack.
A "Docker alternative" is just a different combination of these five components. In table form:
| Tool | Runtime | Daemon | CLI | Builder | VM Layer |
|---|---|---|---|---|---|
| Docker Desktop | containerd + runc | dockerd | docker | BuildKit | VZ (new) / Hyperkit (old) |
| Podman Desktop | crun | none | podman | Buildah | QEMU / Apple Hypervisor |
| OrbStack | containerd + runc | proprietary | docker (compatible) | BuildKit | Apple Virtualization Framework |
| Colima | containerd + runc | none (or dockerd) | nerdctl / docker | BuildKit | Lima |
| Finch | containerd + runc | none | nerdctl (finch wrapper) | BuildKit | Lima |
| Rancher Desktop | containerd | none | nerdctl or docker | BuildKit / moby | Lima |
| Apple Container | runc (macOS port) | none | container | BuildKit | Apple Virtualization Framework |
The headline: containerd is everywhere. The container-runtime war is effectively over and containerd won. The differences between the tools above are about what sits on top of containerd, not the runtime itself.
Chapter 2 · containerd / runc / CRI-O — The Real Standard at the Bottom
containerd was spun out of Docker in 2017 and donated to the CNCF. It graduated in 2019. In 2026 it is the default runtime for Kubernetes 1.30 and later, and the engine behind AWS Fargate, GKE, AKS, EKS, IBM Cloud, and DigitalOcean Kubernetes.
What containerd does Pulls and pushes images, unpacks OCI images into container bundles, invokes runc to actually execute containers, and manages container lifecycles (start/stop/kill/delete). It delegates namespace and cgroup configuration to runc.
Why is it lighter than Docker Docker is a two-layer structure: dockerd on top of containerd. Use containerd alone and you remove a layer. You also drop everything dockerd adds that many people never use — build orchestration, network plugins, volume management. Memory footprint shrinks, startup time drops.
runc vs. crun runc is Go and is the OCI reference. crun is Red Hats C rewrite and is faster — benchmarks consistently show container startup roughly twice as fast. Memory usage is lower too. Podman uses crun by default. containerd can switch to crun via runtime classes.
Where does CRI-O fit CRI-O is a minimal runtime for Kubernetes. It implements only the CRI (Container Runtime Interface) and nothing else. Red Hat OpenShift uses it by default. You rarely see it on developer desktops — for the purposes of this article, just know it as "the runtime that lives only on Kubernetes nodes."
containerds direct CLI is ctr, but its rough for humans. Two user-friendly CLIs emerged on top — nerdctl (Docker-compatible) and crictl (Kubernetes-CRI-focused).
# containerds own CLI
sudo ctr image pull docker.io/library/nginx:latest
sudo ctr container create docker.io/library/nginx:latest mynginx
sudo ctr task start mynginx
# Same thing with nerdctl (much easier)
nerdctl run -d --name mynginx -p 8080:80 nginx:latest
That containerd is the standard has big implications for tool choice. Most of the tools above call the same containerd underneath. So the real differentiation is (a) CLI familiarity, (b) VM-layer performance, and (c) extras like Kubernetes integration, GUI, and builder integration.
Chapter 3 · Podman + Buildah + Skopeo — Red Hats Daemonless Stack
Podman is Red Hats Docker alternative, released in 2018. The name stands for "Pod Manager" — it began as a tool for running Kubernetes Pods locally. In 2026 its on the 5.5.x line and is the default container tool on RHEL, Fedora, and CentOS Stream.
Podmans signature — daemonless
Docker requires dockerd to be running at all times. Even with zero containers, the daemon consumes memory and lives as a systemd service. Podman is different. Type podman run and a forked process spins up the container, then dies with it. No daemon. No background service.
# Docker — daemon must be running
sudo systemctl start docker
docker run -d nginx
# Podman — runs directly with no daemon
podman run -d nginx
# When the container exits, its supervising process exits with it.
Why daemonless matters
Three reasons. 1) Security — dockerd runs as root and exposes a large attack surface. Having dockerd permissions effectively means having root. Podmans fork model removes the requirement for root. 2) Rootless containers — you can run containers as an unprivileged user. User namespaces map the in-container root to a regular user on the host. 3) systemd integration — one container is one systemd unit. podman generate systemd produces unit files automatically.
Buildah — the image builder
Podman doesnt build images itself. Buildah does. Buildahs two main strengths: 1) Scripted builds without Dockerfiles — combine buildah from, buildah run, buildah copy, and buildah commit to script builds procedurally. Powerful in CI pipelines. 2) Rootless builds — build images as a non-root user. Decisive in security-sensitive environments.
# Buildah script-style build
container=$(buildah from alpine:3.20)
buildah run $container -- apk add --no-cache python3
buildah copy $container app.py /app/
buildah config --cmd 'python3 /app/app.py' $container
buildah commit $container myapp:1.0
Skopeo — image transport
Skopeo moves images between registries. It does not run containers — it only manipulates images. 1) Registry-to-registry copy — skopeo copy docker://docker.io/nginx:latest docker://my-registry.com/nginx:latest. 2) Inspect images — read manifests without pulling. 3) Signature verification — integrates with Sigstore/Cosign. Standard for "examine without pulling" CI scenarios.
Podman Desktop The GUI released by Red Hat in 2022. In 2026 its on the 1.20.x line, and feature parity with Docker Desktop is close. Windows, macOS, Linux. Adds Kubernetes integration (Kind/Minikube), a migration wizard, and AI Lab (local LLMs). Free and open source (Apache 2.0).
Podmans weaknesses
- Not 100% Docker-compatible. Some Docker Compose options or network modes behave differently. You need
podman-composeor a Docker-compatible socket. 2) On macOS/Windows you still need a VM, which reduces the daemonless advantage on the host. 3) Tools expecting a Docker socket need a compatibility layer in front.
Chapter 4 · nerdctl — containerd With a Docker CLI
nerdctl is the official sister project of containerd. The name is "nerdy CLI for containerd." In 2026 its on the 2.x line, and it lets you use Docker-style commands as long as containerd is installed.
Why nerdctl exists
containerds own ctr is too low-level. You need three steps for a single run: ctr image pull → ctr container create → ctr task start. nerdctl exposes nearly the same commands as Docker and does the same thing.
# Docker
docker run -d -p 8080:80 --name web nginx:latest
# nerdctl — almost identical
nerdctl run -d -p 8080:80 --name web nginx:latest
# Docker Compose compatibility
nerdctl compose up -d
nerdctls strengths — what Docker cant do
- Lazy image pull —
nerdctl run --snapshotter=stargzstarts a container before the download completes. Dramatically reduces startup for large images. 2) Image encryption —nerdctl image encryptencrypts image layers. 3) Rootless — clean rootless support, comparable to Podman. 4) P2P image distribution — IPFS integration, eStargz format, and other experimental features.
Where nerdctl shows up
- As the default CLI for Lima, Colima, Finch, and Rancher Desktop. 2) Debugging on Kubernetes nodes when crictl is too coarse. 3) Direct container ops on servers that only have containerd.
Weaknesses
90% compatible with Docker CLI, but 10% behaves differently. --platform handling, certain --volume options, network-driver details. The Compose support via nerdctl compose doesnt cover every Docker Compose option.
Chapter 5 · Lima / Colima — The Linux VM Starting Point on Mac
Lima stands for "Linux on Mac." It started at LINE Corporation in Japan and is now a CNCF Sandbox project. In 2026 its past 1.0 and is the de facto standard for spinning up Linux VMs on macOS.
What Lima is Lima is not a container runtime. It is a tool that launches Linux VMs on macOS and lets a container runtime live inside them. Default backend is QEMU (x86) or Apple Virtualization Framework (arm64). The VM ships with containerd and nerdctl pre-installed.
# Install and start a default VM
brew install lima
limactl start
# Use nerdctl inside the VM
lima nerdctl run -d -p 8080:80 nginx
Limas strengths
- Declarative configuration — define a VM in YAML: cpus, memory, mounts. 2) Multiple VMs at once — separate VMs for Kubernetes clusters versus container development. 3) Automatic port forwarding — ports inside the VM are exposed to the host.
What Colima is Colima stands for "Containers on Lima." Its a wrapper that makes Lima usable as a single command. In 2026 its on the 0.8.x line. The point is to take Lima and give it Docker-Desktop-level UX for developers.
# One-line start with Colima
brew install colima docker
colima start --cpu 4 --memory 8
# Use the Docker CLI — Colima exposes a Docker-compatible socket
docker ps
docker run -d nginx
Colima vs. Lima directly Lima feels like a "VM tool" and Colima feels like a "Docker Desktop alternative." Colima auto-configures the Docker socket and offers a k3s option that brings up Kubernetes in one step.
# Start with Kubernetes via k3s
colima start --kubernetes --cpu 4 --memory 8
# kubectl picks up the context automatically
kubectl get nodes
Colimas strengths
- Completely free — MIT licensed, no company-size restriction. 2) Docker compatible — keep using the Docker CLI, swap the backend to containerd underneath. 3) k3s integration — Kubernetes in one command. 4) Multiple profiles —
colima start -p work,colima start -p personalfor context separation.
Colimas weaknesses
- No GUI — terminal only. 2) First boot takes 10-20 seconds, versus two seconds for OrbStack. 3) Filesystem sharing performance is average (virtiofs/sshfs-based). Noticeable on large monorepos. 4) No Windows support (Lima doesnt support Windows).
Chapter 6 · OrbStack — Commercial, Fast, Lightweight
OrbStack is a commercial Docker Desktop alternative launched in 2023. Built by one person (Danny Lin), with the company name OrbStack. macOS only. In 2026 its on the 1.10.x line. Paid commercial software, free for personal use, around 8 USD per user per month for business.
Why people love OrbStack Three reasons. 1) Fast — startup in two seconds, versus 30 to 60 for Docker Desktop. 2) Light — memory footprint roughly one-third of Docker Desktops. No pressure even on an M2 Air. 3) Smooth — filesystem sharing performance approaches native, thanks to a custom optimization layer above virtiofs.
What is technically different OrbStack (a) leans hard into Apple Virtualization Framework, (b) ships a custom-patched Linux kernel for optimal macOS filesystem sharing, and (c) treats Rosetta 2 for x86 containers as a first-class feature. It runs amd64 images on M1/M2/M3 Macs at near-native ARM speeds.
Features — Docker compatibility, Kubernetes, Linux machines
- Docker compatibility — Docker CLI works as-is. Compose, volumes, networks all behave like Docker Desktop. 2) Kubernetes — one toggle. K3s-based. 3) Linux machines — beyond containers, OrbStack hosts full Linux VMs: Ubuntu, Fedora, Debian, Arch, NixOS, all one command away.
# Use Docker commands as-is
docker run -d nginx
# Start a Linux VM
orb create ubuntu my-vm
orb -m my-vm # enter the VM
OrbStacks weaknesses
- Closed source + commercial. Enterprise adoption may hit policy issues. 2) macOS only. Linux/Windows users cant use it. 3) One-person dependency. If Danny leaves, the future shakes (as of 2026 there are announcements of team expansion). 4) Pricing is around 8 USD per user per month — comparable to Docker Desktop Business, slightly cheaper than Docker.
When to pick OrbStack
- Youre a Mac developer and free options feel sluggish. 2) The company is going to pay for Docker Desktop licenses anyway — OrbStack costs similar. 3) Youre running heavy local container workloads (video, ML inference, etc.).
Chapter 7 · Finch — AWSs Open-Source Integrated Bundle
Finch is AWSs open-source container tool, released in 2022. Named after the Galapagos finches (Darwin, evolution, diversity). In 2026 its on the 1.5.x line.
What Finch is Finch is not a new container runtime. Its a packaged bundle of existing open-source tools. Inside: 1) Lima — VM layer, 2) containerd — runtime, 3) nerdctl — CLI, 4) BuildKit — builder, 5) Soci-snapshotter — lazy-pull support. AWS integration-tests and packages the bundle.
# Install via Homebrew or the official .pkg
brew install --cask finch
finch vm init
finch vm start
# Commands are nearly identical to nerdctl
finch run -d -p 8080:80 nginx
finch compose up -d
finch build -t myapp .
Finchs strengths
- Fully free, open source (Apache 2.0). No company-size restriction, no licensing worries. 2) AWS integration — ECR auth, AWS-Fargate-compatible image building, all smoother. 3) Curated stack — Lima + containerd + nerdctl + BuildKit as a verified combination. 4) macOS, Windows, Linux all supported.
Finchs weaknesses
- No GUI. Frustrating if youre coming from Docker Desktop or OrbStack (as of May 2026, Finch Desktop is in beta development). 2) Lima-level startup speed — 10-20 seconds first boot. 3) Weak Kubernetes integration — not as seamless as Rancher Desktop or Colima. For k8s you need Kind or Minikube on the side.
When to pick Finch
- You work in the AWS ecosystem and ECR/Fargate are primary targets. 2) You want a "more officially supported" free tool than Colima. 3) Company policy makes you avoid closed tools (OrbStack) or Docker licenses. 4) Youre a Linux/Windows user.
Chapter 8 · Rancher Desktop — Optimal for Kubernetes Users
Rancher Desktop is SUSEs (who acquired Rancher Labs in 2020) open-source Docker Desktop alternative. In 2026 its on the 1.18.x line. Kubernetes-friendly is its signature.
Rancher Desktops signature Boot it and a k3s Kubernetes cluster boots alongside. kubectl is auto-configured. The Kubernetes version is selectable from the GUI with one click — 1.28, 1.29, 1.30, switch instantly.
Container engine choice A single GUI option toggles the container engine. 1) containerd + nerdctl — default. 2) dockerd + docker — if you want to keep using the Docker CLI directly.
# In nerdctl mode
nerdctl run -d nginx
# Switch to dockerd mode and keep using docker CLI
docker run -d nginx
# Kubernetes is always running alongside
kubectl get pods --all-namespaces
Rancher Desktops strengths
- Free, open source (Apache 2.0). No company-size restriction. 2) Kubernetes integration — k3s, kubectl, Helm bundled. 3) Engine choice — switchable between containerd and dockerd. 4) macOS, Windows, Linux all supported.
Rancher Desktops weaknesses
- Heavy — Lima plus k3s always running, baseline 8GB of memory. Heavy on an M2 Air. 2) Slow startup — 30+ seconds including k3s boot. 3) Overkill if you dont use k8s. For pure container development, Colima or Finch is lighter.
When to pick Rancher Desktop
- Kubernetes is your primary workflow. 2) You frequently switch k8s versions (multiple clients, multiple versions). 3) You want consistency with the Rancher/SUSE ecosystem. 4) You want a GUI but OrbStacks cost is a problem.
Chapter 9 · Podman Desktop Deep Dive — Daemonless With a GUI
Podman itself was covered in Chapter 3. This chapter zooms in on Podman Desktop — the GUI. In 2026 its on the 1.20.x line.
What Podman Desktop does
- Manages Podman machines (Lima- or WSL2-based VMs) through a GUI. 2) Visualizes containers, images, volumes, and networks. 3) Runs Compose files. 4) AI Lab — spin up local LLMs (Llama, Mistral, etc.) as containers, accessed via an OpenAI-compatible API. 5) Kubernetes — Kind/Minikube integration. 6) Docker Desktop Extension compatibility — some Docker Desktop extensions also run on Podman Desktop.
Podmans evolution — as of 2026
- Quadlet — declaratively define Podman containers as systemd units. Kubernetes-YAML-flavored systemd-native container orchestration. 2) Podman AI Lab — landed properly in 1.20. Model selection, quantization, inference containers, all in one place. 3) Kubernetes Play —
podman play kuberuns Pod YAML directly.
# Run a Pod YAML directly with Podman
podman play kube my-pod.yaml
# Reverse: generate Pod YAML from a running container
podman generate kube my-container > my-pod.yaml
Does Podman Desktop really replace Docker Desktop
- For straightforward container development — close to a full replacement.
- For Compose — compatibility layer exists, but some options behave differently.
- For policies that mandate daemonless/rootless — superior.
- On Windows — works well on WSL2, but setup is slightly more involved than Docker Desktops.
- On macOS — auto-starts an Apple Hypervisor machine, though its not as fast as OrbStack.
Chapter 10 · Apple Container Framework — What Native Containers on Mac Mean
Announced at WWDC in June 2025. Official name: Container Framework, package Apple.ContainerKit. As of May 2026, officially supported on macOS 15.4 and later, with the command container.
What Apple Container is Apples take: "Why do you need a separate VM manager to run Linux containers on macOS? Well build one ourselves." An OCI-compatible container runtime built on Virtualization.framework. The defining property: one micro-VM per container — every container gets its own Linux kernel.
# Install — bundled with macOS 15.4+
container --version
# Pull / run — Docker-like interface
container image pull docker.io/library/nginx:latest
container run -d -p 8080:80 nginx:latest
container ps
Apple Containers signature
- One micro-VM per container — strong kernel isolation between containers, similar to kata-containers. 2) Sub-second startup — Virtualization.frameworks optimizations. 3) Direct Mac hardware access — Neural Engine, GPU, and other accelerators exposed to containers. 4) OCI compatible — pull Docker Hub images directly.
Weaknesses — as of May 2026
- macOS 15.4+ only — useless on older macOS, Linux, or Windows. 2) Immature ecosystem — integration with Compose, Buildah, Skopeo still spotty. 3) Image build — BuildKit-compatible but some multi-stage builds have reported issues. 4) Kubernetes — k3s/minikube integration is beta.
The significance of Apple Container That Apple made containers an OS first-class citizen is itself a big deal. iOS/iPadOS expansion potential, Xcode integration (combined debugging of simulator and container), security-model consistency. In five years it is plausible that most macOS container users will run Apple Container by default. But as of May 2026 its still experimental and not as mature as OrbStack, Colima, or Finch.
Chapter 11 · Which Should Your Team Pick — Decision Tree
Putting the seven tools on the same axes — price, OS support, license, daemon presence, Kubernetes integration — looks like this.
| Tool | Price | OS | License | Daemon | k8s |
|---|---|---|---|---|---|
| Docker Desktop | 9-24 USD/mo (large co.) | Mac/Win/Linux | Commercial | dockerd | Kind separately |
| Podman Desktop | Free | Mac/Win/Linux | Apache 2.0 | None | Integrated |
| OrbStack | 8 USD/mo (business) | Mac only | Commercial | Proprietary | Integrated (k3s) |
| Colima | Free | Mac/Linux | MIT | None | k3s option |
| Finch | Free | Mac/Win/Linux | Apache 2.0 | None | Separate |
| Rancher Desktop | Free | Mac/Win/Linux | Apache 2.0 | None | Integrated (k3s) |
| Apple Container | Free | Mac only (15.4+) | Apple | None | Beta |
Scenario 1 — Solo Mac developer, wants free First pick: Colima. Light, MIT, Docker CLI passthrough. Second pick: Finch, smoother in the AWS ecosystem. If you want to experiment on macOS 15.4+: Apple Container.
Scenario 2 — Solo Mac developer, speed matters First pick: OrbStack. Two-second startup, light memory. Free for personal use. Second pick: Apple Container (macOS 15.4+).
Scenario 3 — Company, 50+ users, needs license cleanup First pick: Podman Desktop. Free, open source, enterprise-usable. Second: Finch or Rancher Desktop. If youre going to pay for Docker Desktop licenses, OrbStack is similar pricing but Mac-only.
Scenario 4 — Kubernetes learning / development First pick: Rancher Desktop. k3s integration, k8s version switching, kubectl/Helm bundled. Second: Colima --kubernetes, or OrbStacks Kubernetes toggle.
Scenario 5 — CI environment, no root, security-conscious First pick: Podman + Buildah. Daemonless, rootless, systemd integration. Second: nerdctl + BuildKit (rootless mode).
Scenario 6 — Windows developer First pick: Podman Desktop or Rancher Desktop. Both WSL2-based. Use when you want to avoid the Docker Desktop license. OrbStack and Apple Container are not options.
Scenario 7 — Truly heavy workloads (video / ML / large data) First pick: OrbStack (Mac) or Podman native (direct on Linux). Minimize VM overhead. Apple Container is also a candidate.
Scenario 8 — Company standardization, one tool for everyone First pick: Podman Desktop or Rancher Desktop. Three OS support, open source. Second: Finch, strong if AWS-friendly.
Decision checklist
- Company size and license — over Dockers 250-employee or 10M USD threshold? If yes, free options or OrbStack/Finch.
- Primary OS — Mac-only opens more choices. Need Linux/Windows too, and Colima drops off.
- Kubernetes weight — daily? Rancher Desktop or Colima+k8s.
- GUI need — if teammates arent CLI-comfortable: Podman Desktop, OrbStack, Rancher Desktop.
- Speed vs. cost — OrbStack is fast but paid for business. Colima/Finch are free but slow to start.
- Security policy — daemonless/rootless required: Podman.
- Long-term bet — Apple Container may become the macOS default in five years. Worth touching now.
Chapter 12 · References
Official docs and core resources for each tool. URLs verified live as of May 2026.
Container standards / runtimes
- OCI (Open Container Initiative): https://opencontainers.org/
- containerd: https://containerd.io/
- runc on GitHub: https://github.com/opencontainers/runc
- crun on GitHub: https://github.com/containers/crun
- CRI-O: https://cri-o.io/
Docker
- Docker official: https://www.docker.com/
- Docker Subscription Service Agreement announcement (2021-08-31): https://www.docker.com/blog/updating-product-subscriptions/
- BuildKit on GitHub: https://github.com/moby/buildkit
Podman / Buildah / Skopeo
- Podman: https://podman.io/
- Podman Desktop: https://podman-desktop.io/
- Buildah: https://buildah.io/
- Skopeo on GitHub: https://github.com/containers/skopeo
- Quadlet docs: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html
nerdctl
- nerdctl on GitHub: https://github.com/containerd/nerdctl
Lima / Colima
- Lima on GitHub: https://github.com/lima-vm/lima
- Colima on GitHub: https://github.com/abiosoft/colima
OrbStack
- OrbStack: https://orbstack.dev/
Finch
- Finch official: https://runfinch.com/
- Finch on GitHub: https://github.com/runfinch/finch
Rancher Desktop
- Rancher Desktop: https://rancherdesktop.io/
- Rancher Desktop on GitHub: https://github.com/rancher-sandbox/rancher-desktop
Apple Container Framework
- Apple Developer "Virtualization": https://developer.apple.com/documentation/virtualization
- WWDC25 "Meet Container Framework" session: https://developer.apple.com/videos/play/wwdc2025/
Other container builders
- kaniko on GitHub: https://github.com/GoogleContainerTools/kaniko
- ko on GitHub: https://github.com/ko-build/ko
Closing
Docker opened up container UX in 2013. That was a great accomplishment. Docker fractured the ecosystem in 2021 by charging for its product, and that fracture has grown seven distinct tools over five years. The result in 2026 is clear: more options, and container users win.
If I started a new project tomorrow, I would decide like this. Solo Mac developer: OrbStack (fast) or Colima (free). Company-scale: Podman Desktop or Rancher Desktop. AWS-centric: Finch. And touch Apple Container once a week to prepare for the future.
In five years this articles table will look different again. But the proposition — "Docker is not the standard, tool choice depends on team context" — is not retreating.
현재 단락 (1/245)
August 31, 2021. Docker Inc. announced the "Docker Subscription Service Agreement," declaring that D...