Ubuntu automatic updates: unattended-upgrades

Why automatic security updates are worth setting up

A server that is not patched is the easiest target on the internet. Most breaches of small servers are not clever; they are a known bug in an old package that the owner never updated. Ubuntu ships a tool that closes that gap on its own: unattended-upgrades installs security updates automatically, on a schedule, without you logging in. It is the cheapest security win available on a VPS, and on Ubuntu it is a few minutes of setup.

The tool is deliberately conservative. By default it applies only security updates, not every package upgrade, because a security patch is low-risk and worth taking without review, while a feature upgrade can change behaviour you were relying on. That default is the right one for most servers, and this guide keeps it while showing you the few settings worth changing.

Step 1: Install and enable it

On Ubuntu 24.04 the package is often present but not always enabled. Install it and turn it on:

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

The dpkg-reconfigure prompt asks a single yes-or-no question, whether to download and install stable updates automatically. Answer yes. That writes the file which switches the daily job on:

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

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

The first line refreshes the package list daily; the second runs the unattended upgrade daily. Both set to 1 means the machine checks for and applies security updates every day, on a systemd timer, with no further action from you.

Step 2: Decide what gets applied automatically

The policy lives in /etc/apt/apt.conf.d/50unattended-upgrades. Open it and look at the Allowed-Origins block near the top:

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";
};

The -security lines are the ones that matter, and they are enabled by default. That is the conservative policy: security updates in, ordinary feature updates left for you to apply by hand when you choose. You can add the "${distro_id}:${distro_codename}-updates" origin line to auto-apply all updates, but for a server that hosts something you care about, taking only security patches automatically is the safer default. Leave it as shipped unless you have a specific reason not to.

Step 3: Handle reboots

Some updates, a kernel or a core library, only take full effect after a reboot. unattended-upgrades will not reboot your server unless you tell it to, which means a patched kernel can sit unused until you happen to restart. Decide how you want to handle that, and set it explicitly in 50unattended-upgrades:

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

That reboots the server at four in the morning when, and only when, an update requires it. On a single VPS with no cluster to fail over to, a brief early-morning reboot is usually the right trade for staying current on kernel fixes. If your server runs something that must never restart unexpectedly, leave the reboot off and make a habit of rebooting yourself after checking /var/run/reboot-required.

Step 4: Prove it works

Do not wait a day to find out whether the job runs. Trigger a dry run that shows exactly what would be applied, without changing anything:

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

The output lists the packages it considers and which origins they come from, so you can see the policy in action. After the real job has run at least once, its record is here:

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

That log is the answer to "is my server actually patching itself." If it shows security packages being installed on a schedule, the job is working.

Where this fits

Automatic updates are one layer of a hardened server, not the whole thing. They keep known bugs from lingering, but they do nothing about who can log in or what is exposed. Pair them with key-only SSH hardening so the front door cannot be brute-forced, a default-deny UFW firewall so only what you choose is reachable, and unprivileged service users so a compromised app cannot take the whole box. Patching closes the holes you know about; the other layers limit the damage from the ones you do not.

FAQ

Does unattended-upgrades apply every update or only security ones?

By default, only security updates. The Allowed-Origins block in /etc/apt/apt.conf.d/50unattended-upgrades enables the -security origins and leaves ordinary feature updates for you to apply by hand. That is deliberate: security patches are low-risk and worth taking automatically, while feature upgrades can change behaviour, so most servers should keep the conservative default.

Will automatic updates reboot my server?

Only if you tell them to. Set Unattended-Upgrade::Automatic-Reboot "true" and an Automatic-Reboot-Time in the config, and the server reboots at that time when an update requires it, for example after a kernel patch. Left off, a patched kernel waits until you reboot yourself; check /var/run/reboot-required to know when one is pending.

How do I check that automatic updates are actually running?

Run sudo unattended-upgrade --dry-run --debug to see what would be applied right now, without changing anything, and read /var/log/unattended-upgrades/unattended-upgrades.log for the record of past runs; every automatic install also lands in /var/log/apt/history.log. If the log shows security packages installed on a daily schedule, the timer is working. If the dry run prints No packages found that can be upgraded unattended, either everything is already current or your allowed origins are too narrow to match the security repository.

Is unattended-upgrades enough to keep my server secure?

No, but it is a necessary layer. It keeps known vulnerabilities from lingering unpatched, which stops the most common kind of breach, but it does not control access or exposure. Combine it with SSH hardening, a default-deny firewall, and least-privilege service users for a server that is genuinely hard to break into.