How to Deploy and Manage Rootless Podman Containers with systemd on Ubuntu 24.04

Running applications in containers on a dedicated server requires more than simply downloading an image and starting a container. Production environments need reliable service management, automatic startup, persistent storage, appropriate security controls and a straightforward way to recover from failures.

Rootless Podman containers provide an effective way to run containerized applications on Ubuntu 24.04 without granting the container process root privileges on the host. Podman is a daemonless container engine that supports OCI-compatible images and provides an alternative to Docker for many Linux container workloads.

When combined with systemd and Podman Quadlet, administrators can manage containers as system services. This approach makes it possible to configure automatic startup, restart policies, persistent volumes and service dependencies without maintaining complicated startup scripts.

In this tutorial, you will learn how to install Podman on Ubuntu 24.04, configure a dedicated Linux user for rootless container execution, deploy an Nginx container and manage its lifecycle using systemd and Quadlet. By the end, you will have a working container deployment that can start automatically after a server reboot and operate independently of an interactive SSH session.

What Are Rootless Podman Containers?

Podman is an open-source container management tool used to create, run and manage Linux containers. It supports OCI-compatible container images and provides commands similar to those used by Docker.

One of its main advantages is its ability to run containers without requiring root privileges. In a traditional rootful container deployment, the container engine or container-management process operates with elevated host privileges. Rootless Podman instead uses Linux user namespaces to map container identities to unprivileged user IDs on the host.

This means that the container's internal root user does not automatically receive root privileges on the underlying Ubuntu server. Rootless container execution can help reduce security risks, particularly when hosting multiple applications or workloads on the same dedicated server.

Why Use Podman Instead of Docker?

Podman and Docker provide similar container-management capabilities, but their architectures differ.

Podman is particularly useful when administrators want daemonless container management, rootless execution and native systemd integration. However, Docker may remain preferable for environments that depend on Docker-specific tooling or established Docker Compose workflows.

What Is Podman Quadlet?

Podman Quadlet is a systemd generator that converts declarative configuration files into systemd service units. Instead of manually creating systemd service files for individual containers, administrators define container settings in files such as:

For rootless deployments, these files are commonly stored in ~/.config/containers/systemd/. After reloading the user's systemd manager, Quadlet processes the configuration and generates the corresponding service units. This makes Podman Quadlet a practical solution for managing long-running containers on Ubuntu servers.

1. Install Podman on Ubuntu 24.04

Before deploying rootless Podman containers, install the container engine on your Ubuntu server. Connect to your server through SSH using an account with sudo privileges.

First, update the package index and upgrade installed packages:

Install Podman using Ubuntu's package manager:

Ubuntu 24.04 provides Podman through its official package repositories, making APT the straightforward installation method.

After installation, verify the installed version:

Check the container engine configuration:

You should also verify that the server uses cgroup v2, which is required by Quadlet:

The expected output is v2. If the server reports a different cgroup version, investigate the host configuration before continuing.

Important: Ubuntu 24.04's packaged Podman version is 4.9.3 in the documented Noble package. This tutorial uses Quadlet features supported by that release rather than relying on newer Podman 5.x or 6.x functionality.

2. Create a Dedicated Linux User for Rootless Containers

Running every container under the root account defeats an important security advantage of rootless Podman. A better approach is to create a dedicated Linux user for container workloads. In this example, the account will be named podapp.

Create the user:

This creates a separate account without requiring an interactive password.

Verify the account:

Configure Subordinate UID and GID Ranges

Rootless Podman uses subordinate user IDs (UIDs) and group IDs (GIDs) to map identities inside containers to unprivileged identities on the host.

Check whether the new account already has subordinate ID ranges:

If suitable ranges do not exist, allocate unused ranges. For example:

These are example ranges, not universal defaults. Before assigning them, check /etc/subuid and /etc/subgid to ensure they do not overlap existing allocations.

Verify the configuration:

The account should now have subordinate UID and GID ranges available for rootless container execution.

3. Enable Rootless Podman and Configure User Services

Rootless Podman runs containers within the permissions and environment of the Linux user who owns them. For server deployments, however, there is another important requirement: containers should continue running after the user disconnects from SSH.

Linux systemd provides a feature called lingering to support this behaviour. When lingering is enabled, systemd maintains the user's service manager even when the user does not have an active login session.

Enable lingering for the dedicated container account:

Verify the configuration:

Expected output: Linger=yes

Now switch to the dedicated account:

Check whether Podman can initialise its rootless environment:

If the command completes successfully, the user-level container environment is ready. You can now use Podman without running container commands through sudo.

Security recommendation: Keep application containers under their dedicated unprivileged account. Avoid switching between rootful and rootless Podman because they maintain separate container storage, images and volumes.

