Unattended-Upgrades: Automatic Security Updates on Ubuntu and Debian Without Surprises

2026-08-08·7 min read

A large portion of compromised servers fall not to sophisticated exploits, but to vulnerabilities known for months that no one patched. Keeping the operating system updated is one of the highest-ROI measures in any VPS hardening plan, and on Ubuntu/Debian it can be fully automated using unattended-upgrades.

In this guide, we configure it to install security patches automatically, without surprises or major updates that could break your application.

1. Installation

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

apt-listchanges is optional but recommended: it shows (or emails you) the changelog of each package before or after updating, so you know exactly what changed.

2. Enabling the service

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

This creates /etc/apt/apt.conf.d/20auto-upgrades with the following configuration, enabling daily update checks:

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

3. Choosing what updates automatically

The key configuration file is /etc/apt/apt.conf.d/50unattended-upgrades. By default, it typically includes only the security repository:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

This is intentionally conservative: only security patches are installed, not the entire standard repository. Adding ${distro_codename}-updates would also pull non-security bug fixes, introducing greater risk of regressions.

4. Avoiding unexpected reboots

Some updates (typically kernel patches) require a server reboot to take full effect. You can configure how this is handled in the same file:

// Do not reboot automatically
Unattended-Upgrade::Automatic-Reboot "false";

// If you prefer automatic reboots, set a low-traffic time
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

If you leave Automatic-Reboot set to false, the system will continue running the old in-memory kernel until manually rebooted, which poses a risk if a critical vulnerability was patched. For production systems without defined maintenance windows, setting an automatic reboot time during off-peak hours is generally safer.

5. Getting notifications of installed updates

Configure your email address so each run reports updated packages and errors:

Unattended-Upgrade::Mail "you@email.com";
Unattended-Upgrade::MailOnlyOnError "false";

6. Testing the configuration

To trigger a dry-run test and see detailed logs without waiting for the daily timer:

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

And to inspect the actual execution logs:

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

7. Automation does not replace supervision

Unattended-upgrades significantly narrows the exposure window against known CVEs, but it won't tell you if a service stopped responding after a reboot or if a container failed to restart. That is precisely the type of silent failure discussed in our article on cron jobs that fail without warning: an automated job that quietly fails until disaster strikes.

With SecuryBlack and heartbeat monitoring, you can track whether your scheduled tasks — including nightly updates — continue running successfully and receive instant alerts if anything goes wrong.