Table of Contents

Podman Container Auto-Updates: Native Integration vs. Watchtower
#

In both production and development environments, ensuring container images are up-to-date is key to maintaining system security and functionality. This article will explore the two main approaches for automatically updating Podman containers: Watchtower and Podman’s native podman-auto-update mechanism.

A Comparison of Approaches: Architectural Philosophy and Design
#

Choosing an approach is essentially choosing between two different management philosophies.

Comparison Aspect	Podman Native Approach (`podman-auto-update`)	Watchtower (External Management)
Core Architecture	Declarative & System-Integrated. You simply declare “this container should be updated,” and the rest of the work is handled entirely by the operating system’s core `systemd` timers.	Imperative & External Polling. You run a separate manager container that actively and continuously polls the Podman API to check for and perform updates.
Design Philosophy	“Let the system manage me.” It leverages the host’s existing, extremely reliable `init` system to achieve zero-overhead management.	“I will manage you.” It introduces an external, stateful manager to monitor and operate other containers.
Reliability	Extremely High. Its reliability is equivalent to that of `systemd` itself, one of the most robust components of a Linux system.	Moderate. It depends on the stability of the Watchtower container itself, which is another piece of software that needs to be managed and could crash or be misconfigured.
Overhead	Almost Zero. There are no running processes or memory usage at rest. It only spawns a short-lived process at the moment the check is triggered.	Continuous Overhead. It requires a long-running container that constantly consumes a small amount of CPU and memory.
Security	Superior. There are no extra running daemons, which reduces the attack surface. It aligns perfectly with Podman’s rootless philosophy.	Introduces Additional Risk. It requires mounting the Podman socket into the container, which is a privileged operation that needs to be handled with care.
Features	Focuses on the core update functionality. Its purpose is pure, with no built-in extras like notifications.	Feature-rich. It supports sending update notifications (Webhook, Email), finer-grained filtering, and more control.

Tip: The Podman native approach embodies the modern DevOps philosophy of deep integration with the operating system. It is more secure, more reliable, and more resource-efficient. While Watchtower is a versatile general-purpose solution, it introduces unnecessary complexity and management overhead into the Podman ecosystem. For professional users who value robustness and simplicity, the native approach is the clear first choice.

The Native Approach: `podman-auto-update`
#

This method works for both rootless and rootful modes.

Step 1: Declare the “Auto-Update” Intent for the Container
#

Using Podman’s Quadlet tool, we only need to add a single line to the container’s .container configuration file.

Locate or create your Quadlet file.
- Rootless Mode (Recommended): Files are in ~/.config/containers/systemd/
- Rootful Mode: Files are in /etc/containers/systemd/

Add AutoUpdate=image to the [Container] section.

Here is an example of a typical caddy.container file:

 1[Unit]
 2Description=Caddy web server
 3After=network-online.target
 4Wants=network-online.target
 5
 6[Container]
 7ContainerName=caddy
 8Image=docker.io/library/caddy:latest
 9# Core: Declare that this container should be auto-updated
10AutoUpdate=image
11Port=80:80
12Port=443:443
13
14[Install]
15WantedBy=default.target

Apply the changes. After modifying or creating the file, reload systemd and restart your container service to apply the new label.
- Rootless Mode: systemctl --user daemon-reload && systemctl --user restart caddy.service
- Rootful Mode: sudo systemctl daemon-reload && sudo systemctl restart caddy.service

Step 2: Activate the Global Update Timer
#

Podman ships with a systemd timer that we just need to activate.

Rootless Mode: systemctl --user enable --now podman-auto-update.timer
Rootful Mode: sudo systemctl enable --now podman-auto-update.timer

enable ensures it starts on boot, and --now starts the timer immediately. At this point, your auto-update is configured and will run on its default schedule.

Step 3: (Optional) Customize the Update Frequency
#

The default update frequency is daily, in the early morning. To modify this safely, it’s recommended to use systemd’s override mechanism.

Open the edit interface. This command will automatically create an override file for you to edit.
- Rootless Mode: systemctl --user edit podman-auto-update.timer
- Rootful Mode: sudo systemctl edit podman-auto-update.timer

Enter your new schedule in the editor. The OnCalendar= field follows the systemd.time calendar event format.

1#
2# /etc/systemd/system/podman-auto-update.timer.d/override.conf
3#
4[Timer]
5# Clear the inherited schedule from the original file to ensure our setting is the only one
6OnCalendar=
7# Set the new schedule, for example: every day at 3:30 AM
8OnCalendar=*-*-* 03:30:00

Common OnCalendar examples:

Run once per hour: hourly
Every Monday at 4:00 AM: Mon *-*-* 04:00:00
Every 15 minutes: *:0/15

Apply and verify your changes.
- Rootless Mode: systemctl --user daemon-reload && systemctl --user restart podman-auto-update.timer
- Rootful Mode: sudo systemctl daemon-reload && sudo systemctl restart podman-auto-update.timer
You can view the new trigger time with systemctl --user list-timers (or sudo systemctl list-timers) to confirm the configuration has been applied.

Podman Container Auto-Updates: Native Integration vs. Watchtower#

A Comparison of Approaches: Architectural Philosophy and Design#

The Native Approach: podman-auto-update#

Step 1: Declare the “Auto-Update” Intent for the Container#

Step 2: Activate the Global Update Timer#

Step 3: (Optional) Customize the Update Frequency#