Ubuntu unattended-upgrades: Practical Security Patching Without the Ops Overhead

The Problem: Staying Patched While Staying Alive

Security updates are non-negotiable for production systems, yet the manual process of monitoring CVEs, downloading patches, and rebooting servers is a recipe for drift and oversight. Ubuntu's unattended-upgrades package promises to close that gap by automating the safe installation of security updates—but getting it right requires understanding how it selects packages, when it reboots, and what it skips.

How unattended-upgrades Picks Its Battles

The tool works by consulting a whitelist of APT package origins, not a blacklist of dangerous packages. By default, it's configured to pull from the -security pocket of your release (e.g., jammy-security for Ubuntu 22.04 LTS). This means kernel updates, OpenSSL fixes, and web server patches flow through automatically, while newer feature releases in -updates or -proposed are ignored.

The selection logic lives in /etc/apt/apt.conf.d/50unattended-upgrades. The Unattended-Upgrade::Allowed-Origins section maps directly to the pockets you want. A typical production setup looks like:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Timing, Reboots, and Systemd Timers

On modern Ubuntu (18.04 and later), the daily cadence is driven by two systemd timers: apt-daily.timer refreshes package lists, and apt-daily-upgrade.timer triggers the actual upgrade run. Unlike legacy cron, these timers randomize execution within a window, which reduces load spikes across a fleet. Machines that were powered off at the scheduled time catch up at next boot.

Reboots are where things get tricky. Kernel packages install cleanly, but the new kernel only takes effect after a restart. The Unattended-Upgrade::Automatic-Reboot-Time option lets you schedule this (e.g., "02:00" for 2 AM). Without it, systems stay vulnerable until someone manually reboots. For stateful services like PostgreSQL or Redis, you'll want to blacklist them entirely—an unexpected mid-run restart of a database is rarely acceptable.

Work It Out: A Security-Only Configuration

Let's configure a server that only applies security patches and reboots at a safe hour. Run these commands on the target machine with sudo privileges. First, ensure the package is installed:

sudo apt install unattended-upgrades

Then edit /etc/apt/apt.conf.d/50unattended-upgrades to limit origins and add a blacklist for stateful services:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

Unattended-Upgrade::Package-Blacklist {
    "postgresql";
    "redis-server";
};

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

Finally, enable the periodic checks in /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Now run a dry-run to verify before anything changes:

sudo unattended-upgrade --dry-run --debug

This shows exactly which packages would be upgraded without touching the system. After a day, check /var/log/unattended-upgrades/unattended-upgrades.log to confirm the job ran and applied the expected patches. Note that exact option names and timer behavior vary across releases—confirm the syntax against the version you actually run.

Trade-Offs: When Auto-Updates Bite Back

The biggest hidden risk is the gap between package installation and effective patch level. A kernel update lands at 2 AM, but the system remains exploitable until the scheduled reboot at 3 AM—assuming the reboot actually fires. Missed runs or disabled timers leave you exposed longer than you think.

Stateful services are another minefield. Even with a blacklist, dependencies can pull in newer libraries that restart dependent processes unexpectedly. Always audit /var/log/unattended-upgrades/ after enabling this on systems running databases, message queues, or custom daemons.

Final Check: Is It Actually Working?

Use these commands to verify your setup:

• systemctl list-timers apt-daily* — confirms timers are active and shows the next scheduled run
• cat /etc/apt/apt.conf.d/20auto-upgrades — checks that periodic mode is enabled
• sudo unattended-upgrade --dry-run --debug — previews the actual upgrade list

If the dry-run shows only packages from -security, you're in good shape. Automation isn't a set-and-forget feature: regular log reviews and testing the reboot path in a staging environment are the only ways to be sure your security patches are actually protecting you.