Enable automatic security updates

Unpatched software is one of the most common ways servers get compromised. Ubuntu's unattended-upgrades package installs security updates automatically, so your VPS stays protected between the times you log in. This guide turns it on, checks what it does, and shows how to handle reboots.

Before you begin

An Ubuntu 24.04 LTS VPS with SSH access as a sudo user, such as alex.
Some understanding that automatic updates can restart services or, if you allow it, the whole machine.
Access to the server if something goes wrong. Keep your SSH session or console available while you test.

Step 1: Install unattended-upgrades

Refresh the package list and install the package. Ubuntu often includes it already, and the command is harmless if it does.

sudo apt update
sudo apt install -y unattended-upgrades

Step 2: Turn on the daily schedule

Two settings control the schedule: one refreshes the list of available packages each day, and the other runs the upgrade. Write them to a small file in apt's configuration folder. The tee command writes the text between the markers to that file.

sudo tee /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF

A value of "1" means once per day. Setting either to "0" turns that part off.

Tip: You can also run sudo dpkg-reconfigure -plow unattended-upgrades and answer Yes to the question. It writes the same file.

Step 3: Run a dry run

A dry run simulates an upgrade without changing anything. It is a safe way to see what would be installed. The last lines show a summary.

sudo unattended-upgrade --dry-run --debug | tail -n 20

Packages that will be upgraded: libssl3t64 openssh-client
Writing dpkg options file ...
Fetched 0 B in 0s (0 B/s)
Dry run finished

If the list says no packages will be upgraded, your system is already current, which is also fine.

Step 4: Confirm that only security updates are included

By default Ubuntu limits automatic upgrades to its security pocket. Check the allowed origins in the main configuration file:

grep -A4 "Allowed-Origins" /etc/apt/apt.conf.d/50unattended-upgrades

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

Keep the -security entries enabled. Regular updates still need your attention, so run sudo apt update && sudo apt upgrade every so often.

Step 5: Decide how to handle reboots

Some updates, mostly kernel and core library updates, need a reboot before they take effect. Ubuntu leaves a marker file when one is needed. By default, unattended-upgrades does not reboot the server. You can allow an automatic reboot at a quiet time by editing the main configuration:

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

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

Careful: An automatic reboot stops every service for a minute or two. Enable it only if your applications start on boot and you accept a short outage.

Step 6: Check that it is working

Confirm the service is running, the daily timer is scheduled, and the log shows the latest activity:

systemctl status unattended-upgrades --no-pager
systemctl list-timers apt-daily-upgrade.timer --no-pager
tail -n 20 /var/log/unattended-upgrades/unattended-upgrades.log

Then check whether a reboot is pending:

test -f /var/run/reboot-required && echo "Reboot needed" || echo "No reboot needed"

No reboot needed

Troubleshooting

Could not get lock /var/lib/dpkg/lock: another package process is running, often the automatic update itself. Wait a few minutes and try again. Do not delete lock files.
No upgrades appear in the log: confirm the timer is listed in the output above, and that the server can reach the Ubuntu package mirrors with sudo apt update.
Changes to the configuration seem ignored: check for typos and missing semicolons, then re-run the dry run to see the effect.
Reboot needed but not yet done: reboot at a convenient time with sudo reboot, and reconnect to confirm the services came back.

Next steps

Automatic patches reduce risk, but they do not replace monitoring. Set up uptime checks such as LightServe Beacon so you learn quickly if a service stops after an update. The journal guide shows how to read the logs when that happens.