{"id":1065,"date":"2026-09-06T22:07:47","date_gmt":"2026-09-06T22:07:47","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1065"},"modified":"2026-09-06T22:07:47","modified_gmt":"2026-09-06T22:07:47","slug":"automate-vps-security-patching-unattended-upgrades","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/automate-vps-security-patching-unattended-upgrades\/","title":{"rendered":"How to Automate VPS Security Patching with Unattended Upgrades"},"content":{"rendered":"

Security patches arrive daily. If you patch manually, you are always behind. Unattended-upgrades is the built-in mechanism on Debian and Ubuntu that automatically installs security updates without human intervention. Configured correctly, it keeps your VPS<\/a> patched within hours of a CVE being fixed while avoiding the risk of a broken update taking down your production services. This guide covers setup, fine-tuning, monitoring, and the edge cases that trip people up.<\/p>\n

How Unattended Upgrades Work<\/h2>\n

The unattended-upgrades package runs as a systemd timer (or cron job on older systems). It checks the apt package cache for available updates, filters them by origin (security, stable, backports), downloads the matching packages, and installs them. It can also automatically reboot the server if a kernel update was installed and email you a summary of what it did.<\/p>\n

By default, Ubuntu Server and Debian install the package but only enable it for security updates. This is the correct starting point \u2014 security patches are tested and unlikely to break anything.<\/p>\n

Step 1: Install and Enable<\/h2>\n
# Install the package (usually already present)\nsudo apt install unattended-upgrades apt-listchanges -y\n\n# Enable it for the first time\nsudo dpkg-reconfigure -plow unattended-upgrades\n# Select \"Yes\" when prompted<\/code><\/pre>\n
Verify the timer is active:<\/p>\n
sudo systemctl status apt-daily-upgrade.timer\n\n# Or check the timer schedule\nsudo systemctl list-timers apt-daily-upgrade.timer<\/code><\/pre>\n
Step 2: Configure Update Sources<\/h2>\n
Edit \/etc\/apt\/apt.conf.d\/50unattended-upgrades<\/code>. The critical section is the Unattended-Upgrade::Allowed-Origins<\/code> block. A secure configuration for a production VPS:<\/p>\n
Unattended-Upgrade::Allowed-Origins {\n    \"${distro_id}:${distro_codename}-security\";\n    \"${distro_id}ESMApps:${distro_codename}-apps-security\";\n    \"${distro_id}ESM:${distro_codename}-infra-security\";\n};<\/code><\/pre>\n
This limits automatic updates to security patches only. Do not add ${distro_codename}-updates<\/code> unless you have a staging environment that tests updates before they reach production. A non-security package update can break your application stack.<\/p>\n
Step 3: Blacklist Packages That Should Never Auto-Update<\/h2>\n
Some packages are too risky to update automatically. Add a blacklist in the same configuration file:<\/p>\n
Unattended-Upgrade::Package-Blacklist {\n    \"mysql-server\";\n    \"mysql-server-8.0\";\n    \"postgresql\";\n    \"redis-server\";\n    \"docker-ce\";\n    \"docker-ce-cli\";\n    \"containerd.io\";\n};<\/code><\/pre>\n
Database servers, container runtimes, and custom-compiled packages should be updated manually during a maintenance window. A database major version bump applied automatically at 3 AM is a fast path to an outage.<\/p>\n
Step 4: Configure Automatic Reboots<\/h2>\n
Kernel security updates take effect only after a reboot. Unattended-upgrades can handle this automatically:<\/p>\n
Unattended-Upgrade::Automatic-Reboot \"true\";\nUnattended-Upgrade::Automatic-Reboot-Time \"04:00\";\nUnattended-Upgrade::Automatic-Reboot-WithUsers \"false\";\nUnattended-Upgrade::Remove-Unused-Kernel-Packages \"true\";\nUnattended-Upgrade::Remove-New-Unused-Dependencies \"true\";<\/code><\/pre>\n
The Automatic-Reboot-WithUsers<\/code> setting is important: when set to false<\/code>, the server will not reboot if a user is logged in via SSH. This prevents interrupting an active admin session. Set it to true<\/code> only if you are confident nobody will be logged in at 4 AM.<\/p>\n
If you run a service that needs a graceful shutdown before reboot, add a pre-reboot hook:<\/p>\n
# \/etc\/kernel\/postinst.d\/zzz-pre-reboot\n#!\/bin\/bash\n# This script runs before the automatic reboot\nsystemctl stop my-custom-app\nsleep 5<\/code><\/pre>\n
Step 5: Email Notifications<\/h2>\n
You need to know what unattended-upgrades is doing. Configure email reports:<\/p>\n
Unattended-Upgrade::Mail \"admin@example.com\";\nUnattended-Upgrade::MailReport \"on-change\";\nUnattended-Upgrade::SyslogEnable \"true\";\nUnattended-Upgrade::SyslogFacility \"daemon\";<\/code><\/pre>\n
The on-change<\/code> setting sends an email only when packages were actually installed, not every day. For email delivery, your VPS needs a functioning MTA. A minimal setup with msmtp or postfix relaying through an external SMTP server works well:<\/p>\n
# Install a lightweight mail sender\nsudo apt install msmtp msmtp-mta -y\n\n# Configure \/etc\/msmtprc with your SMTP credentials\n# Then test\n echo \"Test from unattended-upgrades\" | mail -s \"Test\" admin@example.com<\/code><\/pre>\n
Step 6: Dry Run and Verify<\/h2>\n
Before letting unattended-upgrades run on its own, simulate what it would do:<\/p>\n
# Dry run \u2014 shows what would be installed without doing it\nsudo unattended-upgrade --dry-run --debug\n\n# Check the log for any issues\nsudo tail -f \/var\/log\/unattended-upgrades\/unattended-upgrades.log<\/code><\/pre>\n
The dry run output lists every package that would be upgraded. Look for anything surprising \u2014 a kernel update on a system that should not reboot, or a database package that slipped past the blacklist.<\/p>\n
Production Hardening Checklist<\/h2>\n