Run Rootless Podman Containers as Systemd User Services

The problem: your container dies with your shell

You switched to Podman to avoid a persistent container daemon and to run containers without root. That works until you close your terminal: the container you started with podman run stops, and it does not come back after a reboot. Docker users solve this with a daemon and restart policies, but Podman’s daemonless model means there is no background process watching your containers by default.

You can run rootless Podman containers under systemd user services instead. This keeps containers alive after logout and across reboots without giving the container root access to the host.

Check that your host is ready for rootless Podman

Run this in your normal user shell, not as root:

podman info --format ’{{.Host.Security.Rootless}}’

Expect true. If it prints false, you are in rootful mode and the rest of this article does not apply.

Rootless mode uses Linux user namespaces, which map container user IDs to a range of unprivileged host IDs. Your user needs entries in /etc/subuid and /etc/subgid. Check them with:

grep "^$USER:" /etc/subuid
grep "^$USER:" /etc/subgid

Each line should show a starting ID and a count, for example a range of at least 65,536 IDs. If either file lacks your user, ask your system administrator to add a range before continuing.

Create a container and generate its systemd unit

Start a container as your unprivileged user. This example uses port 8080 on the host because rootless users normally cannot bind to privileged ports below 1,024.

podman run --detach --name web-example --publish 8080:80 docker.io/library/nginx:alpine

Where to run: your user shell. Permissions: none beyond normal user access. Risk: the command downloads an image from the network and binds port 8080; make sure that port is free.

Now generate a systemd unit file for that container:

podman generate systemd --new --files web-example

This writes container-web-example.service into your current directory. The --new flag tells systemd to create the container if it does not exist when the unit starts.

Install and start the user service

Copy the unit into your user systemd directory:

mkdir -p ~/.config/systemd/user
cp container-web-example.service ~/.config/systemd/user/

Enable linger so systemd keeps your user manager running after you log out:

sudo loginctl enable-linger $USER

Where to run: a shell with administrative access. Permissions: root or sudo. Risk: this changes system login behavior for your user so services can run without an active session.

Reload and start the service as your normal user:

systemctl --user daemon-reload
systemctl --user enable --now container-web-example.service

Expected result: the command returns without error, and systemctl --user status shows the service as active.

Verify and diagnose

Check the service:

systemctl --user status container-web-example.service

Look for active (running) in the output. If it failed, read the user journal:

journalctl --user -u container-web-example.service --since today

Confirm the container itself is running under Podman:

podman ps --filter name=web-example

Trade-offs and limits

• Rootless networking usually uses slirp4netns or pasta. It works for outbound connections, but port publishing and inter-container DNS behave differently from Docker’s rootful bridge.
• Privileged ports below 1,024 require a sysctl change such as net.ipv4.ip_unprivileged_port_start=0, which needs root access.
• The subuid/subgid range must be large enough for every UID and GID inside the container image. A small range can cause mapping failures.
• Some Docker-specific features do not map one-to-one to Podman, so compose files and rootful scripts may need adjustment.

Undo the change

If you no longer want the service:

systemctl --user disable --now container-web-example.service
rm ~/.config/systemd/user/container-web-example.service
systemctl --user daemon-reload

What to do next

Run podman --version and compare it against your distribution’s release notes, because exact flags and defaults change between Podman releases. Once the unit is active, test a reboot or log out and back in to confirm the container returns without your intervention.