# Docker to Podman on Omarchy: what shipped and what has not
Omarchy 4.0.1 made the docker group opt-in. Podman is still an unmerged branch. What is shipped, what is pending, and how to prepare now.
> **Short answer:** Nothing about Podman has shipped. Omarchy 4.0.4 still installs Docker, and the only container change that landed is from 4.0.1: your user is no longer added to the docker group, so plain docker needs sudo unless you opt in under Setup > Security > Sudoless Docker. Podman lives in open pull request 11032 on the feature/podman branch, unmerged.
- Applies to Omarchy: 4.0.1 and later
- Status: info
- Fixed in: 4.0.1
- Last verified: 2026-09-16
- Canonical: https://omarchylinux.org/upgrade/docker-to-podman/
_Unofficial community page. Not affiliated with 37signals or the Omacom Foundation. Omarchy is a registered trademark of 37signals LLC._

Two different things get mixed up whenever Omarchy and Podman come up in the same sentence. One has shipped and is on your machine right now. The other is an open pull request that nobody has merged. Keeping them apart saves a lot of confusion.

## What is shipped

Omarchy v4.0.4, checked on 2026-09-16, still installs Docker. The base package list names `docker`, `docker-buildx`, `docker-compose`, `lazydocker` and `ufw-docker`, and `install/config/enable-services.sh` still enables `docker.socket`. There is no mention of Podman anywhere in the v3.8.4, v4.0.0, v4.0.1, v4.0.2, v4.0.3 or v4.0.4 source trees.

What did change is who can talk to the daemon. Through v4.0.0, `install/config/docker.sh` added the installing user to the docker group with `usermod -aG docker`, and v4.0.0 also recorded the group for first boot provisioning. The docker group is root equivalent, because anything in it can bind mount the whole filesystem into a container and write to it as root. Pull request 8056, merged on 2026-08-24 and listed under Security in the v4.0.1 release notes, removed that grant, and in v4.0.1 the file is a comment explaining the decision and nothing else. Two follow ups landed the same day: pull request 8080 flags a reboot when the group changes, and pull request 8098 offers the reboot from the toggle and hides the menu entry that does not apply to you.

So since v4.0.1, on a fresh install and after the migration on an existing one, your user is not in the docker group.

## What changed for you on the command line

The daemon still runs. Only your direct, unprompted access to its socket is gone.

- Plain `docker` needs `sudo`. So does the `d` alias, which is still defined as `docker` in `default/bash/aliases`.
- The Docker TUI on `Super + Shift + D` goes through `omarchy-launch-docker-tui`, which runs lazydocker under `pkexec` when the socket is not writable. You get a polkit prompt instead of an error.
- The Windows VM helper asks for authorization the same way.
- `omarchy-install-docker-dbs`, the Install > Development > Docker DB menu entry, already calls `sudo docker run` for every database it sets up.

If you want the old behaviour back, run `omarchy-setup-security-sudoless-docker`, or pick Setup > Security > Sudoless Docker in the Omarchy menu. It prints a warning, adds you to the group after you confirm, and asks to reboot. Group membership is fixed when your session is created, so the reboot is not optional theatre. Setup > Security > Sudoless Docker only appears when you are out of the group, and Remove > Security > Sudoless Docker only appears when you are in it.

To check where you stand:

```bash
id -nG | grep -w docker && echo "in the group" || echo "not in the group"
```

The upgrade itself was not loud about this. In issue 9101, closed as completed on 2026-08-30, Matt Rayner reported working Docker commands starting to fail with a socket permission error after an update, with no obvious prompt explaining the change. If that happened to you, the group removal is the reason.

## The Podman work, which has not shipped

There is a real branch. `feature/podman` exists on the upstream repository, and its head commit at the time of writing is from 2026-09-14. It is open as pull request 11032, "Make Podman native with optional Docker compatibility", by acrogenesis, opened 2026-09-09 against the `quattro` branch. It carries 51 commits ahead of `quattro`, touches 101 files, and adds roughly 4,500 lines. It sits 22 commits behind and currently reports merge conflicts. It has two approving reviews from a bot reviewer and no maintainer merge.

There is a companion design document at `docs/podman-migration.md` on that branch, plus companion pull requests in the packages repository (369) and the ISO repository (171). All three are open.

There is also a rival. Pull request 11386, by the same author, opened 2026-09-11 from `feature/rootless-docker`, keeps Docker and its CLI and API but moves development workloads into a per user rootless daemon. Its own description calls it a direct Docker alternative to 11032 for side by side review. When two competing proposals from the same author are both open, the design is not settled.

If 11032 were merged as written, this is roughly what would change:

