Podman's no-daemon model, its rootless ceiling, and two major lines shipping on the same day

On Mac and Windows you get podman-remote talking to a virtual machine

Podman ships a Docker-compatible CLI that can drive containers locally or on a remote system, which is why one binary name covers two very different situations. The repository builds two primary targets, podman and podman-remote, and the Makefile draws the line between them without hedging: Windows and Mac are podman-remote client only, and both require CGO_ENABLED=0. The local podman binary needs CGO_ENABLED=1, with a comment above it saying Podman does not work without CGO except in very specific cases.

# Podman does not work w/o CGO_ENABLED, except in some very specific cases.
# Windows and Mac (both podman-remote client only) require CGO_ENABLED=0.
CGO_ENABLED ?= 1

The consequence for planning is easy to miss. Those two platforms are supported through a Podman-managed virtual machine, started with `podman machine`, and your commands are carried into it.

So moving from Docker to Podman is cheap at the command line and more expensive at the mount. The compatible interface covers the surface you type. The compatible interface is what you type; the platform underneath is a Podman-managed virtual machine.

No manager daemon means nothing is resident holding state for you

The scope list puts the central claim plainly: no manager daemon, for improved security and lower resource utilization at idle. The idle half is the obvious one, since there is no long-lived privileged process sitting on the host. The security half is about reachability, because a service listening for requests is a thing that can be talked into doing something.

On Mac and Windows it is messier, because `podman machine` starts a virtual machine that is itself a long-lived process, so the daemon-free property that describes Linux does not carry over to those platforms unchanged.

The REST API shows the same split from a client's point of view. Podman exposes a Docker-compatible interface and an improved interface exposing advanced Podman functionality.

Rootless is the default, and --privileged cannot lift the ceiling

Podman runs as a normal user with no setuid binary, and when it runs without root the containers use user namespaces so that root inside the container is the user who ran Podman. The boundary is stated without hedging: rootless containers will never have more privileges than the user that launched them. Some restrictions can be lifted, and `--privileged` is the flag named for that, but it lifts only restrictions the user was actually subject to in the first place.

The example given is more useful than the rule. Run Podman as your user, mount in `/etc/passwd` from the host, and you still cannot change it, because your user has no permission to do so. A bind mount under rootless carries only the user's own permissions, so a container that edits a bind-mounted file the user cannot write will fail to change it.

Almost all normal functionality is said to be available, with the shortfalls listed in rootless.md, and an administrator has to do a little configuration before rootless Podman can be used at all. Budget for that step.

v6.1.3 and v5.8.8 were published on the same day, 2026-09-29

Two major lines shipped on one date: v5.8.9 and v6.1.4 were both published on 2026-10-12, and v6.2.0-RC1 followed on 2026-10-26. The release rhythm explains the pairing: Podman ships a new major or minor four times a year, in the second week of February, May, August and November, and patch releases arrive more often and at any time. So the 5.x line is still receiving fixes while 6.x is current, and a team on 5.x is not on a dead branch today.

The rule underneath is narrower than that. Only the most recent release receives upstream support, exceptions are sometimes made, and an LTS version is offered in those cases. The list of supported versions lives in SUPPORT.md in the Podman community repository, under the long-term-support section. The question when you pin is therefore not whether a release is supported now but which line you will be sitting on when the next major ships, because that is when the patches stop, absent an LTS exception.

All releases are PGP signed, and the public keys of the team members approved to make releases sit in the containers/release-keys repository under podman. If you verify releases on a restricted network, pull those keys before you need them. The last push to main was 2026-10-02, so the tree you install from is moving.

An exploded root filesystem arrives with no trust check attached

Images can be pulled from various sources with trust and verification, built from a Containerfile or a Dockerfile, or committed from a running container. Containers can then be created from an image or from an exploded root filesystem. That is three different provenance stories, and the verification machinery is bolted to only one of them.

In the scope list, trust and verification are attached to pulling images from various sources. The list does not attach them to committing from a container or to creating one from an exploded root filesystem, so if your pipeline starts containers from an unpacked directory, check separately what you are verifying.

Checkpoint and restore is a CRIU contract with an unstated kernel floor

Container lifecycle management includes checkpointing and restoring via CRIU, and the dependency list pins github.com/checkpoint-restore/go-criu/v8 at v8.5.0 alongside checkpointctl at v1.7.0. That is a working capability rather than a placeholder, but it is one that depends on the kernel underneath agreeing to replay what was written to disk.

A checkpoint captures process state that has to be restored against a kernel. Land that restore on a different kernel, on a kernel configured differently, or on a host missing what CRIU needs, and it fails. CRIU restores depend on the kernel and host, so test on the machines you actually run.

The dependency set deserves the same suspicion. go.mod requires Go 1.26.8 and carries a warning that a toolchain directive, if one appears anywhere in the file, has to match the go directive exactly.

The module path already says v6, and the Python in the repo is only tooling

The go.mod file opens like this:

module go.podman.io/podman/v6

// Warning: if there is a "toolchain" directive anywhere in this file (and most of the
// time there shouldn't be), its version must be an exact match to the "go" directive.

go 1.26.8

The /v6 suffix is the Go major-version rule, so any project importing Podman's libraries has to carry that suffix in its own go.mod, and a build host needs a Go toolchain at or above 1.26.8. The dependency list doubles as a map of the subsystems: ocicrypt, go-systemd, libhvee, the moby client and API packages, go-sqlite3, vfkit and go-qemu for the virtual machine paths, and gvisor-tap-vsock.

The repository is Go throughout. pyproject.toml is the only Python configuration at the top level, and it configures black with line-length 100 and target-version py36, scoped to .py and .pyi files with docs and hack excluded. That file governs helper scripts, not the product.

What the top level does carry is a large amount of operating documentation: rootless.md, troubleshooting.md, transfer.md, install.md, SUPPORT.md, RELEASE_PROCESS.md, ADOPTERS.md, MAINTAINERS.md, plus build_osx.md, build_windows.md and winmake.ps1 for platform builds. Most operational answers live in those files rather than in the README.

Editorial conclusion

Podman suits Linux workloads where running containers as a normal user matters, where pods are worth having, and where a long-lived privileged daemon on the host is the thing you want gone. It does not suit a Mac or Windows user who expects bind mounts to behave exactly as they do under Docker, because those platforms run the client against a Podman-managed virtual machine. It also does not suit a team that wants upstream support on an older major line, since only the most recent release gets it. Before adopting it, check whether the release you plan to pin is the current major line or an LTS entry in SUPPORT.md, and whether your hosts have CRIU working if you need checkpoint and restore. The narrowest thing to verify is this: run a container as your own user with /etc/passwd bind-mounted in, and try to write to it. That single write shows the boundary the rootless design turns on: rootless containers never have more privileges than the user who launched them.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes