How to Set Up Automatic Security Updates on Ubuntu

The most common way servers get compromised isn't a clever hack — it's a known vulnerability in software that was never patched. Automatic security updates fix this by installing critical patches on their own. On Ubuntu, the tool is unattended-upgrades, and setting it up takes five minutes.

Why automate updates?

Security advisories become public the moment a fix ships. Attackers immediately scan for unpatched servers. If you only update "when you get around to it," you're exposed for days or weeks. Automating *security* updates (not every update) closes that window with minimal risk of breakage.

Install unattended-upgrades

It's usually pre-installed on Ubuntu, but ensure it and the update helper are present:

sudo apt update
sudo apt install unattended-upgrades apt-listchanges -y

Enable it interactively

The quickest way to turn it on:

sudo dpkg-reconfigure --priority=low unattended-upgrades

Choose "Yes" to automatically download and install stable updates. This creates /etc/apt/apt.conf.d/20auto-upgrades.

Verify the schedule config

Check /etc/apt/apt.conf.d/20auto-upgrades contains:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";

That updates package lists and applies unattended upgrades daily, and cleans the cache weekly.

Tune what gets upgraded

Open /etc/apt/apt.conf.d/50unattended-upgrades. By default only the security pocket is enabled, which is what you want:

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

Leave general -updates off unless you're confident, so you only auto-apply security fixes.

{{SCREENSHOT}}

Handle reboots for kernel updates

Some patches (like the kernel) only take effect after a reboot. Decide your policy in the same file:

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

This reboots at 4 AM if a patch requires it. If your workload can't tolerate surprise reboots, set this to "false" and reboot manually on a schedule — but don't forget, or kernel fixes never activate.

Get notified

To receive an email when upgrades run (needs a working mail setup):

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

Test it without waiting

Run a dry run to see what would be upgraded:

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

And check the log afterwards:

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

Don't blindly auto-update everything

Auto-applying *security* patches is low-risk and high-value. Auto-applying *all* updates on a production app can occasionally break things. Keep security automatic, and review feature/major updates yourself. Pair this with automated backups so you can roll back if an update ever misbehaves.

Handling services that need restarting after a patch

A subtle gap catches many people: when a shared library is updated, the running processes that loaded the *old* version keep using it until they're restarted. You can be "patched" on disk but still running vulnerable code in memory. The needrestart tool detects exactly this:

sudo apt install needrestart -y
sudo needrestart

It lists services still running outdated libraries and can restart them for you. On Ubuntu it integrates with unattended-upgrades, so you can have it handle restarts automatically. Configure its behaviour in /etc/needrestart/needrestart.conf — set $nrconf{restart} = 'a' for automatic restarts, or 'l' to just list and decide yourself. For a kernel update, only a reboot fully applies it, which is why the automatic-reboot window discussed above matters.

Keep an eye on the upgrade log

Automation is only trustworthy if you occasionally verify it. Once a week, glance at what's been applied:

grep -h ' upgrade ' /var/log/dpkg.log* | tail -20
cat /var/log/unattended-upgrades/unattended-upgrades.log

This confirms updates are actually running, and — on the rare occasion something breaks — gives you a timeline correlating a problem with a specific package change. If a security update ever does cause trouble, you can hold that package with sudo apt-mark hold <package> while you investigate, then unhold it once a fix ships. Combined with tested backups, this gives you both automatic protection and a clear path to recover if an update ever misbehaves, which turns "should I risk auto-updates?" into an easy yes.

FAQ

Will automatic updates break my server?

Security-only updates are carefully backported and rarely break anything. The real risk is auto-applying *all* updates — so keep it scoped to the security pocket.

Do I still need to reboot?

Yes, for kernel and some library updates. Either enable automatic reboots at a quiet hour or schedule manual reboots. Tools like needrestart flag services that need restarting.

How do I know it's working?

Check /var/log/unattended-upgrades/ and run a --dry-run. You can also see applied updates in /var/log/dpkg.log.

Should I automate updates on a production app server?

Automate security patches, yes. For everything else, test in staging first. Combining automatic security updates with backups gives you both safety and recoverability.

Setup checklist

Getting reliable, low-risk automatic patching in place is a short list:

• Install unattended-upgrades and enable it with sudo dpkg-reconfigure --priority=low unattended-upgrades.
• Scope it to security — keep only the -security origins enabled in 50unattended-upgrades, not all updates.
• Decide your reboot policy: automatic reboot at a quiet hour, or manual reboots you won't forget.
• Install needrestart so services running outdated libraries get restarted after a patch.
• Test with sudo unattended-upgrade --dry-run --debug and check the log occasionally.
• Pair with backups so you can roll back in the rare event an update misbehaves.

The guiding principle is to automate the low-risk, high-value work — security patches — while keeping feature and major upgrades under your own review. That split gives you the protection of always-current security fixes without the unpredictability of auto-applying everything, which is the balance most production servers want. If you run several servers, keep the unattended-upgrades configuration under version control or a configuration-management tool so every machine applies the same policy — consistency is what prevents one forgotten box from becoming the weak link. A five-minute setup on each server, applied uniformly, quietly closes the patch-window that causes a large share of real-world compromises.

Automatic security updates are the highest-value, lowest-effort security habit you can adopt. Run them on a VPS you fully control — see Nxeon VPS hosting, our security page, and the securing your first Linux VPS checklist.