- Podman, Podman TUI and Podman Desktop replace Docker Engine, Buildx, lazydocker and ufw-docker. `Super + Shift + D` would open Podman TUI.
- Development databases become rootless Quadlet user services with named volumes, managed by systemd, instead of `sudo docker run` containers.
- Docker Compose stays as the compose frontend, used through `podman compose`.
- The `podman-docker` CLI shim becomes optional on fresh installs, offered as Install > Development > Docker Compatibility, and retained automatically for machines migrating off Docker.
- The Windows VM stays rootful, behind an authenticated launcher.

## How to prepare

You do not need to do anything today. If you want to be ready either way, these steps are useful now and cost nothing.

1. Decide your sudo posture deliberately. Either accept `sudo docker` as normal, or opt into the group knowing it is passwordless root. Do not drift between the two.
2. Look at your containers through the lens of what an automatic migration could carry. The boundary document is explicit: automatic transfer covers unprivileged containers on the default bridge, with localhost published ports, private named volumes, and ordinary CPU, memory, PID and shared memory limits.
3. Expect to move these by hand, whatever ships: privileged containers, added capabilities, device and GPU or CDI access, host directory and host socket mounts, custom networks, shared volumes, custom domain names, Docker in Docker, persistent BuildKit, and anything binding a low host port. Cached images and unattached volumes are also outside the automatic path.
4. Name your volumes. Anonymous volumes are the ones most likely to be left behind.
5. Stop hardcoding `/var/run/docker.sock` as a bind mount in your own compose files. Both proposals hit the same wall during testing, where an application mounted the rootful socket path and failed under a rootless engine. Rootless is the direction of travel in both designs.
6. Take a snapshot before any large update. See [rollback with Snapper and Limine](/upgrade/rollback-with-snapper-and-limine/).
7. Do not run either feature branch on a machine you care about. They are proposals under review, with conflicts against the default branch.

## What to watch for on newer versions

DHH said on X on 2026-09-08 that the next release will be called Quattro RS 4.5. If a container engine change lands, it will be in release notes under its own heading, and a migration script will appear under `migrations/`. Until then, treat any guide that tells you Omarchy ships Podman as wrong.

Two smaller things to watch. First, pull request 11032 changes the `d` alias from `docker` to `podman` and rewrites the Docker DB installer, so check both after any update that mentions containers. Second, if a migration does arrive, it is designed to leave Docker installed and the migration pending whenever it finds a workload it cannot reproduce, so a partially migrated machine is an expected state rather than a failure.

## Related

- [The docker group root escalation](/security/docker-group-root-escalation/)
- [Permission denied while trying to connect to the docker API](/fix/docker-permission-denied-after-group-change/)
- [Upgrading 3.x to 4.0 Quattro](/upgrade/3-to-4-quattro/)
- [What Omarchy migrations do](/upgrade/what-migrations-do/)
- Official manual: [Development Tools](https://omarchy.org/manual/development-tools/) and [Security](https://omarchy.org/manual/security/)

## Sources

- [Pull #8056: Don't put the user in the docker group; make it opt-in](https://github.com/omacom/omarchy/pull/8056)
- [Pull #8080: Flag a reboot when the docker group changes](https://github.com/omacom/omarchy/pull/8080)
- [Pull #8098: Offer to reboot when toggling sudoless Docker; show only the relevant menu entry](https://github.com/omacom/omarchy/pull/8098)
- [Omarchy v4.0.1 release notes: Fast-Follow Fixes](https://github.com/omacom/omarchy/releases/tag/v4.0.1)
- [Issue #9101: Docker migration removes socket access without an apparent sudoless-Docker setup prompt](https://github.com/omacom/omarchy/issues/9101)
- [Pull #11032: Make Podman native with optional Docker compatibility](https://github.com/omacom/omarchy/pull/11032)
- [docs/podman-migration.md on the feature/podman branch](https://github.com/omacom/omarchy/blob/feature/podman/docs/podman-migration.md)
- [Pull #11386: Run development containers with rootless Docker](https://github.com/omacom/omarchy/pull/11386)
- [Pull #369: Package Podman defaults and rootless ONCE](https://github.com/omacom/omarchy-pkgs/pull/369)
- [Pull #171: Build ISOs with Podman and test legacy migrations](https://github.com/omacom/omarchy-iso/pull/171)
- [DHH: next version of Omarchy is going to be Quattro RS 4.5](https://x.com/dhh/status/2097236884531351700)
- [Omarchy Manual: Development Tools](https://omarchy.org/manual/development-tools/)
- [Omarchy Manual: Security](https://omarchy.org/manual/security/)