Plan automatic security updates on Debian and Ubuntu

Check the operating system and recovery copy

~~CloudExa~~Automatic security updates reduce the time a known vulnerability remains unpatched. They still need monitoring and a recovery plan. This guide concerns supported Debian and Ubuntu VPS installations, not a distribution release upgrade or a replacement of your operating system.

Record the installed release, applications and third-party repositories. Take a current backup of configuration and application data, exporting databases consistently. Confirm that you can use the browser console if SSH becomes unavailable. A snapshot may help ~~guide.~~recovery, but it is not a substitute for an independent backup.

Inspect what is already enabled

Cloud images and manually installed systems may differ. Check rather than assuming the package is configured:

dpkg-query -W unattended-upgrades
systemctl list-timers "apt-daily*" --all
apt-config dump

Review the relevant output privately. A timer existing does not prove successful recent patching. Inspect /etc/apt/apt.conf.d/20auto-upgrades and the installed unattended-upgrades configuration, usually 50unattended-upgrades. Preserve custom settings and read the release-specific comments.

If the package is missing, install it through the distribution's normal APT process after reviewing proposed changes. Debian provides sudo dpkg-reconfigure unattended-upgrades to configure periodic unattended updates. Do not run multiple package managers simultaneously or delete their lock files to bypass an active upgrade.

Review repositories and simulate the policy

Limit permitted origins to the updates you intend to install automatically. Debian and Ubuntu use different origin names and configuration examples; do not paste one distribution's block into the other. A repository being present in APT does not automatically mean unattended-upgrades will select its packages.

Check the proposed policy with:

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

Review which origins and packages are allowed or excluded. Investigate signature, repository or dependency errors instead of disabling authentication checks. A dry run does not install those upgrades, and its output is evidence about that run rather than a future guarantee. Keep debug output private if it reveals internal repository details.

Choose restarts and reboots deliberately

Package installation may restart services. Some processes continue using old libraries until restarted, and a new kernel normally needs a reboot before it runs. Coordinate these effects with application owners, including saving game worlds and stopping database writes where appropriate.

Review Unattended-Upgrade::Automatic-Reboot explicitly. If you keep it false, arrange a monitored maintenance process for required reboots rather than leaving them pending indefinitely. If enabling it, choose a suitable window and understand that applications can be interrupted. Ubuntu commonly signals a required reboot through /run/reboot-required; do not assume every Debian installation provides the same marker.

Verify the result and alert on failures

Inspect /var/log/unattended-upgrades/, package history and timer execution after the first run. Check that key services answer real requests, then repeat after a planned reboot. Configure a working alert destination and test delivery; merely entering an email address does not establish a mail transport.

Keep major operating-system upgrades and application feature upgrades as separate tested changes. If an update fails, preserve its logs and resolve the specific package issue. Send support the release, timestamp and redacted error rather than repeatedly rebooting or reinstalling the VPS.

For service access, see VPS access and console recovery. When contacting us, follow the support-ticket checklist.