Automating Ubuntu Security Patches: How to Use unattended-upgrades Effectively – ITFROMZERO

Table of Contents

Why You Shouldn’t Update Your Server Manually

If you’re only managing 1-2 VPS instances, SSH-ing in and running sudo apt update && sudo apt upgrade every morning might seem perfectly manageable. But once your infrastructure grows to 10 or 20 servers, that routine quickly becomes a serious burden. Skip it for just a week, and your servers could already be exposed to dozens of newly disclosed security vulnerabilities.

In practice, critical vulnerabilities are often exploited by attackers within just 24-48 hours of public disclosure. Without an automated patching mechanism, you’re leaving a dangerous window open in your systems. That’s why I always install unattended-upgrades the moment I spin up a new server. It silently patches the system in the background — so you can actually sleep soundly at night.

How unattended-upgrades Works

At its core, this is a background script that runs on a schedule to check for updated packages from your configured repositories. Its most valuable feature is filtering: you can configure it to install only critical security patches, while skipping major feature updates that carry a higher risk of breaking things or causing application conflicts. Your server stays secure without sacrificing stability. For a more comprehensive security baseline on top of this, consider automating CIS Benchmarks hardening with USG.

Step-by-Step Setup Guide

Step 1: Install the Required Packages

Most modern Ubuntu Server releases already include this tool. That said, run the following command to make sure all supporting components are in place:

sudo apt update
sudo apt install unattended-upgrades update-notifier-common -y

The update-notifier-common package is important — it allows the system to detect and create the signal file that indicates a reboot is required after an update.

Step 2: Configure Which Packages Are Allowed to Update

All the core settings live in /etc/apt/apt.conf.d/50unattended-upgrades. This is where you tell the server exactly what it’s allowed to install automatically.

Open the file with your preferred editor:

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

Find the Unattended-Upgrade::Allowed-Origins section. For production environments, I recommend only uncommenting the security line. This minimizes the risk of unexpected software breakage:

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

To optimize disk usage, enable automatic cleanup of unused packages (this can free up anywhere from 200MB to 1GB of space over time):

Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

Step 3: Schedule Automatic Runs

Once you’ve defined what gets updated, the next step is setting how often it runs. Edit the file /etc/apt/apt.conf.d/20auto-upgrades:

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

Paste the following to have the system check for and apply updates once per day:

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

Setting Up Email Notifications

Letting your server run on autopilot without any reporting can feel unsettling. I’ve had this email notification setup running across 50+ servers at work to monitor patch status every morning. For a higher-level daily digest of your entire server activity beyond just patches, pairing this with Logwatch is a solid combination. Note: your server needs a Mail Transfer Agent (MTA) such as postfix or msmtp installed for this to work.

In the 50unattended-upgrades file, find and fill in your email address on this line:

Unattended-Upgrade::Mail "[email protected]";

To keep everything visible, set the following option to false. This way you’ll receive a notification even when updates succeed, not just when something goes wrong:

Unattended-Upgrade::MailOnlyOnError "false";

Handling Automatic Reboots

Kernel patches typically require a system restart to take effect. If minimizing downtime is a priority, Ubuntu Pro’s Livepatch feature can apply certain kernel patches without requiring a reboot at all. Otherwise, you can configure the server to automatically reboot during your lowest-traffic window — for example, at 3:00 AM:

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

Warning: If you’re running stateful services like a Database Cluster or applications that don’t restart automatically with the system, think carefully before enabling this feature.

Testing and Monitoring Logs

To verify your configuration is correct, run a dry-run simulation. This will walk through the entire update process without actually making any changes to the system:

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

To review the history of installed packages, you can tail the log file directly at:

tail -f /var/log/unattended-upgrades/unattended-upgrades.log

Lessons from Real-World Deployments

After years of managing Linux infrastructure, here are three key takeaways I always come back to:

Never auto-update databases: Do not enable automatic updates for MySQL, PostgreSQL, or MongoDB. Database patches often modify configuration files or data structures, and can easily bring your application to a halt.
Always test on Staging first: Run this configuration on a staging environment for at least one week before rolling it out to production.
Monitor /boot partition space: Old kernel versions can eventually fill up the /boot partition. Even with Autoclean enabled, periodically check with df -h and consider a deep clean to purge old kernels to avoid boot failures.

Deploying unattended-upgrades is a small step that delivers a massive security payoff. Here’s to managing your Ubuntu systems smarter!