Unattended-Upgrades: Automatic Security Updates on Ubuntu and Debian Without Surprises
Security · · 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.