Docker alternatives: replacing the runtime and the base image

Docker isn't one product. It's a runtime, a desktop app, a registry, a build system, and, more recently, a catalog of secure base images. Most "Docker alternatives" lists only cover tools that replace how you build and run containers, like Podman, containerd, Rancher Desktop, and OrbStack.

This guide covers those tools, as well as alternatives to Docker's image-side products like Docker Hub and Docker Hardened Images, including secure base image catalogs from Chainguard, Bitnami, RapidFort, and Distroless.

The short version

Docker Desktop licensing: Start with Podman, Rancher Desktop, or OrbStack. They replace the desktop/runtime experience without forcing a base image change.

Linux runtime security: Start with Podman. It is rootless and daemonless on Linux, with a Docker-like CLI for common workflows.

Kubernetes runtime alignment: Start with containerd and nerdctl. It gives engineers and continuous integration (CI) jobs the same runtime that many Kubernetes clusters already use.

Mac local speed: Start with OrbStack. It is built for fast startup and low overhead on macOS, but commercial use is paid.

Scanner findings in base images: Start with Docker Hardened Images or Google Distroless. Both can be strong free baselines if you only need hardened images for a narrow set of workloads.

Audit-ready secure images at scale: Start with Chainguard Containers. It is built for source-built provenance, broad Federal Information Processing Standards (FIPS) coverage, and contractual Common Vulnerabilities and Exposures (CVE) remediation across every severity.

Which part of Docker are you replacing?

The table below breaks down each Docker product, what it does, whether it's free, and what alternatives are available.

How we evaluated these tools

We evaluated the tools in this guide using primary sources:

• Official documentation

• Project repositories

• Public pricing pages

• Vendor materials for the base-image claims

We also pulled from GitHub issues and community threads only when they pointed to a concrete limitation we could confirm somewhere else.

Disclosure: Chainguard Containers is our product, which gives us an obvious bias. We're confident it's the right call for audit-ready images at scale, but a comparison you can't trust isn't worth publishing. We’ve done our best to judge every tool on its own merits, so if Chainguard Containers isn’t a fit, one of the other tools here probably is.

Docker alternatives for running and building containers

Judge a runtime alternative on the things that actually bite you in production: whether it runs rootless (so a container escape lands as an unprivileged user, not host root), whether it runs daemonless (no long-lived privileged process brokering every container), how cleanly it speaks Open Container Initiative (OCI) and the Docker CLI (so your existing images and muscle memory carry over), its license, and its day-to-day engineering experience across Linux, macOS, and Windows.

Podman: best for rootless Linux containers

Quick facts

• Maintainer and license: Red Hat and the containers community / Apache 2.0

• Best fit: Linux servers, CI runners, and engineering teams removing Docker socket access

• Runtime model: Rootless and daemonless on Linux

• Docker fit: Docker-like CLI for common workflows; Compose and socket-dependent tooling need testing

• Platform note: macOS and Windows support runs through a Linux VM

Podman is the most direct Docker Engine alternative for teams that want familiar CLI commands and image semantics without the daemon model underneath. It preserves the same basic mental model (images, containers, volumes, registries, and familiar commands), while changing the security posture underneath.

On Linux, containers run as child processes rather than through one central root daemon. That makes Podman especially attractive for CI runners and locked-down hosts where mounting the Docker socket is a non-starter.

Beyond CLI compatibility, Podman has native pod support, can generate systemd units (or define them via Quadlet), and can export Kubernetes YAML, so local and CI workflows can look closer to the environments teams eventually deploy into.

Use Podman if you're replacing Docker Engine on Linux, removing privileged Docker socket access from CI, or standardizing on rootless container workflows. Before switching, test Dockerfile compatibility, Compose behavior, bind mounts, host networking, and any service that binds privileged ports.

Standout features

Rootless Linux containers

Podman's Linux default removes the assumption that every container workflow needs host-root privileges. That makes it a practical fit for CI runners, shared build hosts, and engineer laptops where Docker socket access creates risk.

Daemonless process model

On Linux, Podman runs containers as child processes instead of brokering every action through a long-lived root daemon. Security reviews get a cleaner failure model because there is no central privileged daemon to protect.

Docker-like workflow

Common docker run, docker build, and registry commands map closely enough that many teams can pilot Podman without retraining every engineer. The migration work usually sits in Compose behavior, networking, mounts, and socket-dependent tools.

Watch-outs

• Rootless containers cannot bind ports below 1024 by default; SUSE's rootless Podman docs document the limitation and the required host configuration.

• On macOS and Windows, Podman runs through a Linux VM, so "daemonless" mainly describes the Linux architecture.

containerd with nerdctl: best for Kubernetes runtime alignment

Quick facts

• Maintainer and license: Cloud Native Computing Foundation (CNCF) / Apache 2.0

• Best fit: Platform teams aligning local, CI, and Kubernetes runtime behavior

• Runtime model: Daemon-based container runtime

• Docker fit: Docker-style workflows through nerdctl, including Compose support

• Platform note: Strongest on Linux; desktop use usually means assembling more pieces

containerd is the runtime choice for teams that want local and CI environments to behave more like Kubernetes nodes. Docker itself uses containerd under the hood, and many Kubernetes clusters already run it directly, so this path is less about escaping Docker syntax and more about aligning the runtime layer across the stack.

nerdctl is what makes containerd realistic for teams that do not want to operate entirely at the Container Runtime Interface (CRI) layer. It adds a Docker-compatible CLI with Compose support, rootless mode, and BuildKit while exposing containerd capabilities Docker does not foreground.

It's a toolkit rather than a polished desktop app, so expect to assemble pieces yourself. Use it when runtime parity matters more than a GUI, and test rootless setup, Container Network Interface (CNI) networking, Compose compatibility, BuildKit integration, cache behavior, and engineering ergonomics before standardizing on it.

Standout features

Kubernetes runtime parity

containerd is already the runtime layer underneath many Kubernetes clusters. Using it in CI or local Linux environments can reduce the gap between how an image behaves during development and how it runs on a node.

nerdctl keeps familiar workflows

nerdctl gives engineers Docker-style commands, Compose support, and BuildKit integration without turning containerd into a desktop product. That makes the path usable for teams that want runtime alignment but do not want to work directly at the CRI layer.

Advanced image operations

containerd and nerdctl expose capabilities Docker Desktop does not foreground, including lazy image pulling, image encryption, image signing, and direct namespace work.

Watch-outs

• containerd is a daemon, so it is not the path for teams trying to eliminate daemon-based operation.

• It is more assembled than Docker Desktop: the nerdctl repo points users to nerdctl-full when they need dependencies such as CNI, BuildKit, and RootlessKit bundled together.

Rancher Desktop: best for free local Kubernetes

Quick facts

• Maintainer and license: SUSE / Apache 2.0

• Best fit: Engineers who need a free Docker Desktop replacement with local Kubernetes included

• Runtime model: Managed Linux VM with either Moby/dockerd or containerd

• Docker fit: Docker CLI support on the Moby backend; nerdctl on the containerd backend

• Platform note: macOS, Windows, and Linux

Rancher Desktop is the Docker Desktop alternative for teams that want containers and Kubernetes in the same local app. It's heavier than Podman or bare containerd because it bundles a managed VM, a local Kubernetes cluster, version switching, and a choice of engine.

The engine choice is the main decision. With the Moby backend, Rancher Desktop behaves more like Docker Desktop and supports the Docker CLI. With the containerd backend, engineers use nerdctl and get closer alignment with Kubernetes runtime behavior.

That flexibility is useful for platform teams, but it also means organizations need a standard configuration. Otherwise, every engineer ends up debugging a slightly different local stack.

Use Rancher Desktop when local Kubernetes is part of the workflow, not when you only need the lightest possible way to run containers. Before switching, test backend choice, Compose behavior, startup time, file sharing, port forwarding, Kubernetes version switching, and resource use on the machines your engineers actually use.

Standout features

Local Kubernetes built in

Rancher Desktop includes k3s, so engineers can test Helm charts, manifests, and controller behavior against a real local cluster instead of installing a separate cluster manager.

Moby or containerd backend

Pick Moby if you want Docker CLI compatibility and the closest feel to Docker Desktop. Pick containerd if you'd rather run the same runtime as your Kubernetes clusters and are fine using nerdctl instead.

Free cross-platform desktop app

Rancher Desktop is free, open source, and works the same way on macOS, Windows, and Linux. For shops with mixed workstations, that means one tool to support instead of a different setup per operating system.

Watch-outs

• It is heavier than a plain runtime because Kubernetes is built in through k3s, not added only when needed.

• Docker CLI compatibility depends on using the Moby backend; Rancher Desktop's docs describe nerdctl as the CLI for the containerd backend.

OrbStack: best for fast macOS development

Quick facts

• Maintainer and license: OrbStack / proprietary

• Best fit: Engineering teams on macOS that value local speed and polish

• Runtime model: macOS-native app with Docker containers, Linux machines, and Kubernetes

• Docker fit: Designed for Docker-compatible CLI and socket workflows

• Platform note: macOS only

OrbStack is a macOS-native app for running Docker containers, lightweight Linux machines, and Kubernetes. On a Mac it starts faster and uses less memory and disk than Docker Desktop.

It fits best when your engineers are on Apple Silicon and the main complaint is that Docker Desktop feels slow or heavy. It is the wrong fit if you need one standard across macOS, Windows, and Linux, or if you require open source tooling, because OrbStack runs only on macOS and ships under a paid proprietary license.

Before committing, test Docker CLI and socket compatibility, volume mounts, file-heavy workflows, Kubernetes behavior, and how licensing applies to employees, contractors, and commercial use.

Standout features

macOS performance

Built only for macOS, OrbStack optimizes for fast startup, quick file sharing, low resource use, and responsive Linux machine management on Apple Silicon.

Docker-compatible workflows

OrbStack supports the standard Docker CLI and socket workflows, so on macOS it can usually slot in where Docker Desktop was without rewriting scripts or retraining engineers.

Linux machines and Kubernetes

Beyond containers, OrbStack can also run lightweight Linux machines and a local Kubernetes cluster from the same app, so it works as a full local environment rather than only a container runtime

Watch-outs

• OrbStack is positioned as a Docker Desktop alternative for macOS, so it will not standardize Windows and Linux workstations.

• It is a paid commercial product rather than an open source project; OrbStack pricing lists a paid business and commercial use tier.

LXC, LXD, and Incus: best for persistent Linux system containers

Quick facts

• Maintainer and license: LinuxContainers and Canonical history; Incus is the community fork of LXD

• Best fit: Linux teams that need persistent, OS-like environments

• Runtime model: System containers and virtual machines, not Docker-style app containers

• Docker fit: Not a Docker CLI or Compose replacement

• Platform note: Linux-focused

Docker popularized short-lived application containers. LXC-style tooling is built around system containers: long-lived, OS-like environments that behave more like lightweight virtual machines than single-process app packages.

A platform team running Incus or LXD manages system containers and virtual machines from one control plane, with snapshots, storage pools, and networking primitives built for environments that stay up long-term.

It is not a drop-in Docker Desktop replacement. If your team works in Dockerfiles, Compose, and docker run, start with one of the runtimes above. If you need persistent Linux environments you manage like machines, test Incus or LXD against the things that actually break: networking, storage, snapshots, lifecycle operations, and whether the license terms clear your review.

Standout features

OS-like system containers

LXC, LXD, and Incus are built for persistent Linux environments, not single-process application packages. They are useful when a team wants a lightweight machine boundary with init systems, services, and long-lived state.

VM and container management together

With Incus or LXD, a single CLI and API drive both system containers and full virtual machines, so you don't bolt a separate hypervisor onto a container runtime to run a mixed fleet. Infrastructure labs, edge nodes, and internal platform sandboxes tend to need exactly that mix, where some workloads want a container and others need a full VM.

