I ditched Docker for Podman

Original Article ↗ Hacker News Discussion ↗

Container users are weighing a switch from Docker to Podman, attracted by Podman’s daemonless, rootless design, tighter systemd integration and freedom from Docker Desktop’s licensing and resource overhead. Many report Podman works well for simple workloads and on Linux servers, especially when paired with Quadlets and Kubernetes-style workflows, but run into rough edges around Docker Compose compatibility, networking, SELinux, and poor support on macOS and Windows. The overall picture is of a maturing but still uneven alternative: compelling on security and architecture grounds, yet not a seamless drop‑in replacement for Docker in all environments or tooling ecosystems.

Where and why people use containers

  • Many workloads end up on Kubernetes; others run directly on VMs or bare metal using Podman/Docker without an orchestrator.
  • Some prefer simple VM + Podman pods + Ansible instead of managing Kubernetes when workloads are uniform and scaling is coarse‑grained.
  • Containers are widely seen as a packaging format: “write software → build image → deploy image” across EC2, k8s, ECS, etc.

Perceived advantages of Podman

  • Daemonless: no long‑running privileged daemon; integrates cleanly with systemd and quadlets for per‑service units.
  • Rootless by default: container root maps to unprivileged host users; stricter resource enforcement than Docker in some reports.
  • Better fit for SELinux‑oriented distros and cgroups v2; some use Podman specifically because Docker lagged there.
  • podman generate kube and podman play kube offer an easy path from local pods to Kubernetes YAML.
  • Licensing: no Desktop license or telemetry; reduces procurement friction and “Docker tax” for large orgs.

Common pain points and incompatibilities

  • Networking: reports of flaky port‑forwarding, IPv6 issues, slow rootless networking (especially with slirp4netns), and macOS/Windows quirks.
  • Compose: podman‑compose lags the Compose spec and misses features (e.g. watch); some switch to Docker’s Go docker compose against the Podman socket or to quadlets instead.
  • Tooling: many CI/CD tools and services assume Docker’s API/socket, credential helpers, and buildx; Podman support is partial or fragile (GitLab runner, CUDA/GPU flags, secrets, multi‑arch builds).
  • Rootless + SELinux: volume mounts, UID mappings, and file ownership are frequent sources of confusion; users discuss :z/:Z flags, subordinate IDs, and custom policies.

Desktop experience and alternatives

  • On macOS, repeated reports that Podman Desktop is brittle compared to Docker Desktop, OrbStack, Colima, or Rancher Desktop; some orgs migrated entire dev teams to OrbStack with good results.
  • Windows users sometimes prefer plain Podman via WSL2 or Docker Engine in WSL over any Desktop UI.

Security and ecosystem maturity debates

  • Some view Docker’s rootful daemon as an unacceptable attack surface and prefer Podman’s model; others note Docker’s rootless mode and argue most risk comes from kernel/user‑namespace bugs, not the daemon.
  • Several tried Podman multiple times and reverted to Docker, citing “works out of the box” reliability and richer docs; others report years of smooth Podman production use and see Docker as overcomplicated or encumbered by licensing.