4. Pull and Run a Container Image

Before configuring systemd, test whether the dedicated user can download and run a container image. For this tutorial, we will use Nginx, a widely used web server and reverse proxy.

Pull the official Nginx image:

After downloading the image, start a temporary container:

Here is what each option does:

Check whether the container is running:

View its logs:

Test the Nginx service locally:

A successful response should include an HTTP status such as 200 OK. If you want to access the service externally, configure your server firewall to permit TCP port 8080. Only expose ports that your application actually requires.

Once the test is complete, remove the temporary container:

The next step is to replace this manually started container with a systemd-managed deployment.

5. Create a Podman Quadlet Configuration File

Podman Quadlet simplifies rootless container management by allowing administrators to describe container settings in configuration files. Instead of manually maintaining long podman run commands, you can define the required settings once and allow systemd to manage the container.

First, create the Quadlet configuration directory:

Create a container configuration file:

Add the following configuration:

Save the file.

Understanding the Quadlet Configuration

Each section has a specific purpose.

[Unit]
Defines the systemd service description and its dependencies. Description identifies the container service, while Wants and After express a dependency on network availability.

[Container]
Contains the Podman-specific container configuration.

[Service]
Controls the systemd service lifecycle. Restart=always tells systemd to restart the service when the container process exits. TimeoutStartSec=900 allows up to 15 minutes for startup, which is useful when an image needs to be downloaded.

[Install]
Defines how the generated service should be connected to the user's systemd startup target. WantedBy=default.target allows the service to start automatically with the user's systemd manager. This is particularly useful for long-running applications hosted on dedicated servers.

6. Configure Persistent Storage with Podman Volumes

Container filesystems are not always suitable for storing application data permanently. When a container is removed and recreated, data stored only in its writable container layer may be lost. Persistent volumes help prevent this problem by storing application data separately from the container itself.

Podman supports named volumes that can be mounted into containers whenever they start. For this deployment, we will create a named volume for the Nginx website directory.

Create the volume configuration file:

Add:

Save the configuration. The .volume extension tells Quadlet to create a systemd-managed Podman volume.

In the previous web.container configuration, we referenced this volume using: Volume=web-data.volume:/usr/share/nginx/html

This mounts the persistent volume inside the Nginx container at /usr/share/nginx/html. The volume is created automatically when the container service starts.

Verify the Persistent Volume

After starting the container service in the next step, inspect the available volumes:

Inspect the named volume:

For production applications, use persistent volumes for database files, uploaded content and other information that must survive container replacement. Remember that persistent storage is not a backup. Important application data should also be backed up to a separate storage location.

7. Start and Manage the Podman systemd Service

Now that the Quadlet configuration and persistent volume definition are ready, you can load them into the systemd user manager.

First, reload the systemd configuration:

Quadlet reads the configuration files and generates the corresponding systemd service units. The file web.container generates web.service.

Check whether the generated service is available:

Check its status:

Start the container:

Verify that the service is running:

You can also check the container directly:

Test the Nginx web server:

If everything is configured correctly, the Nginx container should now be running as a rootless Podman service managed by systemd.

Enable Automatic Startup

One important difference between Quadlet-generated services and conventional systemd services is that you do not normally enable the generated service directly using systemctl enable.

Instead, Quadlet reads the [Install] section in the original configuration file and applies the requested startup relationship when generating the service.

Combined with the previously enabled user lingering, this allows the container to start automatically when the user's systemd manager starts, including after a server reboot.

8. Manage Rootless Containers Using systemctl

Once Podman Quadlet has generated the service, you can manage the container through systemd. This provides a consistent way to start, stop, restart and monitor containerized applications.

The following commands should be executed as the podapp user.

Start the Container:

Stop the Container:

Restart the Container:

Check the Service Status:

View Container Service Logs:

To follow the logs continuously, use journalctl --user -u web.service -f. To display the latest 100 log entries, use journalctl --user -u web.service -n 100 --no-pager.

Inspect the Container with Podman

Although systemd manages the service lifecycle, Podman remains useful for inspecting container-level information.

List running containers:

List all containers, including stopped containers:

View container logs, inspect configuration, and monitor resource consumption:

Using systemd for lifecycle management and Podman for container inspection provides a practical administration workflow for rootless container deployments.

9. Configure Container Networking

Networking is an important part of running production containers on dedicated servers. Podman allows administrators to publish container ports, create private container networks and control communication between applications.

In our example, the Quadlet configuration contains PublishPort=8080:80. This forwards connections from port 8080 on the Ubuntu host to port 80 inside the Nginx container.

You can verify the published port using:

Create a Dedicated Container Network

When hosting multiple applications, it is often better to use a dedicated network rather than exposing every container port directly. Podman Quadlet supports .network files for defining container networks.