Infrastructure lifecycle primitives

Snapshots, storage pools, profiles, and managed networking are built into Incus and LXD rather than bolted on. You can snapshot a system container before a risky change and roll it back, reuse a profile to stamp out identical machines, and define storage and networks the way you would for long-running infrastructure instead of a throwaway app container.

Watch-outs

• LinuxContainers' Incus documentation describes a system container and VM manager rather than a Docker-compatible desktop runtime.

• LXD moved under Canonical and added AGPLv3/CLA requirements in 2023, as documented in the

  Linux Containers forum announcement.

• If license posture is the concern, validate Incus separately against its LinuxContainers project docs.

Buildah and BuildKit: best for CI image builds without Docker runtime

Quick facts

• Maintainer and license: Buildah is from the containers ecosystem; BuildKit is from Docker's Moby project / Apache 2.0

• Best fit: CI pipelines that want to reduce Docker daemon dependency during image builds

• Runtime model: Build tools only; neither runs containers as a Docker Desktop replacement

• Docker fit: Dockerfile-oriented workflows need compatibility testing

• Platform note: Strongest in Linux build environments

Buildah and BuildKit cover only the build part of Docker, not running containers. Buildah is a genuine non-Docker build tool, and while BuildKit is Docker's own build engine, it can also run standalone, decoupled from the Docker daemon and Docker Desktop. Either way, both let you move image building out of a full Docker runtime, which pays off most in CI pipelines where the risky or expensive dependency is building images through a privileged daemon.

Buildah works well when the goal is daemonless, scriptable OCI image creation. It pairs naturally with Podman and gives teams fine-grained control over image assembly.

BuildKit is the fit when build speed matters most. Parallel execution, stronger caching, and multi-platform builds pay off in high-volume pipelines, even though BuildKit itself still runs as a daemon.

Most teams end up using both, just in different pipelines: Buildah, where they want daemonless, scriptable builds, and BuildKit, where caching and speed matter most. Before moving any builds off Docker, test Dockerfile compatibility, multi-stage builds, build arguments, layer caching, registry auth, and signing, and check whether engineers still need Docker Desktop locally even if CI no longer does.

Standout features

Daemonless OCI builds with Buildah

Buildah lets CI pipelines build Open Container Initiative (OCI) images without routing the work through the Docker daemon. That is the cleanest fit when the policy goal is reducing privileged daemon exposure during builds.

Faster cache-heavy builds with BuildKit

BuildKit is for teams that need better caching, parallel execution, and multi-platform output. It is Docker's own build engine rather than a competitor to it, so the move here is running it standalone, pointed at CI, where it can make high-volume build pipelines much faster without depending on a full Docker install.

CI pipeline flexibility

You can move image building off Docker without changing the runtime engineers use locally. Developers keep their Docker-compatible workflows, while CI builds images under a tighter security posture.

Watch-outs

• Neither is a container runtime. Buildah's docs describe it as a tool for building OCI images, and

  Docker's BuildKit docs describe BuildKit as the builder backend used by Docker.

• BuildKit typically runs through buildkitd; Docker's BuildKit docs explicitly include starting the BuildKit daemon.

None of these tools decides what goes inside your images. You still pull a base image from a registry, and that image is where most of your vulnerabilities, your compliance gaps, and your missing audit evidence come from.

Docker alternatives for securing base images

Docker Hardened Images is the obvious starting point: its free Community tier gives you the full catalog, SBOMs, SLSA Build Level 3 provenance, and signed images at no cost. You outgrow the free tier when DHI doesn't carry an image you need, an audit asks about your whole vulnerability backlog, FIPS becomes a hard requirement, or remediation is too slow to unblock releases. That's when a dedicated catalog is worth the move.

When you compare secure image catalogs, five things actually separate them:

• Remediation: Is there a contractual Service Level Agreement (SLA)? Which severities and layers does it cover?

• Evidence: Do images ship SBOMs, signatures, and Supply-chain Levels for Software Artifacts (SLSA) provenance?

• Compliance: Are Federal Information Processing Standards (FIPS) and Security Technical Implementation Guides (STIGs) variants available for the images you need?

• Coverage: Is catalog size measured in distinct images, not version tags?

• Build model: Are images built from source on a controlled base or hardened from an upstream distribution?

Chainguard Containers: best for audit-ready, secure images at scale

Quick facts

• Vendor: Chainguard

• Best fit: Security, platform, and compliance teams that need remediation ownership across a broad catalog

• Catalog model: Enterprise secure image catalog with 2,000+ images

• SLA model: Seven days for critical CVEs; 14 days for high, medium, and low CVEs

• Build model: Source-built on Chainguard OS with SBOMs, SLSA Level 3 provenance, and Sigstore signatures

Chainguard Containers is for teams who need to secure the whole image supply chain over time. Every image is built from source on Chainguard’s own OS, backed by contractual remediation that covers the entire image, and shipped with the signed provenance and FIPS variants auditors ask for.

Use Chainguard Containers when scanner findings, audit evidence, FIPS coverage, and remediation ownership stop being one-off cleanup tasks and turn into recurring business problems. At that scale, you need a catalog someone is contractually responsible for keeping patched across every severity, with the source-built provenance and FIPS variants your auditors already ask for, rather than a base image your own team hardens and re-hardens release after release.

Standout features

Built from source on Chainguard's own OS

DHI, Bitnami, and RapidFort harden or debloat upstream distros (Debian, Alpine, PhotonOS) they don't maintain, so a layer of the supply chain stays outside their control. Chainguard builds every image from source on Chainguard OS and rebuilds it daily to provide a zero-CVE starting point and verifiable provenance from source to registry. Every image is shipped with signed SBOMs, SLSA Level 3 provenance, and Sigstore signatures.

A remediation SLA that covers the whole image

Chainguard’s contractual SLA (24 hours for Known Exploited Vulnerabilities (KEVs), seven days for critical, and 14 for everything else) covers every layer of the image, including the OS base, with measured critical fixes well under a day. Other vendors either gate remediation on upstream distros they don't control, leave the OS layer out, or defer CVEs based on upstream decisions, which is exactly where audit backlogs pile up.

Audit evidence and compliance at catalog scale

Chainguard pairs 3,000+ source-built images with its own CMVP-validated, kernel-independent FIPS module and 700+ FIPS variants, so platform and compliance teams can standardize FIPS, STIG, and FedRAMP-ready images across the whole estate instead of clearing one image family at a time.

Customer proof

• Anduril now meets its zero-CVE mandate across a rapidly growing estate of container images.

• Appian reached Federal Risk and Authorization Management Program (FedRAMP) accreditation in a few months rather than its original estimate of more than a year.

Watch-outs

• Chainguard’s free plan, Catalog Starter, is limited to five images and does not include FIPS variants, so depending on your organization’s needs, it might not provide enough coverage. Even so, it is a fast way to get started with hardened container images. You can create a free account in minutes.

Bitnami Secure Images: best for existing Bitnami users

Quick facts

• Vendor: Broadcom/VMware

• Best fit: Teams already standardized on Bitnami images or Helm charts

• Catalog model: Paid production catalog with a development-only free subset

• Evidence: SBOMs, SLSA Level 3, and Vulnerability Exploitability eXchange (VEX) data

• Compliance: FIPS support through VMware cryptographic modules

Teams that adopted Bitnami charts years ago may have dozens of manifests, values files, and runbooks built around Bitnami image names. For those teams, the choice is whether to pay for the secure Bitnami path or migrate off a catalog they already depend on.

Many organizations have already begun searching for a Bitnami alternative after Broadcom moved free versioned images to a frozen bitnamilegacy registry and limited the free catalog to dev-only latest tags.

Bitnami Secure Images makes sense if you still have meaningful Bitnami dependencies. Start with an inventory: which bitnami/* images are in production, which tags are pinned, which charts depend on them, and which workloads need a paid migration path.

Standout features

Existing Kubernetes app gravity

Bitnami's biggest advantage is the installed base. If your charts, runbooks, and manifests already depend on bitnami/* images, the secure-image decision includes migration cost, not just catalog features.

Enterprise evidence package

Bitnami Secure Images include SBOMs, SLSA Level 3 provenance, and Vulnerability Exploitability eXchange (VEX) data. That combination can help teams answer scanner and audit questions without abandoning familiar application images.

VMware FIPS module support

Bitnami's FIPS story runs through VMware cryptographic modules. That could be a procurement advantage for teams already standardized on Broadcom or VMware, but it should be validated against the exact images and hosts in scope.

Watch-outs

• The Bitnami containers announcement issue says existing versioned tags moved to

  bitnamilegacy; the free images are intended for development and only available on the

  latest tag.

• Broadcom's Bitnami Secure Images SLA article says remediation consists of publishing an updated image that includes the upstream fix, so validate OS-layer commitments in the contract before treating the SLA language as all-layer coverage.

• Broadcom's Bitnami page routes buyers to contact sales, so budget validation requires a sales conversation.

RapidFort: best for debloating existing upstream images

Quick facts

• Vendor: RapidFort

• Best fit: Teams that want to optimize and harden images they already run

• Catalog model: Curated and optimized images with scanner-driven hardening

• Compliance: Messaging around FIPS, STIG, Federal Risk and Authorization Management Program (FedRAMP), Cybersecurity Maturity Model Certification (CMMC), System and Organization Controls (SOC) 2, and SBOM generation

• Decision point: Validate rebuild model, provenance details, and contract terms directly with the vendor

RapidFort takes a different route from source-built catalogs. Its core pitch is that you can reduce the attack surface by adopting curated hardened images across familiar long-term support Linux distributions.

The evaluation question is how much supply-chain ownership you need. If optimization and compliance coverage are enough, RapidFort may suit your needs. If you need a from-source image catalog with detailed provenance and contractual remediation terms, ask for contract language and implementation details so you can compare it directly with source-built catalogs.

RapidFort is a viable option when you want to harden existing image families. If considering RapidFort, you should verify whether the images you need are distinct maintained repositories or mostly version/tag variants, whether each target image is rebuilt from source or hardened from upstream, and whether the platform fits your CI and delivery model.

Standout features

Image debloating

RapidFort's approach is to reduce what ships inside the image. That can lower scanner noise and attack surface when teams are not ready to move away from the upstream image families they already run.

Predictable hardening workflow

RapidFort emphasizes deterministic builds, hardening, SBOM generation, FIPS-validated cryptography, and a predictable patch cadence. That workflow fits teams whose immediate problem is image hygiene rather than adopting a new source-built catalog.

Compliance-oriented catalog

RapidFort positions its hardened images around regulated-market frameworks like FIPS, STIG, FedRAMP, and CMMC. For federal and compliance-heavy buyers, that focus is its clearest draw.

Watch-outs

• RapidFort's public positioning centers on curated and optimized images; validate whether a given image is rebuilt from source or hardened from an upstream base before comparing it to source-built catalogs.

• If a contractual remediation SLA is a purchase requirement, ask RapidFort for the contract language; RapidFort's secure-container-images page advertises rapid fix and rebuild targets, but public marketing language is not the same as contract terms.

• Treat large catalog counts carefully and distinguish distinct repositories, images, and version variants when reviewing the RapidFort catalog.

Google Distroless: best for free minimal language runtime images

Quick facts

• Maintainer and license: GoogleContainerTools project / Apache 2.0

• Best fit: Teams that want a free, minimal language runtime base

• Catalog model: Focused language-based images, not a broad application catalog

• Evidence: cosign signatures; verify SBOM and provenance expectations against project docs

• Security model: Tracks Debian for distro-level fixes

Google Distroless is the original minimal-image answer: ship the application and runtime dependencies, but leave out the shell, package manager, and general-purpose OS tooling attackers love and scanners report on. For many teams, that is enough. A smaller image with fewer packages can reduce scanner noise and production attack surface without adding a vendor relationship.

Distroless is strongest for straightforward language-runtime workloads. Java, Python, Node.js, Go, static, base, and cc images cover many common services, and the project is easy to test because it is free and open source.

The tradeoff is operational. Debugging minimal images takes discipline because the tools engineers expect inside a container often are not there.

The strategic limit is that Distroless is a focused open source project, not a commercial secure-image catalog. It tracks Debian for distro-level fixes and does not give buyers a remediation contract, broad application-image coverage, or FIPS catalog.

Use Distroless when you want the cleanest free minimal baseline for language services. Verify runtime coverage, debugging expectations, certificate authority and timezone needs, Debian-tied remediation timing, cosign signature verification, and whether project-level security policy is enough for your reviewers.

Standout features

Minimal runtime surface

Distroless removes the shell, package manager, and general-purpose OS tooling that many production services do not need. That smaller surface can reduce scanner findings and make runtime behavior easier to reason about.

Free language-runtime bases

The catalog focuses on common language and runtime bases rather than broad application coverage. It is a strong fit for services where the team controls the application layer and only needs a clean runtime base.

Signed images without a vendor contract

Distroless images are signed with cosign, which gives teams stronger verification than an unsigned community image. The tradeoff is that remediation follows the open source project and Debian security model, not a commercial SLA.

Watch-outs

• Distroless tracks Debian for distro-level security fixes; its GitHub security policy

  points to Debian package versions for the current build.

• It is a focused language-based project, not a broad application-image catalog; validate coverage against the

  Distroless image list.

• The Distroless security policy is project-level security guidance, not a commercial remediation SLA.

Five questions to answer before you switch

Is Docker still free?

Mostly, with one exception. Docker Engine, the runtime, is free and open source. Docker Hub and Docker Scout have free tiers with limits. Docker Hardened Images has a free, open source Community tier. The only piece that requires payment for larger organizations is Docker Desktop, the GUI app, for companies with more than 250 employees and more than $10 million in annual revenue. Both thresholds must apply.

Do I have to choose one or the other?

No, and most teams change one at a time. The runtime and the base image are independent choices. You can keep Docker Engine and swap to Chainguard Containers, or move to Podman and keep pulling community-based images. Pick the decision that is causing you pain first.

Can I run secure base images on a non-Docker runtime?

Yes. Every base image catalog ships standard OCI images, so a Chainguard container image, DHI, Bitnami, or Distroless image runs unchanged on Podman, containerd, or any OCI-compliant runtime. The base image and the runtime never need to come from the same vendor.

If Docker Hardened Images are free now, why pay for a catalog?

For many teams, you should not, and a free hardened image is the right starting point. The reasons to pay show up at scale and under audit: a contractual SLA that covers every severity, from critical to low, FIPS validation across a broad catalog, images for software the free catalogs do not carry, and a source-built provenance chain. If none of those apply to you, free is the correct answer.

What about Docker Hub itself, or Compose?

Those are separate swaps. For the registry, Harbor, Quay, GitHub Container Registry, and cloud registries such as Amazon Elastic Container Registry, Azure Container Registry, and Google Artifact Registry are the common moves. For Compose, both podman compose and nerdctl compose read existing Compose files, though complex files can need adjustment.

Address your sharpest pain first

The fastest way to make progress is to stop treating "Docker alternatives" as a single shopping trip.

If Docker Desktop licensing is the pain, solve the runtime problem first. Podman, Rancher Desktop, and OrbStack can close that gap without touching your base images.

If scanner findings are blocking releases, start with one base image. Pull a hardened equivalent, rerun your scanner, and see whether a free baseline is enough.

That test will tell you whether you only need a cleaner image today, or whether you need someone contractually responsible for keeping it patched across every severity. If that second problem is the real one, pull the Catalog Starter equivalent of your most-flagged image and compare the result.

This guide reflects product details, pricing, and availability as of June 2026. Container tooling moves fast, so verify current specs, license terms, and SLAs in each vendor's official docs before you decide.