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

> Podman is a Go tool for running OCI containers and pods without a manager daemon, built so that ordinary users can run containers directly. The cost is that on Mac and Windows every command crosses into a Podman-managed virtual machine, and that rootless containers can never hold more privileges than the user who launched them.

**podman-container-tools/podman** — GitHub describes it as Podman: A tool for managing OCI containers and pods.. The repository metadata lists Go as its primary language. The metadata lists the Apache-2.0 license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/podman-container-tools/podman
- Website: https://podman.io
- Stars: 32,914 · Forks: 3,384
- Language: Go
- License: Apache-2.0
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/podman-container-tools-podman

## 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.

```make
# 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. Anything that depends on the host filesystem being the same filesystem now crosses a machine boundary, and the path you supply is a path in the guest rather than a path on your desktop.

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 virtual machine underneath it is a different machine with different absolute paths, and that is where the migration work actually lands.

## 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.

The bill arrives in how state gets recovered. With no resident process, everything a command needs to know about existing containers has to be read back from storage on each call, and a container that was started is reconstructed from what was written down rather than from a process still holding it. On Linux that is a clean trade and the design holds up. 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. A client written against the Docker half will connect, run containers, and then find that the advanced half is not reachable through it.

## 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 is therefore not a writable view of the host file, and a container that edits a bind-mounted config expecting the host copy to change will fail in a way that reads like a permissions bug in the image rather than a deliberate policy.

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. It is the first thing that breaks when someone installs the package and runs it as a normal user expecting Docker to behave identically.

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

Two major lines shipped on one date, with v5.8.7 landing six days earlier on 2026-09-16. 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 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-09-22, 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.

A named image pull means a registry lookup with trust and verification applied, so you can state which bytes you received and whether they were signed. Committing from a container yields whatever that container's filesystem happened to hold at the moment you asked, with nothing to compare it against. An exploded root filesystem is a directory of files some process unpacked, and creating a container from it means Podman takes the directory on trust. No digest is attached to the thing you are about to run.

This bites hardest in CI, where unpacking a tarball into a directory is the fastest path and the easiest to get subtly wrong. If your pipeline does that and starts a container from the result, the verification the pull path gives you is not in the loop. The README does not document a way to add one at that point.

## 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.4.0 alongside checkpointctl at v1.6.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. The README does not state which kernel versions or configurations are required, so the floor is something you establish by testing on the machines you actually run rather than by reading documentation. That is a real cost for the workloads people reach for this on, since moving a process between machines quickly is the entire reason to want checkpointing.

The dependency set deserves the same suspicion. go.mod requires Go 1.26.3 and carries a warning that a toolchain directive, if one appears anywhere in the file, has to match the go directive exactly. Patching the toolchain line in a vendored copy is not a warning you can ignore. It is a build that stops on a version check.

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

The go.mod file opens like this:

```go
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.3
```

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.3. The dependency list doubles as a map of the subsystems: ocicrypt, go-systemd, libhvee, the moby client and API packages, go-sqlite3, vfkit and a go-qemu fork 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.

## 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 and every host path has to be a path in the guest. 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 a host file bind-mounted in, and try to write to it. That single write is the boundary the whole rootless design turns on, and it fails quietly in a way that looks like a bug in your image.

## FAQ

### Is Docker the same as Podman?

Podman offers a Docker-compatible CLI interface and a Docker-compatible face on its REST API, so familiar commands work. The objects underneath are different: there is no manager daemon, containers run rootless without a setuid binary, and pods are a first-class group of containers that share resources.

### What are the downsides of using Podman?

Only the most recent release receives upstream support, so a pinned major line loses fixes when the next one ships unless an LTS exception applies. On Mac and Windows every command runs through a Podman-managed virtual machine started by `podman machine`, and rootless containers never hold more privileges than the user who launched them.

### How do I install Podman?

The project sends you to the install guide at podman.io/getting-started/installation, and downloads are listed in DOWNLOADS.md in the repository. For building from source the repository carries build_osx.md, build_windows.md and a Makefile whose main targets are podman and podman-remote.

### How do I use Podman on Windows?

Windows runs Podman through a virtual machine managed by `podman machine`, and on that platform the client is the podman-remote build, which the Makefile notes requires CGO_ENABLED=0. Source build instructions for the platform are kept in build_windows.md, with winmake.ps1 at the repository root.

### What is Podman used for?

Managing containers and images, volumes mounted into those containers, and pods that group containers sharing resources. It handles multiple image formats including OCI and Docker, the full container lifecycle from creation to removal, and container networking through Netavark.

### How do I use Podman instead of Docker?

Podman provides a Docker-compatible CLI interface that can run containers both locally and on remote systems, plus a REST API with a Docker-compatible side. Container creation works from a Containerfile or a Dockerfile, or by committing a running container, and images can be pulled with trust and verification applied.

## Sources

- [Official documentation](https://podman.io)
- [Official README](https://github.com/podman-container-tools/podman#readme)
- [Project repository](https://github.com/podman-container-tools/podman)
- [Release notes](https://github.com/podman-container-tools/podman/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/podman-container-tools-podman