--- title: 'Podman vs Docker: The 2026 Container Showdown' description: 'Podman vs Docker in 2026: daemon-less and rootless containers, Kubernetes compatibility, migration steps, and when each wins on security or DevOps workflow.' url: https://nerdleveltech.com/podman-vs-docker-the-2025-container-showdown language: en date: '2025-10-13' category: cloud-devops tags: - Podman - Docker - Containers - DevOps - Kubernetes - Rootless - Security - Cloud markdown_url: https://nerdleveltech.com/podman-vs-docker-the-2025-container-showdown.md attribution: 'Source: NerdLevelTech — https://nerdleveltech.com/podman-vs-docker-the-2025-container-showdown' terms: https://nerdleveltech.com/llms.txt --- # Podman vs Docker: The 2026 Container Showdown ## Introduction Containers have become the backbone of modern DevOps. They've changed how we build, ship, and run software across every environment—from local development to massive cloud deployments. For years, **Docker** has been the de facto standard, the tool that made containerization accessible to everyone. Its simple commands and consistent behavior turned containers from a Linux kernel curiosity into a mainstream development practice. But as the ecosystem matures, new players are challenging the old assumptions about how containers should run. Enter **Podman**—a daemon-less, rootless alternative that's been quietly gaining traction among developers and enterprise teams. By 2026, Podman has grown from a niche Red Hat project into a serious contender for production workloads. With Podman 6.x as the current stable line[^podman-version] and Podman Desktop accepted into the CNCF Sandbox in January 2025[^podman-desktop-cncf], it addresses security concerns that Docker's architecture makes difficult to solve, while maintaining near-perfect CLI compatibility. This post is a deep dive into **Podman vs Docker**: how they differ under the hood, how their command-line interfaces align, what they mean for orchestration and image management, and which one might be the better fit for your workflows going forward. Let's unpack the real differences. --- ## The Container Landscape in 2026 Before we zoom in on Podman and Docker, it's worth remembering how we got here. ### Docker's Revolution Docker didn't invent containers, but it made them usable. It abstracted away the messy Linux primitives—namespaces, cgroups, and union file systems—into a clean developer experience. The `docker run` command became shorthand for modern software deployment. Within a few years, Docker transformed from a niche Linux tool into the foundation of cloud-native development. ### Evolving Requirements But as containerization matured, so did the expectations: - **Security:** Running containers as root became a major concern, especially for regulated industries - **Compliance:** Enterprises needed auditable, policy-driven container runtimes that could pass security audits - **Composability:** Developers wanted modular tools that integrated cleanly with Kubernetes and CI/CD pipelines - **Multi-tenancy:** Shared development servers needed better isolation between users ### The Daemon Problem Docker's architecture, built around a central daemon, started to feel like a constraint. The daemon requires root privileges, creates a single point of failure, and makes per-user isolation difficult. Podman emerged to solve exactly that. By eliminating the daemon entirely, it addresses security concerns that Docker's architecture makes difficult to fix without breaking backward compatibility. --- ## Architecture: Daemon vs Daemon-less The biggest philosophical and technical difference between Docker and Podman lies in their architecture. ### Docker’s Daemon Model Docker uses a **client–server model**. The Docker CLI communicates with the **Docker daemon** (`dockerd`), a background service that handles everything—building images, managing containers, networking, logging, and more. This design simplifies things for developers, but it comes with trade-offs: - **Single point of failure:** If the daemon crashes, all running containers are affected. - **Root privileges:** The daemon typically runs as root, meaning a compromise in one container could potentially escalate privileges. - **Centralized control:** All container operations funnel through the daemon, which can create bottlenecks in multi-user systems. ### Podman’s Daemon-less Model Podman flips that model completely. There’s **no central daemon**. Each container runs as a child process of the user who created it. The Podman CLI interacts directly with the container runtime (usually **runc** or **crun**) through **libpod**, a library that manages container lifecycles. Key advantages: - **No background service:** Start containers without a persistent daemon. - **Better isolation:** Each user runs containers under their own UID. - **Rootless by design:** You can run containers without root privileges. This difference might seem subtle, but it's transformative for security and compliance. Podman's architecture aligns naturally with the principle of least privilege. --- ## Quick Comparison Table To help you understand the key differences at a glance, here's a side-by-side comparison: | Feature | Docker | Podman | |---------|--------|--------| | **Architecture** | Client-server with daemon | Daemon-less, fork-exec model | | **Root requirement** | Daemon runs as root by default | Fully rootless capable | | **Background service** | Yes (dockerd) | No | | **CLI compatibility** | Docker commands | Docker-compatible commands | | **Pod support** | No native pods | Native pod support | | **Kubernetes integration** | Via containerd/CRI-O | Direct YAML generation | | **Image format** | OCI-compliant | OCI-compliant | | **Desktop app** | Docker Desktop (commercial) | Podman Desktop (open source) | | **Systemd integration** | Limited | Native support | | **Multi-user isolation** | Limited (shared daemon) | Strong (per-user containers) | | **Licensing** | Free tier + commercial | Fully open source (Apache 2.0) | This table highlights the architectural and functional differences that impact your choice of container runtime. --- ## Rootless Containers and Security Security is where Podman really shines. ### Why Rootless Matters In Docker, even if you run a container as a non-root user inside the container, the daemon itself often runs as root on the host. That means the daemon has full system access. If an attacker escapes the container, they could potentially gain root access to the host. This privilege escalation risk has been demonstrated in real-world container breakouts. Podman avoids this entirely. When you run a container rootlessly with Podman, it uses **user namespaces** to map container root to an unprivileged user on the host. In other words, root inside the container isn't root outside. An attacker who breaks out of a rootless Podman container gains only the privileges of the user who started the container—typically a non-privileged account. This design drastically reduces the attack surface and makes container security more defense-in-depth. ### Enterprise Compliance Benefits For organizations subject to strict compliance frameworks (e.g., FedRAMP, PCI-DSS), this rootless architecture simplifies audits. There’s no privileged daemon to monitor or lock down. Podman also integrates neatly with **SELinux** and **AppArmor** profiles, giving admins granular control over container permissions. --- ## CLI Compatibility: The Familiar Experience If you’ve ever used Docker, Podman’s CLI will feel instantly familiar. That’s intentional. Podman was designed to be a **drop-in replacement** for Docker in most workflows. In fact, many commands are identical: ```bash # Docker $ docker run -d -p 8080:80 nginx # Podman $ podman run -d -p 8080:80 nginx ``` Even Docker Compose workflows can be adapted using **Podman Compose**, a compatible tool that interprets `docker-compose.yml` files. ### Aliasing for Seamless Transition One of the neat tricks developers use is aliasing Docker commands to Podman: ```bash alias docker=podman ``` This lets you continue using muscle memory while benefiting from Podman’s security model. ### Subtle Differences Despite the CLI parity, there are a few differences worth noting: - Podman doesn’t require a daemon to be running. - Commands like `podman ps` only show containers started by the current user (unless root). - Networking and volume handling differ slightly due to the lack of a central daemon. Overall, the learning curve for Docker users is minimal. --- ## Image Handling and Registries Both Docker and Podman rely on the **OCI (Open Container Initiative)** image format. That means images built with one can generally run on the other. ### Building Images Docker uses the `docker build` command, which relies on the daemon to process the build context. Podman uses **Buildah** under the hood for builds. Buildah is a separate tool (though tightly integrated) that allows for rootless image creation. Example: ```bash podman build -t myapp:latest . ``` Podman’s build process can run entirely in user space, aligning with its rootless philosophy. ### Registry Compatibility Podman can push and pull images from any OCI-compliant registry, including Docker Hub, Quay.io, and private registries. ```bash podman pull docker.io/library/alpine:latest ``` If you’re migrating from Docker, your existing image repositories will continue to work. ### Image Storage Differences Because Podman runs rootless, each user has their own image store. This can be advantageous for multi-user systems but might require extra disk space if multiple users pull the same image. Docker, by contrast, shares a single image store managed by the daemon. --- ## Pods: Podman’s Native Concept Here’s where Podman introduces something unique: **pods**. If you’re familiar with Kubernetes, the concept will sound familiar. A pod is a group of containers that share the same network namespace and can communicate over localhost. Docker doesn’t have a native pod abstraction—each container typically gets its own network namespace. ### Why Pods Matter Pods make it easier to model multi-container applications that mirror Kubernetes deployments. For example, you might have an app container and a sidecar logging container running in the same pod. Example: ```bash podman pod create --name mypod -p 8080:80 podman run -d --pod mypod nginx podman run -d --pod mypod redis ``` Now both containers share the same network stack, simplifying communication. This makes Podman an excellent tool for **Kubernetes-native development**—you can prototype locally using pods, then deploy seamlessly to a cluster. --- ## Orchestration and Integration Docker’s orchestration story has evolved over time. Docker Swarm once played that role, but by 2026, Kubernetes dominates the orchestration landscape. ### Docker and Kubernetes Docker used to integrate directly with Kubernetes through the **dockershim**, but it was deprecated in Kubernetes 1.20 and removed entirely in Kubernetes 1.24 (April 2022)[^dockershim]. Modern Kubernetes uses **containerd** or **CRI-O** as the CRI runtime — though Mirantis maintains `cri-dockerd` for clusters that still want to talk to the Docker Engine. While Docker Desktop still offers a convenient local Kubernetes environment, it’s not part of production Kubernetes anymore. ### Podman and Kubernetes Podman integrates more natively with Kubernetes concepts. You can generate Kubernetes YAML directly from running containers or pods. The current syntax in Podman 5.x is `podman kube generate` (the older `podman generate kube` form still works as an alias): ```bash podman kube generate mypod > mypod.yaml ``` That YAML can then be applied directly to a cluster: ```bash kubectl apply -f mypod.yaml ``` This makes Podman a powerful tool for developers who want to build and test locally before pushing to production clusters. ### Systemd Integration Another neat feature: Podman can run containers as systemd services, letting you manage them as traditional Linux services. The historical workflow used `podman generate systemd`, which still works: ```bash podman generate systemd --name myapp > /etc/systemd/system/myapp.service ``` However, `podman generate systemd` is **deprecated** in modern Podman. The recommended replacement is **Quadlets** — declarative `.container`/`.pod`/`.kube` unit files placed under `~/.config/containers/systemd/` (rootless) or `/etc/containers/systemd/` (rootful), which systemd's generator turns into services on the fly[^quadlets]. Either way, this bridges the gap between containers and conventional server management. --- ## Performance Considerations Performance between Docker and Podman is generally comparable since both rely on similar underlying runtimes (runc, crun). However, there are subtle differences worth understanding. ### Startup Times Podman can sometimes start containers faster because it doesn't need to communicate with or wait for a daemon. The direct fork-exec model means less overhead for cold-start container operations. Public benchmarks vary widely — some report Podman with double-digit cold-start advantages (especially with the **crun** runtime), while others find Docker slightly faster on warm starts because its always-running daemon keeps state cached[^perf-benchmarks]. In practice, the gap depends on the runtime (`runc` vs. `crun`), image size, and host filesystem more than the management tool itself. ### Resource Usage Without a long-running daemon, Podman consumes fewer background resources. Reported figures for the Linux Docker daemon's idle memory typically land in the 300–400MB range[^docker-daemon-ram], and Docker Desktop on macOS or Windows can sit several gigabytes higher because it runs containers inside a Linux VM. This difference matters on lightweight systems, CI runners, or environments where every megabyte counts. For developers running containers on laptops, Podman's lighter footprint can extend battery life. ### Build Performance Docker's daemon-based build can sometimes cache layers more efficiently across users. The centralized daemon shares image layers system-wide, reducing disk usage. Podman's Buildah integration allows for fine-grained control of build steps and caching. While each user maintains separate image storage in rootless mode, you can configure shared storage for root-level builds. ### CPU and Memory Overhead Both tools add minimal overhead to container execution. The actual performance of your application depends on the container runtime (runc or crun), not the management tool. In production workloads, you won't notice performance differences between Docker and Podman. The choice often comes down to workflow and security preferences rather than raw speed. --- ## Enterprise Use Cases Both Docker and Podman have strong enterprise presences, but their sweet spots differ. ### Docker in the Enterprise Docker remains a favorite for: - **Developer onboarding:** Docker Desktop provides a polished experience for local development. - **Cross-platform support:** Native clients for Windows, macOS, and Linux. - **Ecosystem maturity:** Rich tooling, plugins, and community support. Docker’s commercial arm, **Docker Inc.**, has focused heavily on developer experience and team collaboration tools like Docker Hub and Docker Scout. ### Podman in the Enterprise Podman shines in environments where **security and compliance** are paramount: - **Government and regulated industries:** Rootless containers simplify compliance. - **Multi-user Linux systems:** Each user can run containers independently. - **Kubernetes-native shops:** Podman’s pod model and `generate kube` integration streamline workflows. Podman is also fully open source, backed by Red Hat, and integrates naturally with **OpenShift**, Red Hat's enterprise Kubernetes platform. --- ## Cost and Licensing Considerations Understanding the financial implications of your container runtime choice matters, especially at enterprise scale. ### Docker Licensing Docker Desktop requires a **paid subscription** for organizations with more than 250 employees **or** more than $10 million in annual revenue[^docker-pricing-faq]. Below that threshold, the **Personal** tier is free for individual developers, students, and small businesses. Docker Desktop pricing tiers (as listed on docker.com in 2026)[^docker-pricing]: - **Personal:** Free (within the eligibility rules above) - **Pro:** ~$9/month per user - **Team:** ~$15/month per user (5-seat minimum) - **Business:** $24/month per user (25-seat minimum) with SSO, centralized management, and enhanced security Pricing is updated periodically by Docker, so check the [official pricing page](https://www.docker.com/pricing/) before budgeting. The Docker Engine on Linux servers remains free and open source. However, commercial support and enterprise features like Docker Business require paid licenses. ### Podman Licensing Podman is **100% free and open source** under the Apache 2.0 license. There are no licensing costs regardless of company size or revenue. Red Hat provides commercial support for Podman through **Red Hat Enterprise Linux (RHEL)** subscriptions and **OpenShift** contracts. However, the software itself remains free to use without any restrictions. ### Total Cost of Ownership For small teams and individual developers, Docker Desktop's free tier works well. For larger organizations, Podman can offer significant cost savings—potentially thousands of dollars annually for teams of 50+ developers. However, consider indirect costs: Docker's mature ecosystem may reduce training time and troubleshooting overhead. Podman's learning curve is minimal for Docker users, but organizational adoption requires planning. --- ## Migration and Compatibility If you're considering switching from Docker to Podman, the good news is that it's relatively painless. Here's a comprehensive migration guide. ### Step 1: Install Podman On Ubuntu/Debian: ```bash sudo apt update sudo apt install podman ``` On RHEL/CentOS/Fedora: ```bash sudo dnf install podman ``` On macOS (via Homebrew): ```bash brew install podman podman machine init podman machine start ``` ### Step 2: Verify Installation Check Podman version and basic functionality: ```bash podman --version podman info ``` ### Step 3: Test CLI Compatibility Run a few familiar commands to verify Docker-like behavior: ```bash podman ps podman images podman run --rm hello-world ``` If everything works, you can alias Podman as Docker: ```bash echo "alias docker='podman'" >> ~/.bashrc source ~/.bashrc ``` ### Step 4: Migrate Existing Images Export images from Docker and import to Podman: ```bash # Export from Docker docker save myapp:latest -o myapp.tar # Import to Podman podman load -i myapp.tar ``` Or simply pull directly from registries since both use OCI-compliant images: ```bash podman pull docker.io/library/myapp:latest ``` ### Step 5: Migrate Docker Compose Workflows Install **podman-compose** for Docker Compose compatibility: ```bash pip3 install podman-compose ``` Then run your existing `docker-compose.yml`: ```bash podman-compose up -d ``` For simple multi-container setups, you can also use Podman's native pod support: ```bash podman play kube docker-compose-converted.yaml ``` ### Step 6: Update CI/CD Pipelines Replace Docker commands with Podman equivalents in your pipeline scripts. Most commands work identically: ```yaml # Before script: - docker build -t myapp . - docker push myapp # After script: - podman build -t myapp . - podman push myapp ``` ### Step 7: Configure Registries Set up your private registries in Podman's configuration: ```bash # Edit /etc/containers/registries.conf [registries.search] registries = ['docker.io', 'quay.io', 'registry.company.com'] ``` This allows Podman to search multiple registries automatically. --- ## Troubleshooting and Common Pitfalls Despite the compatibility, there are a few gotchas when moving to Podman. ### Networking Differences Docker’s daemon manages a virtual bridge network (`docker0`) that containers automatically join. Podman’s rootless networking uses **slirp4netns**, which behaves slightly differently—especially with port forwarding and DNS. If you run into connectivity issues, try running Podman in rootful mode or adjusting your network configuration: ```bash podman run --network=host myapp ``` ### Volume Permissions Because Podman runs as your user, mounted volumes must have appropriate permissions. You might need to adjust ownership or use `--userns=keep-id`. ### System Integration Docker Desktop handles a lot of system integration automatically (like credential helpers and Kubernetes). With Podman, you may need to configure these manually—but you gain transparency and control. --- ## Podman Desktop and Developer Experience One of Docker's long-standing advantages has been its polished desktop experience. Podman has been catching up fast with **Podman Desktop**, a comprehensive GUI that rivals Docker Desktop in functionality. ### Podman Desktop Features First released in 2022, accepted into the **CNCF Sandbox** in January 2025[^podman-desktop-cncf], and updated on roughly a monthly cadence, Podman Desktop provides: - **Container management:** Start, stop, inspect, and debug containers visually - **Image handling:** Build, pull, push, and inspect images through a clean interface - **Pod management:** Create and manage multi-container pods with visual tools - **Kubernetes integration:** Deploy to local or remote Kubernetes clusters - **Extension system:** Add functionality through plugins - **Multi-platform:** Native apps for Windows, macOS, and Linux ### Docker Desktop Comparison Docker Desktop remains more polished for cross-platform development, especially on Windows and macOS. It includes: - Seamless WSL2 integration on Windows - Modern virtualization options on Apple Silicon (Docker VMM by default, with Apple's Virtualization framework as an alternative; legacy QEMU was deprecated in 2025)[^docker-vmm] - Built-in Kubernetes cluster for local testing - Credential management and security scanning Podman Desktop is closing the gap rapidly. The key difference: Podman Desktop is fully open source and free for all users, while Docker Desktop requires paid licenses for larger organizations. ### Developer Workflow Integration Both tools integrate with popular IDEs like VS Code, IntelliJ, and Eclipse. Docker has broader third-party plugin support, but Podman's growing ecosystem includes excellent tooling for Kubernetes-native development. --- ## Community and Support The strength of a container platform isn't just technical—it's also about the community and support ecosystem. ### Docker Community Docker has a massive, mature community built over more than a decade. You'll find: - **Extensive documentation:** Docker Docs cover virtually every use case - **Stack Overflow:** Tens of thousands of answered questions - **Docker Hub:** Millions of pre-built images - **YouTube tutorials:** Thousands of video guides for beginners - **Commercial support:** Docker Inc. offers enterprise support contracts The Docker community's size means you'll almost always find someone who's solved your problem before. ### Podman Community Podman's community is smaller but growing rapidly. Resources include: - **Official documentation:** Comprehensive and well-maintained at podman.io - **Red Hat support:** Enterprise support through RHEL subscriptions - **GitHub discussions:** Active development and community help - **Fedora/CentOS community:** Strong Linux distribution integration - **OpenShift ecosystem:** Enterprise Kubernetes users adopt Podman naturally While Stack Overflow has fewer Podman questions, the Docker knowledge often translates directly thanks to CLI compatibility. ### Getting Help For Docker, community forums and Stack Overflow are your first stop. For Podman, GitHub issues and Red Hat documentation are particularly valuable. Both projects have active maintainers who respond to bug reports and feature requests. --- ## The Ecosystem Factor Docker’s ecosystem remains massive—Docker Hub, Docker Scout, Docker Build Cloud, and integrations across every CI/CD platform. Podman’s ecosystem, while smaller, is tightly integrated into the **Red Hat** and **Kubernetes** worlds. Tools like **Buildah**, **Skopeo**, and **CRI-O** complement Podman for a full container lifecycle: - **Buildah:** Builds images without a daemon. - **Skopeo:** Inspects and transfers container images. - **CRI-O:** Provides a lightweight Kubernetes runtime. Together, they form a modular alternative to Docker's all-in-one approach. --- ## Workload-Specific Recommendations Different workloads have different requirements. Here's guidance for common scenarios. ### Development Workstations **Best choice:** Docker Desktop (Windows/macOS) or Podman (Linux) For developers on Windows or macOS, Docker Desktop provides the smoothest experience with excellent platform integration. Linux users should consider Podman for its lighter footprint and security benefits. ### CI/CD Pipelines **Best choice:** Podman Running containers in CI environments benefits significantly from Podman's rootless architecture. No daemon means faster startup and easier cleanup. Many CI platforms now support Podman natively. Example GitLab CI configuration: ```yaml build-image: image: quay.io/podman/stable script: - podman build -t myapp:latest . - podman push myapp:latest ``` ### Production Kubernetes Clusters **Best choice:** Neither (use CRI-O or containerd) Modern Kubernetes doesn't use Docker or Podman directly. Instead, it uses container runtimes like CRI-O or containerd. However, both Docker and Podman are excellent for building images that will run in Kubernetes. ### Multi-Tenant Development Servers **Best choice:** Podman Linux servers shared by multiple developers benefit enormously from Podman's per-user isolation. Each developer can run containers without interfering with others or requiring root access. ### Microservices Development **Best choice:** Podman with pods Podman's native pod support makes it ideal for developing microservices architectures. You can model service meshes locally before deploying to Kubernetes. ### Legacy Application Containerization **Best choice:** Docker If you're containerizing older applications with complex dependencies, Docker's mature ecosystem and extensive documentation make troubleshooting easier. --- ## When to Choose Docker vs Podman in 2026 Let’s make this practical. ### Choose Docker if: - You’re focused on **developer experience** and cross-platform support. - Your team relies heavily on **Docker Desktop**. - You want the broadest ecosystem of **third-party integrations**. - You’re building for environments where root access isn’t a concern. ### Choose Podman if: - You need **rootless security** and compliance. - You’re working in **multi-user Linux** or **enterprise** environments. - You’re building **Kubernetes-native** applications. - You want **modular, open-source tooling** without vendor lock-in. In many cases, teams use both: Docker for local dev on laptops, Podman for production or CI/CD pipelines. --- ## Real-World Example: Rootless CI Pipeline Here’s a quick example of using Podman in a CI pipeline to build and push an image without root privileges. ```bash # Build image rootlessly podman build -t quay.io/myorg/myapp:latest . # Log in to registry (stored in user space) podman login quay.io -u $REGISTRY_USER -p $REGISTRY_PASS # Push image podman push quay.io/myorg/myapp:latest ``` No daemon, no root, no privileged containers—ideal for secure CI environments. --- ## The Future of Containers Beyond 2026 The container ecosystem isn’t static. The lines between Docker, Podman, and Kubernetes runtimes continue to blur. By 2026, the trend is clear: - **Security-first design** is non-negotiable. - **Rootless and daemon-less architectures** are becoming the new normal. - **Kubernetes-native tooling** is shaping the developer experience. Podman represents this evolution—a tool built for the realities of modern DevSecOps. Docker remains a fantastic developer platform, but its daemon model feels increasingly legacy in high-security or multi-user contexts. The good news? You don’t have to pick just one. Both Docker and Podman share the same container DNA. You can mix and match them across environments with minimal friction. --- ## Conclusion Docker changed the world by making containers simple. Podman is changing it again by making them **secure**. If Docker democratized containers, Podman is democratizing **secure containers**—no root required, no daemon to babysit, and no compromise on compatibility. In 2026, the choice isn’t about one tool replacing the other. It’s about using the right tool for the right job. Docker remains a strong default for fast prototyping and cross-platform dev; Podman leads when compliance, isolation, and Kubernetes alignment matter most. Whichever path you choose, containers remain the foundation of modern DevOps—and both Docker and Podman are pushing that foundation forward. If you’re serious about modern container workflows, it’s worth experimenting with both. Try aliasing Podman to Docker for a week and see how it feels. You might be surprised how natural the transition is. And as always—stay curious, stay secure, and keep shipping. --- **Further Reading** - [Podman Official Documentation](https://podman.io/) - [Docker Documentation](https://docs.docker.com/) - [Buildah Project](https://buildah.io/) - [Skopeo Project](https://github.com/containers/skopeo) --- ## Related reads - [Deploy a Node.js App to a VPS with Kamal 2 (2026)](https://nerdleveltech.com/deploy-nodejs-app-vps-kamal-2-tutorial) [^podman-version]: Podman release history is tracked at [containers/podman releases](https://github.com/containers/podman/releases) — Podman 6.0 completed Fedora test days in May 2026 and reached general availability on June 24, 2026, making the 6.x series the current stable line. [^podman-desktop-cncf]: [Podman Desktop | CNCF](https://www.cncf.io/projects/podman-desktop/) — accepted into the CNCF Sandbox on January 21, 2025. [^docker-daemon-ram]: Reported `dockerd` idle memory typically lands in the 300–400 MB range on Linux; Docker Desktop on macOS/Windows is significantly higher because it runs containers inside a Linux VM. See [Docker Community Forums: Docker Daemon using 300MB - 400MB Ram](https://forums.docker.com/t/docker-daemon-using-300mb-400mb-ram/136695). [^perf-benchmarks]: Public Podman vs. Docker benchmarks vary widely depending on runtime (`runc` vs. `crun`), workload, and host. See for example [Uptrace: Podman vs Docker Comparison](https://uptrace.dev/comparisons/podman-vs-docker) and [Linux Journal: Containers in 2025](https://www.linuxjournal.com/content/containers-2025-docker-vs-podman-modern-developers). [^docker-pricing-faq]: [Docker Plans FAQs](https://www.docker.com/pricing/faq/) — Docker Desktop's free Personal tier is limited to companies with fewer than 250 employees AND less than $10M in annual revenue; exceeding either threshold requires a paid subscription. [^docker-pricing]: [Docker Pricing](https://www.docker.com/pricing/) — pricing is updated periodically; figures shown are list prices on docker.com at time of writing. Docker Business has a 25-seat minimum. [^quadlets]: [Make systemd better for Podman with Quadlet (Red Hat)](https://www.redhat.com/en/blog/quadlet-podman) — `podman generate systemd` is deprecated in favor of declarative Quadlet unit files; the older command continues to receive urgent bug fixes only. [^docker-vmm]: [Virtual Machine Manager for Docker Desktop on Mac](https://docs.docker.com/desktop/features/vmm/) — Docker Desktop on Apple Silicon now defaults to Docker VMM, with Apple's Virtualization framework as an alternative. The legacy QEMU option was deprecated on July 14, 2025. [^dockershim]: [Updated: Dockershim Removal FAQ (Kubernetes blog)](https://kubernetes.io/blog/2022/02/17/dockershim-faq/) — dockershim was deprecated in Kubernetes 1.20 and removed entirely in Kubernetes 1.24. The replacement bridge is [cri-dockerd](https://github.com/Mirantis/cri-dockerd), maintained by Mirantis. ---