Podman containers can be configured to start automatically at boot using systemd, but the magic isn’t in Podman itself; it’s in how systemd interprets a special file that tells it how to run your container as a service.
Let’s see this in action. Imagine you have a simple Nginx container you want running all the time.
First, run your container and give it a name. We’ll also make sure it’s configured to restart if it crashes, as this is a good practice for services.
podman run -d --name my-nginx-web -p 8080:80 docker.io/library/nginx:latest
podman container update --restart always my-nginx-web
Now, you need to create a systemd service unit file. This file describes your container as a service to systemd. We’ll put this in /etc/systemd/system/my-nginx-web.service.
[Unit]
Description=My Nginx Web Server Container
Requires=podman.socket
After=podman.socket
[Service]
Restart=always
ExecStart=/usr/bin/podman start -a my-nginx-web
ExecStop=/usr/bin/podman stop my-nginx-web
Environment="PODMAN_SYSTEMD_UNIT=my-nginx-web.service"
[Install]
WantedBy=multi-user.target
Let’s break down what’s happening here.
The [Unit] section provides metadata. Description is human-readable. Requires=podman.socket and After=podman.socket tell systemd that this service depends on the Podman socket being available and ready, which is crucial for Podman to manage containers.
The [Service] section is where the action is. Restart=always mirrors what we set on the container itself, ensuring systemd tries to keep it running. ExecStart=/usr/bin/podman start -a my-nginx-web is the command systemd runs to start your container. The -a flag is important: it attaches to the container’s main process, ensuring systemd can monitor it correctly and see it as "running." ExecStop=/usr/bin/podman stop my-nginx-web is what systemd runs to stop the service. Environment="PODMAN_SYSTEMD_UNIT=my-nginx-web.service" is a Podman-specific environment variable that helps Podman’s internal systemd integration work correctly, especially when dealing with container lifecycles.
The [Install] section dictates how the service is enabled. WantedBy=multi-user.target means this service should be started when the system reaches its normal multi-user runlevel (i.e., when it’s ready for users to log in, but before graphical interfaces load).
After creating this file, you need to tell systemd to reload its configuration and then enable and start your new service.
sudo systemctl daemon-reload
sudo systemctl enable my-nginx-web.service
sudo systemctl start my-nginx-web.service
Now, if you check the status, you should see it running.
sudo systemctl status my-nginx-web.service
The output will show your Nginx container as active, managed by systemd. If you reboot your machine, systemd will automatically execute the ExecStart command for my-nginx-web.service, starting your container.
The real power here is that Podman itself doesn’t need to be aware of systemd. You’re using systemd to manage Podman’s ability to start and stop a specific container, treating that container as a first-class service. This allows for robust service management, including automatic restarts, dependency ordering, and integration with the OS’s boot process, all without needing a separate orchestration layer for simple use cases.
A common pitfall is forgetting the -a flag in ExecStart. Without it, podman start might return before the container’s main process is fully initialized and running, leading systemd to believe the service has failed even if the container is technically active. This is because systemd’s Type=forking (the default for ExecStart commands that detach) relies on the process exiting, but podman start doesn’t exit until the container process is no longer attached. The -a flag keeps the podman start command attached to the container’s process, allowing systemd to monitor its lifecycle directly.
Once your containers are reliably starting with systemd, the next logical step is to think about how to manage multiple containers that depend on each other, which leads to exploring systemd’s ability to define complex service chains and dependencies.