Automatic Security Updates on Ubuntu: 2026 Setup

A VPS you stood up six months ago and rarely log into is the most dangerous machine you own. It is still serving traffic, still listening on its open ports, and still running whatever package versions it had the day you walked away — including the ones with public exploits published last week. Patch hygiene is the single highest-leverage thing you can do for an unmonitored server, and on Ubuntu you can hand the whole job to a background service. This guide configures unattended-upgrades so security updates install themselves, on a schedule you control, with a reboot policy you choose.

Install unattended-upgrades

On most Ubuntu Server images the package is already present, but install it explicitly so you know it is there:

1sudo apt update
2sudo apt install unattended-upgrades

The package ships a systemd timer and an APT periodic hook — there is no daemon to start by hand. Configuration lives in two files under /etc/apt/apt.conf.d/: 20auto-upgrades decides whether and how often the service runs, and 50unattended-upgrades decides what it is allowed to touch.

Enable the Periodic Runs

The simplest way to switch everything on is the package's own configuration prompt:

1sudo dpkg-reconfigure -plow unattended-upgrades

Answering Yes writes /etc/apt/apt.conf.d/20auto-upgrades for you. You can also create or edit it directly — it is two lines:

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

The first line refreshes the package index daily; the second runs the unattended upgrade daily. The values are intervals in days, so "1" means every day and "0" disables that step. Daily is the right cadence for a security-only policy — a patch should never sit on disk unapplied for a week.

Choose What Gets Upgraded

This is the part that matters most, and the default is deliberately conservative: only the security pockets, not every available update. Open the main config:

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

The Allowed-Origins block defines which repositories the service may pull from. The shipped default looks like this:

1Unattended-Upgrade::Allowed-Origins {
2    "${distro_id}:${distro_codename}";
3    "${distro_id}:${distro_codename}-security";
4    "${distro_id}ESMApps:${distro_codename}-apps-security";
5    "${distro_id}ESM:${distro_codename}-infra-security";
6};

Keep the -security lines enabled. The first line — ${distro_codename} with no suffix — pulls all updates, not just security ones; many administrators comment it out so the service stays strictly security-scoped and never bumps an application package out from under a running service. On an unmonitored box, security-only is the safer posture, because an untested feature update is its own kind of outage.

If a particular package has ever broken on an automatic bump, blacklist it so it is only ever updated by hand:

1Unattended-Upgrade::Package-Blacklist {
2    "libc6$";
3    "libc-bin$";
4};

The $ anchors the match to the exact package name.

Handle Reboots

Kernel and libc patches do not take full effect until the machine restarts. By default the service installs them but leaves the reboot to you:

1Unattended-Upgrade::Automatic-Reboot "false";

For a server nobody is watching, an unapplied kernel patch waiting weeks for a manual reboot defeats the point. Enable automatic reboots, but pin them to a low-traffic window so a restart never lands in the middle of your busiest hour:

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

The time is the server's local clock — check it with timedatectl and set the timezone if it still reads UTC. The default Automatic-Reboot-WithUsers "true" lets the reboot proceed even while someone is logged in; set it to "false" if you would rather an active admin session blocks the restart. On a single-purpose web or database host where you are rarely connected, a fixed 4 a.m. reboot is exactly the behavior you want.

Get Notified When It Acts

Silent automation is only trustworthy once you can see what it did. Point the service at an address that actually reaches you:

1Unattended-Upgrade::Mail "you@example.com";
2Unattended-Upgrade::MailReport "on-change";

on-change mails you only when packages were actually installed or a problem occurred — quiet on the days nothing happens, loud the moment something does. The alternatives are always (a daily receipt) and only-on-error. Mail delivery needs a working local mailer such as postfix or msmtp; if the server cannot send mail, rely on the log file instead, covered below.

Test Before You Trust It

Never enable an unattended process without first watching it run in simulation. The dry-run shows precisely which packages would be fetched and installed, and changes nothing:

1sudo unattended-upgrade --dry-run -v

Note the binary is unattended-upgrade (singular) while the package is unattended-upgrades (plural) — an easy thing to mistype. Read the output: it lists the candidate packages and the origins they come from. If you see application packages you did not expect, your Allowed-Origins is broader than you intended — go back and tighten it before the next scheduled run.

Verify It Is Actually Running

Configuration that was never picked up is worse than none, because it gives false confidence. Confirm the periodic settings are live:

1apt-config dump APT::Periodic

You should see your Update-Package-Lists and Unattended-Upgrade values reflected back. Check the timer that drives the run:

1systemctl status apt-daily-upgrade.timer

And after the first overnight cycle, read the log to confirm real activity:

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

A healthy log shows the package-index refresh, any security packages installed, and — if you enabled it — the reboot decision. An empty or stale log on a server that has been up for days means the timer is not firing; that is your signal to revisit the two config files.

One more thing worth checking on a long-lived server is whether a pending reboot is being deferred. When a kernel update has installed but the machine has not yet restarted, Ubuntu drops a marker file at /var/run/reboot-required. Test for it directly:

1[ -f /var/run/reboot-required ] && cat /var/run/reboot-required

If that file exists and you have not enabled automatic reboots, the patched kernel is on disk but not yet running — you are protected only after the restart. This is the gap automatic reboots are designed to close, and the reason an unmonitored server in particular should not be left to a manual reboot that may never come.

Patching Is the Floor, Not the Ceiling

Automatic security updates close the gap between a fix exists and your server has it — the window attackers live in. They do not replace a firewall, key-only SSH, or off-server backups; they sit underneath all of it as the baseline that keeps the rest from being undermined by a known, already-patched CVE.

Scope it to security origins, give it a reboot window the traffic can absorb, wire up an on-change email, and read the log once after the first run. Then the most neglected machine in your fleet patches itself every night without you remembering it exists — which, for an unmonitored VPS, is exactly the outcome you want.

References

• Ubuntu Server documentation — Automatic updates