Set up automatic security updates on Ubuntu 24.04 with unattended-upgrades

The first thing to do on any new Ubuntu 24.04 VPS is to ensure it stays patched against security vulnerabilities without requiring manual intervention every day. Set up automatic security updates on Ubuntu 24.04 VPS with unattended-upgrades to close critical CVEs before they get exploited, no admin login required.
Prerequisites
- An Ubuntu 24.04 LTS VPS (or a fresh installation) with root or sudo access.
- A non-root sudo user (recommended; the guide uses
sudofor commands). - Internet connectivity from the VPS to access the Ubuntu repositories.
- SSH access (port 22 by default, or a custom port).
Why automate security updates on a VPS?
Running a VPS that faces the internet trong giờ hành chính means attackers scan for known vulnerabilities every day. High-profile CVEs in kernel, OpenSSL, sudo, or systemd get fixes within hours, but leaving the update step to a manual admin is a bet you will lose. Automated patching, via unattended-upgrades, installs security updates automatically, reducing the window of exposure from weeks to a few hours. This is not about "set and forget" for convenience; it is about reducing your server's attack surface.
For production systems on a VPS Vietnam, where uptime matters and manual intervention is not always possible, this configuration is a baseline requirement, not an optional extra. Combined with a minimal attack surface (disabled root login, firewall, and fail2ban), automatic security updates provide the first layer of defense.
Step 1, Install unattended-upgrades
The package is usually pre-installed on Ubuntu 24.04. Verify and, if missing, install it:
sudo apt update
sudo apt install unattended-upgrades -y
Then verify the executable exists and its version:
dpkg -l | grep unattended-upgrades
Expected output includes a line like ii unattended-upgrades 2.9.4 all automatic installation of security upgrades. If you see nothing, install it with the command above.
Step 2, Enable and configure automatic update download
The file /etc/apt/apt.conf.d/20auto-upgrades controls the apt periodic behavior. Use the interactive configuration tool to generate it correctly:
sudo dpkg-reconfigure --priority=low unattended-upgrades
When prompted: Answer "Yes" to automatically download and install stable updates. This creates or updates /etc/apt/apt.conf.d/20auto-upgrades with two lines:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Verify the file content:
cat /etc/apt/apt.conf.d/20auto-upgrades
If both lines show "1", the system will refresh package lists and run unattended upgrades daily.
For finer control, you can also set APT::Periodic::Download-Upgradeable-Packages "1"; and APT::Periodic::AutocleanInterval "7"; in the same file to keep the cache clean.
Step 3, Customize which updates are applied
The main configuration file is /etc/apt/apt.conf.d/50unattended-upgrades. Open it with your editor:
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
The key block that defines allowed origins (i.e., which repositories' updates will be installed) looks like this:
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}-security";
// "${distro_id}:${distro_codename}-updates";
// "${distro_id}:${distro_codename}-proposed";
// "${distro_id}:${distro_codename}-backports";
};
By default, only security updates are enabled (the -security suite). This is the recommended setting for a production VPS: you get fixes for known vulnerabilities, but not standard bugfixes or feature updates that might introduce regressions.
If you want to include the -updates repository (non-security bugfixes), uncomment that line. For most servers, leave it as is.
Other important options in the same file:
Unattended-Upgrade::Automatic-Reboot "false";, set to"true"if you are willing to reboot when the update requires it (e.g., kernel updates). Default isfalse, which leaves the system running and unpatched until a manual reboot.Unattended-Upgrade::Automatic-Reboot-Time "02:00";, if reboots are enabled, set the time (2 AM is a common low-traffic window).Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";, keep the boot partition clean by removing old kernels.Unattended-Upgrade::Remove-Unused-Dependencies "true";, autoremove packages no longer needed.
After editing, save and close. Test the configuration for syntax errors:
sudo unattended-upgrades --dry-run --debug
This runs a simulation without installing anything. Watch the output for errors like "unknown allowed origin". If it completes without red errors, the config is valid.
Step 4, Enable email notifications (optional but recommended)
Unattended upgrades can send a summary email when changes are made. In /etc/apt/apt.conf.d/50unattended-upgrades, find:
// Unattended-Upgrade::Mail "root";
Uncomment and replace root with your real email address (if you have a mail server, Postfix or a local MTA set up on the VPS):
Unattended-Upgrade::Mail "[email protected]";
Also set:
Unattended-Upgrade::MailOnlyOnError "true";
This way you only get an email when something goes wrong, keeping your inbox clean during normal operations.
Step 5, Verify the service is running
The unattended-upgrades service is triggered by a systemd timer, not as a persistent daemon. Check the timer is active:
sudo systemctl status apt-daily-upgrade.timer
Expected output: Active: active (waiting). The timer fires around 6 AM (UTC) by default, and runs the apt-daily-upgrade.service which executes unattended-upgrades.
To see the last trigger time:
sudo systemctl list-timers apt-daily-upgrade.timer
Check the logs for a successful run:
sudo journalctl -u apt-daily-upgrade.service --since "1 day ago" | tail -20
You should see lines like "All upgrades installed" or "No packages found that can be upgraded unattended".
To force an immediate run (for testing):
sudo unattended-upgrades -v
Watch the verbose output. If it reports errors, review /var/log/unattended-upgrades/unattended-upgrades.log and /var/log/unattended-upgrades/unattended-upgrades-dpkg.log.
Troubleshooting
1. Updates not being installed at all
Check the log file first: sudo cat /var/log/unattended-upgrades/unattended-upgrades.log. Common causes: the allowed origins are misconfigured (uncommented a non-security repository that does not exist), or the apt cache is broken (sudo apt update to repair).
2. "dpkg: error: unable to lock database"
Another apt process is running. Wait for it to finish, or kill it with sudo killall apt-get dpkg. This often happens if you manually update while the timer runs.
3. Reboots happening at the wrong time
Ensure Unattended-Upgrade::Automatic-Reboot "true"; is set only if you are prepared for the server to restart. Always test the reboot time with Unattended-Upgrade::Automatic-Reboot-Time "HH:MM"; and verify it does not clash with your backup window or other cron jobs.
4. Email notifications not arriving
The VPS needs a working MTA (Postfix or a lightweight like msmtp). On a basic VPS, Postfix in "local only" mode often fails because there is no relay. Consider setting up a transaction mail provider (e.g., SendGrid, Mailgun) to relay alerts, or rely on external monitoring instead.
FAQ
Will unattended-upgrades break my application?
Security updates are backport fixes that rarely break APIs. However, if your application depends on a specific library version, test on a staging VPS first. You can limit updates to only security fixes (the default) to minimize risk.
Do I need to reboot after every kernel update?
No. The old kernel remains running until you reboot manually or enable Automatic-Reboot in the config. The new kernel is installed but dormant. For many VPS workloads, a monthly scheduled reboot during maintenance windows is sufficient to activate the new kernel.
Can I update non-security packages automatically?
Yes, uncomment the -updates or -backports lines in 50unattended-upgrades. For production, avoid backports (less tested). For a personal Linux VPS, enabling -updates provides bugfixes as well as security patches.
How do I check what was updated?
The main log at /var/log/unattended-upgrades/unattended-upgrades.log lists every package installed. For dpkg details, check /var/log/dpkg.log. You can also run zgrep -h "upgrade" /var/log/unattended-upgrades/*.log.
Is this enough to secure my VPS?
No. Automatic updates are one layer. You still need a firewall (ufw or nftables), SSH hardening (disable root login, use keys), fail2ban or CrowdSec, and regular security audits. For a guide on SSH hardening, see hardening SSH on a new VPS.
Can I set a custom schedule instead of the default daily?
Yes. Edit /etc/systemd/system/timers.target.wants/apt-daily-upgrade.timer to change OnCalendar. For example, OnCalendar=daily runs once a day; you can set OnCalendar=*-*-* 02:00:00 for a fixed 2 AM run. Then reload: sudo systemctl daemon-reload && sudo systemctl restart apt-daily-upgrade.timer.
Related articles
- Hardening SSH on a new VPS, keys, ports, fail2ban and CrowdSec
- Security audit and hardening with Lynis on a VPS
- Configure swap and optimize memory on a low-ram VPS
- How to connect to a Linux VPS for the first time via SSH


