How to Configure Automatic Security Updates on Ubuntu (unattended-upgrades)

You want security patches landing on your Ubuntu server without logging in every week, and without surprise reboots or a broken production stack in exchange. This DevAnswers guide configures unattended-upgrades deliberately: what’s already on by default, reboot policy, excluding fragile packages, and a 30-second check that proves it’s actually working.

Quick Answer: It’s Probably Already On #

Modern Ubuntu Server ships unattended-upgrades enabled for security updates. Check before configuring anything:

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

Two lines ending in "1" mean security patches already install automatically. The rest of this guide is what the default doesn’t decide for you: the reboot policy, package exclusions, and the 30-second proof it’s actually working.

Check First: It May Already Be On #

On a modern Ubuntu Server install, the unattended-upgrades package is present by default and security updates are applied automatically without user interaction. Half the confusion around this topic is people enabling something that was never off. Check the switch file before touching anything:

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

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

Both lines at "1" means package lists refresh daily and security upgrades install daily: the automation is live, and you can skip straight to the reboot policy and verification sections. If the file is missing or shows "0", the Enable and Configure section below switches it on. (For the manual side of updating, see the update Ubuntu guide.)

How It Works, and What It Actually Covers #

The behaviour is controlled by two files in /etc/apt/apt.conf.d/: 20auto-upgrades holds the on/off periodic switches you just checked, and 50unattended-upgrades defines what may be installed. Out of the box the allowed origins are limited to the security pocket, so the daily run installs security fixes and nothing else; your PHP version does not silently jump. Systemd timers (apt-daily and apt-daily-upgrade) fire the runs at randomized times to avoid mirror stampedes.

One boundary worth knowing about coverage: Canonical’s security maintenance applies to packages in Ubuntu’s Main repository (five years on an LTS). The much larger Universe repository historically carries no such commitment, so software installed from Universe may see few or no security updates for unattended-upgrades to apply. Ubuntu Pro’s ESM extends coverage there; the point for this guide is simply that automatic updates are only as broad as the patches Canonical publishes.

Enable and Configure It #

If the check above came back off or missing, the package’s own reconfigure step writes the periodic switches for you:

sudo apt install unattended-upgrades && sudo dpkg-reconfigure --priority=low unattended-upgrades

Answer Yes to automatically download and install stable updates, and it updates the configuration files on your behalf. For customization beyond the defaults, follow the Debian convention rather than editing 50unattended-upgrades in place: copy it to a local file that sorts after it, then make your changes there, safe from package upgrades.

sudo cp /etc/apt/apt.conf.d/50unattended-upgrades /etc/apt/apt.conf.d/52unattended-upgrades-local

One caveat on that example: blacklisting linux- stops unattended-upgrades from installing kernel packages at all, which includes kernel security fixes. Only exclude the kernel if you patch and reboot it deliberately on your own schedule; otherwise leave it off the list so security kernels still land automatically.

Decide Your Reboot Policy #

Kernel and libc security updates regularly need a reboot to take full effect; Ubuntu tracks that need in the flag file /var/run/reboot-required. By default unattended-upgrades installs the patch and leaves the reboot to you, which is safe but means a patched-on-disk, unpatched-in-memory kernel until someone acts. If you’d rather automate it, open your local override (jumped straight here? create it first with the cp command in the section above):

sudo nano /etc/apt/apt.conf.d/52unattended-upgrades-local

Find the Automatic-Reboot lines (or add them) and set the window:

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

Save and exit (press CTRL + X, press Y, then press ENTER)

With Automatic-Reboot on, the server restarts itself when a patch requires it, at the time you set. Whether you want that is a judgment call: an unplanned reboot is disruptive if a service doesn’t come back cleanly, so pick a low-traffic window, make sure everything critical starts on boot, and treat the first automated reboot as a drill you watch.

Exclude Fragile Packages #

Almost every production box has one package you patch by hand: a pinned database, a kernel module that breaks on updates, a vendor agent. The blacklist keeps automation away from them. Open the same local override again:

sudo nano /etc/apt/apt.conf.d/52unattended-upgrades-local

Edit the Package-Blacklist block, which accepts regular expressions:

Unattended-Upgrade::Package-Blacklist {
    "linux-";
    "mysql-server$";
};

Save and exit (press CTRL + X, press Y, then press ENTER)

"linux-" blocks everything starting with that prefix (the kernel family), while the $ anchor on "mysql-server$" pins the exact name only. Use the list sparingly: a blacklisted package can also hold back other updates that depend on it, so every entry is a patch you’ve promised to apply yourself.

Verify It Is Actually Working #

Most guides stop at the on switch. Don’t trust it; prove it. The dry run simulates tonight’s run against your real configuration without installing anything, showing which origins are allowed, which packages would upgrade, and what the blacklist held back:

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

Past runs are on the record too. The log shows every run, package, and decision, and the systemd timer listing proves the schedule is armed:

sudo tail -n 20 /var/log/unattended-upgrades/unattended-upgrades.log
systemctl list-timers apt-daily-upgrade.timer --all

That’s the whole 30-second audit: dry run clean, log showing recent activity, timer scheduled. Rerun it whenever you change the config, and you’ll never wonder whether the automation is quietly dead.

Fix the Shutdown Hang #

Sooner or later you’ll reboot manually and hit “Unattended upgrade in progress during shutdown, please don’t turn off the computer”. That hold is a safety feature, not a bug: apt’s package data can be corrupted if the system halts mid-run, so unattended-upgrades takes a systemd inhibitor lock and finishes what it started before shutdown proceeds. The delay is bounded, not infinite; inhibitor locks in delay mode time out after InhibitDelayMaxSec in /etc/systemd/logind.conf.

If the hold bothers you operationally, shorten the exposure rather than fighting it: schedule your own reboots away from the upgrade timers’ windows (check them with the timer listing above), and leave the inhibitor in place to do its job.

Next Steps #

Your server now patches itself, reboots on your terms, and can prove all of it on demand. Note the boundary, though: unattended-upgrades applies package updates within your current release; moving between releases is a different, deliberate operation covered in the release upgrade guide.

And if the truth is that you’d rather never own a patch schedule again, that job can be bought: managed platforms such as Cloudways apply OS security patching for you as part of the service.