DEV Community

Chloe
Chloe

Posted on Originally published at smithchloe.hashnode.dev

Docker Alternatives in 2026: What to Use Instead (and When You Actually Need To)

#devops #docker #linux #tools

TL;DR

  • "Docker" is three layers: the runtime, the engine/CLI, and Docker Desktop. Most people only need to replace Docker Desktop.
  • On a Mac? OrbStack if $8/user/month is fine, or Colima if you want free and terminal-only.
  • Want free with a GUI, at any company size? Podman Desktop or Rancher Desktop.
  • Running Linux servers? Podman (daemonless, rootless). For minimal CI runners, nerdctl.
  • Your Dockerfiles, Compose files, and images keep working. OCI standards make switching low-risk.
  • Sometimes you don't need containers at all. There's a section on that below.

Docker didn't invent containers, but for a decade it basically was containers.

That started to change in 2021. Docker Inc. announced that Docker Desktop would require a paid subscription for commercial use at companies with more than 250 employees or $10M in revenue. Overnight, a lot of teams learned the difference between "Docker the format" and "Docker the product."

Five years later, the ecosystem has sorted itself out. You can keep your Dockerfiles, your docker compose habits, and your registry workflow, and swap out almost everything underneath. Here's what to swap in, grouped by what each tool actually replaces.

First: which Docker are you replacing?

"Docker" is three layers stacked on top of each other:

  1. The runtime (containerd + runc) creates and runs the containers. It's open source and shared by almost everyone, Kubernetes included.
  2. The engine and CLI is the docker command plus the daemon it talks to.
  3. Docker Desktop is the macOS/Windows app that bundles a Linux VM, a GUI, and the licensing that started all of this.

Most "I want a Docker alternative" requests mean layer 3. Some mean layer 2. Almost nobody needs to replace layer 1.

Figure out which layer you mean, and the choice gets much easier.

Engine and CLI alternatives

Podman

Podman is the most complete drop-in replacement for the Docker engine.

  • It's daemonless, so there's no long-running root process.
  • It's rootless by default. That's why security-focused teams and most Linux distros have moved to it.

The CLI mirrors Docker closely enough that a single alias covers most day-to-day work:

# macOS: Podman runs inside a small Linux VM
brew install podman
podman machine init
podman machine start

# Linux: install from your distro's package manager, no VM needed

alias docker=podman
docker run --rm -p 8080:80 nginx   # actually Podman
Enter fullscreen mode Exit fullscreen mode

Podman also has native pods: groups of containers that share a network namespace. It can generate Kubernetes YAML from running containers, which is handy if you're heading toward k8s anyway:

podman pod create --name web -p 8080:80
podman run -d --pod web nginx
podman kube generate web > web-pod.yaml
Enter fullscreen mode Exit fullscreen mode

Two sibling tools round it out:

  • Buildah builds images without a daemon.
  • Skopeo inspects and copies images between registries without pulling them.

Trade-offs: podman compose has improved a lot, but it still differs from Docker Compose on some edge cases. Some third-party tools also still expect a Docker socket at a fixed path.

nerdctl (containerd directly)

If you're happy to go one layer lower, nerdctl gives you a Docker-compatible CLI that talks straight to containerd. Many of the desktop tools below use it internally.

nerdctl run -d -p 8080:80 --name web nginx
nerdctl compose up -d
Enter fullscreen mode Exit fullscreen mode

You also get containerd features that Docker doesn't expose, such as lazy image pulling and image encryption. It's a great fit for Linux servers and CI runners where you want as few moving parts as possible.

Docker Desktop alternatives (macOS and Windows)

Most of the real choice happens here. On a Mac or a Windows machine you always need a Linux VM somewhere, and how that VM is managed makes a big difference to speed and battery life.

OrbStack (macOS)

OrbStack has effectively become the default on Mac. It's a commercial tool, but the performance gap is real:

  • It uses roughly a third of Docker Desktop's memory.
  • It starts in under two seconds.
  • File sharing and port forwarding work without configuration.
  • It can run full Linux VMs alongside containers, and it includes Kubernetes (via K3s). 
brew install orbstack
# your existing docker / docker compose commands just work
Enter fullscreen mode Exit fullscreen mode

It's free for personal use and $8/user/month for commercial use. That's cheaper than Docker Desktop, but not free for teams.

Trade-offs: macOS only, and closed source.

Colima (macOS and Linux)

Colima is the free, no-frills option. It's a thin wrapper around Lima that starts a VM running either the Docker engine or containerd, and you keep using your normal docker CLI.

brew install colima docker
colima start --cpu 4 --memory 8 --vm-type vz --mount-type virtiofs
docker ps
Enter fullscreen mode Exit fullscreen mode

It's terminal-only, and you'll tune CPU, memory, and mount type yourself. In return it's stable and fully open source.

Lima

Lima is the layer underneath Colima. It runs Linux VMs on macOS with automatic file sharing and port forwarding.

brew install lima
limactl start
lima uname -a
Enter fullscreen mode Exit fullscreen mode

Use it directly when you want full control over the VM, or several VMs running different runtimes. It isn't a container tool on its own, but many of the tools in this list are built on it.

Finch (AWS)

Finch is AWS's open-source bundle of Lima, containerd, nerdctl, and BuildKit. Think of it as a more opinionated Colima: one install, no daemon, and a finch command that works like docker.

brew install --cask finch
finch vm init
finch run --rm public.ecr.aws/finch/hello-finch
Enter fullscreen mode Exit fullscreen mode

It's a reasonable choice if you're an AWS shop and want a big vendor behind your tooling.

Rancher Desktop

Rancher Desktop is the pick for Kubernetes-first developers:

  • It's free and open source.
  • It has a GUI.
  • It runs a local k8s cluster that you can pin to the same version as production.
  • You can switch the runtime between containerd and the Docker engine. 
brew install --cask rancher
Enter fullscreen mode Exit fullscreen mode

It's heavier than the CLI tools because Kubernetes always comes along. If you live in kubectl anyway, that's a feature rather than a cost.

Podman Desktop

Podman Desktop is the GUI companion to Podman, now well into its 1.x releases with strong Red Hat backing. It manages containers, pods, images, and Kubernetes connections.

brew install --cask podman-desktop
Enter fullscreen mode Exit fullscreen mode

It's the natural choice if you already use Podman on Linux and want the same model on your laptop. Like Rancher Desktop, it's free at any company size and has a GUI.

Apple's container tooling (macOS)

This one is worth watching. At WWDC 2025, Apple open-sourced a native container CLI and a Containerization framework. Unlike everything else in this list, they run each container in its own lightweight VM, which isolates containers from each other more strongly.

container system start
container run --rm docker.io/library/alpine:latest echo hi
Enter fullscreen mode Exit fullscreen mode

It's still early, and the tooling around it is thin. Expect other tools to start building on it.

Sometimes you don't need a container at all

A lot of local Docker usage isn't really about containers. It's "I need Postgres plus some backend services running so I can develop." The Supabase local stack is a good example: about 12 containers and roughly 2.3 GB of Docker images, just to run your app's backend on a laptop.

If that's your situation, you can skip the container layer entirely. tinbase is an open-source, Supabase-compatible backend that runs as a single process:

npx tinbase start
Enter fullscreen mode Exit fullscreen mode 
import { createClient } from '@supabase/supabase-js'

// same SDK, pointed at the local process — no Docker
const supabase = createClient('http://127.0.0.1:54321', ANON_KEY)

const { data } = await supabase
  .from('todos')
  .select('*')
  .eq('done', false)
Enter fullscreen mode Exit fullscreen mode

What you get:

  • Real Postgres, with Row Level Security, Auth, Storage, and Realtime.
  • Your existing setup: it reads your supabase/migrations folder, and the official supabase-js SDK works unchanged.

Trade-off: it's alpha. That's fine for local dev and prototypes, but not production-ready yet.

The broader lesson goes beyond Supabase. Before you choose a Docker replacement, check whether the thing you're running actually needs to be a container.

Quick decision guide

You want... Use
Fastest, smoothest Mac experience, and $8/user/month is fine OrbStack
Free at any company size, with a GUI Podman Desktop or Rancher Desktop
Free, lightweight, terminal-only on Mac Colima
Local Kubernetes that matches production Rancher Desktop
Daemonless, rootless engine on Linux servers Podman
Minimal CI runners nerdctl + containerd
Full control over the VM Lima
Local Postgres backend, no containers A single-process alternative (see above)

One piece of advice

Whatever you pick, pick it as a team.

Five developers on five different local setups is a support burden that will quickly cost more than you saved on licensing. Agree on one tool, script the setup, and move on:

# scripts/setup-containers.sh
#!/usr/bin/env bash
set -euo pipefail
brew install colima docker docker-compose
colima start --cpu 4 --memory 8 --vm-type vz --mount-type virtiofs
docker context use colima
echo "✅ containers ready"
Enter fullscreen mode Exit fullscreen mode

And remember that none of this touches your Dockerfiles, your Compose files, or your images. OCI standards made this whole ecosystem possible, and they're why switching is much less scary than it sounds.

What's your team running locally in 2026? Did you leave Docker Desktop, or decide it was worth paying for? Drop it in the comments. I'm especially curious whether anyone has moved real workloads onto Apple's container yet. 👇

Top comments (0)