Exploring Podman: A More Secure Docker Alternative

Original Article ↗ Hacker News Discussion ↗

Podman is emerging as a popular alternative to Docker, largely because of its security-first design: rootless containers, better integration with SELinux, and less intrusive networking that avoids some of Docker’s firewall and VPN pitfalls. Commenters highlight that Podman can often serve as a drop-in replacement and works well with tools like systemd and docker-compose/podman-compose, but note rough edges around tooling, UID/GID mappings, and platform issues, especially on Apple Silicon. Many still stick with Docker for its ecosystem, documentation, and familiarity, arguing that Docker rootless mode can address similar security concerns if properly configured.

Security models and rootless containers

  • Many see Podman’s “secure by default” model (rootless, user namespaces, no long‑running root daemon) as a major advantage over Docker.
  • Docker’s default of running as root and using a docker group is criticized as a serious security risk in multi‑user / managed environments.
  • Several comments note Docker does support rootless mode and seccomp by default, but it’s not the out‑of‑the‑box path and is perceived as less prioritized.
  • Some consider comparing Podman-rootless vs Docker-as-root “unfair”; they argue Docker-rootless vs Podman-rootless is the relevant comparison.

SELinux and labeling

  • Podman’s adherence to SELinux policies is praised for production security but causes friction (containers can’t access bind-mounted dirs).
  • Workarounds: disabling labeling in containers.conf, or using :z / :Z on volumes to auto-adjust labels.
  • Opinions on SELinux range from “worth the hour to learn” to “unusable trainwreck,” though some insist it should be left in permissive rather than disabled.

Networking behavior

  • Docker’s manipulation of iptables/nftables is a recurring pain point: conflicts with firewalls (UFW), VPNs, and KVM bridges.
  • Podman is reported to “play nice” with host networking and KVM, though rootless networking has kernel limitations.
  • Dynamic modification of forwarded ports is desired but described as technically hard given iptables/nftables complexity.

Systemd, Quadlet, and orchestration

  • Early Podman support for podman generate systemd was popular; the shift towards Quadlet is divisive. Some find Quadlet cleaner; others see it as needless complication and revert to docker-compose or hand-written units.
  • podman-compose can generate and register systemd units; some find this elegant, others say it’s poorly discoverable.
  • Several use docker-compose/podman-compose in homelabs and even small production; others argue larger deployments should move to Kubernetes, Swarm, or Nomad and wish for a simple Podman-native “Swarm-like” orchestrator.

Tooling, compatibility, and developer workflow

  • Podman is “mostly” a drop‑in Docker replacement; subtle CLI and behavioral differences can break scripts or compose setups, especially around networking.
  • Using Docker tooling with Podman usually involves running a Docker-compatible socket and pointing DOCKER_HOST at it; some see this as trivial, others as needless friction.
  • Docker’s ecosystem (compose files, docs, community) is still viewed as more mature and accessible, so many orgs stick with Docker for developers even if they use Podman/Buildah in CI.
  • NixOS users highlight tools like compose2nix to convert compose files into native systemd/OCI configs.

Platform-specific experiences

  • On Linux, several claim “no reason to use Docker anymore” if Podman is available.
  • macOS (especially Apple Silicon) experiences are mixed: some report years of trouble-free use; others hit severe hangs or freezes and fall back to Docker. Podman Desktop sometimes works where CLI installs don’t.
  • On Windows, Podman is praised as lighter and less intrusive than Docker Desktop, though it lacks some IDE integrations.

Motivations, politics, and ecosystem concerns

  • Red Hat’s investment in Podman is attributed to failed attempts to collaborate with Docker and dissatisfaction with Docker’s security, SELinux, systemd, and networking behavior.
  • Some argue Podman’s existence, like Linux vs proprietary OSes, is valuable as a check on Docker’s power.
  • There is debate over which company is more trustworthy; opinions differ on Red Hat/IBM vs Docker, but Podman’s fully open nature is seen as a safety net if corporate directions change.

Pain points and alternatives

  • Podman’s UID/GID mappings, ACLs, and labels can confuse new users; early adopters report “it didn’t just work” and that podman system migrate could wreck setups. Others, starting later, find it easier than Docker.
  • Some workloads can’t easily be run rootless (e.g., NFS mounts), limiting the value of rootless Podman/Docker in those environments.
  • A few prefer to bypass both Docker and Podman for certain use cases, using bubblewrap or Buildah directly and criticizing Dockerfiles as an unnecessary DSL.