← Back to blog

Why I picked Podman over Docker for the homelab

Most homelab guides assume you'll reach for Docker. I didn't, and the reasoning matters more than the choice itself.

The daemon problem

Docker's default architecture runs a privileged daemon as root. That daemon manages every container on the host, mediates every network and volume operation, and persists across reboots. A compromise of any container that escapes its sandbox lands you on a process with full system access — no privilege escalation required.

Podman is daemonless. There is no background process. Every container runs as the user who launched it, isolated from root by default. A compromised container can do what that user can do — which, for a service account, is usually nothing interesting.

Compatibility was a non-issue

The argument I expected to lose this on was tooling. In practice:

  • The CLI is identical: podman run, podman exec, podman ps. Docker muscle memory transfers cleanly.
  • Image format is OCI-compliant. Same docker.io/library/postgres:15 works.
  • podman-compose handles most existing docker-compose.yml files without changes. Edge cases exist, but they are documented and rare.
  • systemd integration is better than Docker's. podman generate systemd (or Quadlets) gives you a real unit file with the host's service manager — no parallel "Docker daemon owns my containers" layer.

Where Docker stayed

GitLab Runner uses Docker-in-Docker for its CI executor, and DinD requires a privileged Docker socket. That VM stays on Docker. Documenting the exception is part of the policy — not every rule needs to be absolute.

The portfolio angle

Enterprise environments are quietly moving away from Docker daemon dependencies. RHEL ships Podman by default. Showing Podman proficiency in a homelab portfolio is no longer a fringe choice; it's increasingly the table-stakes one.

Lesson

The security argument is real, but the deciding factor was that the cost of choosing Podman is low and the upside compounds. Every host gets the same install role, every service gets the same compose pattern, and the security model gets stronger by default rather than as a hardening pass.