Navigation

DevOps devops security 5 min read

Automatic Security Updates

The single most common way servers get hacked is not some clever zero-day exploit. It is an old, known bug in software that the owner simply never patched. A fix was released months ago, but nobody ran the update. Automatic security updates solve this for almost no effort: Ubuntu downloads and installs security patches on its own, in the background, while you sleep. This page shows you how to turn that on, configure it safely, control when (and whether) the server reboots, and confirm it is actually working.

The patch-promptly principle

When a security flaw is found in software you run (say, OpenSSL or the Linux kernel), the maintainers publish a patch. At the same moment, attackers learn about the flaw too. The longer you wait to install the patch, the longer your server sits exposed with a hole that is now public knowledge. This is the patch-promptly principle: the value of a security update decays every hour you delay. Automation is the only reliable way to apply patches fast, because humans forget, go on vacation, and run dozens of servers they cannot babysit.

A quick definition: a package is a unit of installed software on Ubuntu (like nginx or openssh-server), and apt (Advanced Package Tool) is the command-line tool that installs and updates packages. The tool we use here, unattended-upgrades, is an official Ubuntu package that runs apt for you on a schedule.

When to use this (and when not to)

Server type	Auto security updates?	Why
Web servers, VPS, personal cloud boxes	Yes — strongly recommended	Internet-facing, high risk, low cost to patch
Standard app servers behind a load balancer	Yes, with staggered reboots	Patch promptly, but reboot one node at a time
Databases / stateful single nodes	Yes for downloads, manual reboots	Auto-patch, but you control the restart window
Tightly regulated / change-controlled systems	Maybe — security-only, no reboot	You may need a human to approve every change

Auto-updates are for security patches only by default. They do not (and should not) blindly upgrade every package to its newest feature release, which could break your app. Stick to the security pocket.

Installing and enabling unattended-upgrades

On Ubuntu 22.04 and 24.04 LTS, the package is usually already installed. Install and enable it to be sure.

sudo apt update
sudo apt install -y unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

The dpkg-reconfigure step shows a simple text dialog asking “Automatically download and install stable updates?” — choose Yes. That writes the master switch file /etc/apt/apt.conf.d/20auto-upgrades. Check it:

cat /etc/apt/apt.conf.d/20auto-upgrades

Output:

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

The "1" means “do this every day”. Update-Package-Lists refreshes the list of available updates (like apt update), and Unattended-Upgrade runs the actual install. The work is triggered by a systemd timer (systemd is Ubuntu’s service manager; a timer is its built-in cron-like scheduler). Confirm the timer is active:

systemctl status apt-daily-upgrade.timer

Output:

● apt-daily-upgrade.timer - Daily apt upgrade and clean activities
     Loaded: loaded (/lib/systemd/system/apt-daily-upgrade.timer; enabled)
     Active: active (waiting) since Mon 2026-06-15 09:00:01 UTC
    Trigger: Tue 2026-06-16 06:18:42 UTC; 21h left

Configuring what gets patched

The main config file is /etc/apt/apt.conf.d/50unattended-upgrades. Open it and review the Allowed-Origins block, which controls which sources are eligible for automatic install.

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

The default, recommended configuration keeps you on the security pocket only:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

// Remove unused dependencies after the upgrade
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// Send email if something goes wrong
Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "on-change";

The -security lines are the important ones. The two ESM lines cover Ubuntu Pro (a free-for-personal-use subscription that extends security support); they do nothing unless you have attached a Pro token, so they are harmless to leave in.

Do not add the plain ${distro_codename}-updates pocket unless you have tested it. That pocket includes non-security bug-fix releases that can change behavior and occasionally break a running app. For most servers, security-only is the safe default.

Controlling automatic reboots

Many patches (especially kernel updates) only take effect after a reboot. unattended-upgrades can reboot the server for you, but you decide if and when. Edit the same file:

// Reboot automatically when a patch requires it
Unattended-Upgrade::Automatic-Reboot "true";

// ...but only at 03:00 server time, to avoid surprise downtime
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

// Don't reboot while a user is logged in
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";

Setting	Meaning	When to use
`Automatic-Reboot "false"`	Never auto-reboot; you reboot manually	Databases, single-node services where you control downtime
`Automatic-Reboot "true"` + a time	Reboot at a fixed quiet hour	Stateless web/app servers that can blip at 3 AM
`Automatic-Reboot-WithUsers "false"`	Skip reboot if someone is on the box	Shared dev boxes

After a reboot is applied, the file /var/run/reboot-required tells you a restart is still pending. Check it any time with cat /var/run/reboot-required — if the file exists, a reboot is needed.

Verifying it actually works

Do not assume it runs. Test it. Run a dry run that simulates an upgrade without changing anything:

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

Output:

Checking if system is running on battery is skipped. Generally this is a desktop ...
Initial blacklist:
Initial whitelist (not strict):
Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=jammy, o=Ubuntu,a=jammy-security, ...
Packages that will be upgraded: libssl3 openssl
Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

The Packages that will be upgraded line confirms it found pending security patches. To force a real run immediately (instead of waiting for the timer):

sudo unattended-upgrade -v

Finally, read the logs to confirm history. The logs live in /var/log/unattended-upgrades/:

sudo cat /var/log/unattended-upgrades/unattended-upgrades.log

Output:

2026-06-15 06:18:43 INFO Starting unattended upgrades script
2026-06-15 06:18:55 INFO Packages that were upgraded: openssl libssl3
2026-06-15 06:18:59 INFO All upgrades installed

Best Practices

Enable automatic security updates on every internet-facing server — it is the highest-value, lowest-effort hardening step you can take.
Keep Allowed-Origins limited to the -security pocket so feature changes never auto-install and break your app.
Set a reboot time during a low-traffic window (e.g. 03:00) and, for clusters, stagger nodes so they never reboot at the exact same minute.
Configure Unattended-Upgrade::Mail so failures actually reach a human instead of dying silently in a log.
Test with --dry-run after any config change, and periodically read /var/log/unattended-upgrades/ to confirm patches are landing.
Watch for /var/run/reboot-required if you keep auto-reboot off — a downloaded kernel patch is not active until the server restarts.

Automatic Security Updates

The patch-promptly principle

When to use this (and when not to)

Installing and enabling unattended-upgrades

Configuring what gets patched

Controlling automatic reboots

Verifying it actually works

Best Practices

Related Topics