Create a network configuration:

Add:

Save the file. You can then reference the network in the [Container] section of an applicable container configuration by adding Network=app-network.network.

Reload the user systemd manager after changing Quadlet files and restart the affected container service:

For applications involving databases, backend services and frontend containers, private container networking can reduce unnecessary exposure of internal application ports.

Production recommendation: For public-facing websites, consider placing a reverse proxy such as Nginx or Caddy in front of your containers. This allows you to manage HTTPS certificates, request routing and external access without publishing every application port.

10. Troubleshoot Common Rootless Podman Issues

Even when Podman and systemd are configured correctly, container startup problems can occur because of incorrect configuration files, unavailable images, port conflicts or user namespace restrictions. Understanding how to inspect these problems is important for maintaining reliable container workloads.

Problem 1: The systemd Service Cannot Be Found

You may encounter an error such as: Failed to start web.service: Unit web.service not found. This usually means Quadlet did not generate the expected service.

Check the configuration directory:

Verify that the container file uses the correct .container extension. Reload the user systemd manager with systemctl --user daemon-reload.

If the service is still unavailable, run the Quadlet generator in diagnostic mode:

Problem 2: The Container Stops Immediately After Starting

If a container exits unexpectedly, inspect its service status and application logs.

Common causes include incorrect application configuration, missing environment variables, invalid startup commands and unavailable dependencies.

Problem 3: Rootless Container Permission Errors

Rootless Podman depends on Linux user namespaces and subordinate UID/GID mappings. If you encounter permission-related errors, check the subordinate ID configuration:

If the mappings are missing or incorrect, review the account's subordinate ID allocation before attempting to recreate containers. Do not delete the Podman storage directory as a routine troubleshooting measure because it may contain important container and image data.

Problem 4: Containers Do Not Start After a Server Reboot

If your rootless containers do not automatically start after restarting Ubuntu, verify that lingering is enabled: loginctl show-user podapp -p Linger (Expected output: Linger=yes).

Next, check that your Quadlet file includes WantedBy=default.target under the [Install] section. Remember that rootless container services depend on the correct user-level systemd configuration.

Problem 5: The Container Port Is Already in Use

A port conflict occurs when another application is already listening on the port you want to publish. Check active listeners:

If the port is occupied, choose another available host port. Update your Quadlet configuration (e.g., PublishPort=8081:80), reload systemd, and restart the container.

Problem 6: Container Image Downloads Take Too Long

When Quadlet starts a container, Podman may need to download the required image. Large container images or slow network connections can increase startup time. To avoid unnecessary delays, download the image before starting the service: podman pull docker.io/library/nginx:stable.

You can also configure a longer startup timeout in the Quadlet file (TimeoutStartSec=900).

11. Rootless Podman Best Practices for Production Dedicated Servers

Deploying rootless Podman containers is only one part of maintaining a reliable production environment. When running containerized applications on dedicated servers, administrators should also consider security, resource allocation, monitoring and data protection.

Here are some important practices:

For organizations running multiple containerized workloads, dedicated server infrastructure can provide predictable CPU, memory, NVMe storage and network capacity. Selecting suitable hardware is important when applications have sustained resource requirements.

12. Rootless Podman vs. Docker: Which Is Better for Dedicated Servers?

Both Podman and Docker are capable container platforms, but choosing between them depends on your infrastructure and application requirements. Podman is particularly attractive for administrators who prefer daemonless container execution, rootless security and native systemd integration.

Docker remains a strong choice for teams that already depend on Docker Compose, Docker-specific tooling and established deployment workflows.

For dedicated server environments, consider the following factors:

There is no universal winner. Evaluate application compatibility, security requirements, operational complexity and the experience of your server administration team before choosing a container platform.

Conclusion

Running rootless Podman containers with systemd on Ubuntu 24.04 provides a practical approach to managing containerized applications without relying on root-level container execution.

Throughout this tutorial, you learned how to install Podman, create a dedicated Linux user, configure subordinate UID and GID mappings, enable rootless execution and deploy an Nginx container. You also explored how Podman Quadlet integrates with systemd to manage container services, configure persistent storage, handle automatic startup and troubleshoot common deployment problems.

For production environments, combining rootless container execution with appropriate firewall rules, persistent storage, regular backups and system monitoring can help establish a more manageable and secure application infrastructure. Whether you are deploying web applications, backend services or development environments, Podman Quadlet offers a straightforward way to manage containers on Ubuntu dedicated servers.

Frequently Asked Questions

Related COLO BIRD Resources

When deploying containerized applications, choosing the right server infrastructure is important for maintaining consistent application performance and resource availability. Explore these COLO BIRD resources: