Most compromised servers are running software with a published fix that nobody applied. Automatic security updates close that gap, and the reason people avoid them. That an update might break something, is addressable instead of a reason to patch by hand and eventually stop.
Security updates only
The distinction that makes this safe.
Automatic security updates apply fixes for known vulnerabilities. Automatic everything updates apply feature changes, which is where breakage comes from.
Configure the first and leave the second manual. On Debian and Ubuntu that is unattended-upgrades restricted to the security origin; on RHEL-family systems it is dnf-automatic set to security updates.
sudo apt install unattended-upgrades sudo dpkg-reconfigure -plow unattended-upgrades
Then read the configuration instead of assuming the default matches what you want: the origins it accepts are the whole decision.
Make it tell you what it did
An update mechanism you never hear from is indistinguishable from one that stopped working.
Set it to email a report, to an address that is not on this server. Then you learn about a package that failed to configure, which otherwise sits broken until something needs it.
Better, watch for the absence of reports too. A monthly glance at whether they are still arriving is what catches the case where the service was disabled during some other change. How to Manage Logs and Log Rotation on a VPS sets out reading the log directly.
Reboots are the part that gets skipped
A kernel update does not take effect until the machine restarts. A library update does not take effect in a running process until that process restarts.
So a server that installs security updates faithfully and never reboots is running the old kernel and the old libraries, with a package list that says otherwise.
Check whether a restart is pending:
ls /var/run/reboot-required sudo needs-restarting -r
Then either enable automatic reboots in a window you chose, or reboot deliberately during maintenance, and reboot at least quarterly regardless, so boot problems surface while you are watching rather than during an unplanned restart. How to Plan and Run Server Maintenance Windows explains the window.
Restarting services without a reboot
Between reboots, updated libraries mean running services are still using the old code in memory.
Tools exist to restart just the affected services, and on Debian-family systems needrestart can do it automatically. That is a reasonable default for a web server and a poor one for a database, where an unexpected restart mid-transaction is worse than the delay.
Decide per service rather than globally, and exclude anything where an abrupt restart costs more than waiting for the next window.
Pin what must not move
If a specific version is required. A database version an application depends on, a PHP version a site needs: hold it explicitly rather than hoping the security channel never touches it.
Then write down that you did, and why. A held package that nobody remembers holding becomes an unpatched package a year later, and the reason it was held is the first thing you will need.
Review held packages twice a year. Most holds outlive the reason for them.
Automatic updates do not cover everything
The gap that catches people.
The mechanism updates distribution packages. It does not touch software you installed another way: something compiled from source, a language runtime installed by a version manager, an application updated through its own mechanism, or anything inside a container image. Running Docker on a VPS deals with that last one, where the image carries its own unpatched operating system.
Keep a short list of what falls outside, and how each one is updated. That list is usually shorter than people expect and never zero.
Test the risky ones elsewhere
If a server runs something where an unexpected update would be costly, run the same updates on a staging machine first.
Even a small VPS matching the production configuration is enough, and it converts "we do not automate updates because they might break something" into a schedule where they are applied a few days behind, after nothing broke.
Verify it is actually running
The step that separates a working setup from a decorative one.
systemctl status unattended-upgrades sudo unattended-upgrades --dry-run --debug
The dry run says exactly what it would install and why. A configuration that looks right and installs nothing is common, usually because the origin pattern does not match the distribution.
Check the log afterwards to confirm real runs are happening, and check again a month later. A mechanism that was working can stop, and it stops silently.
Where it sits
Automatic security updates are one layer. They do not replace a firewall, key-based authentication, or backups you have restored.
What they do is remove the most common route in. A known vulnerability with an available fix, unapplied for months because patching was somebody's intention instead of a schedule. Securing Your VPS: Best Practices walks through the rest of the set.
One other thing belongs in provisioning and is almost always forgotten until it causes an inexplicable fault. For that, see Why a Server Clock Matters and How to Keep It Right.
Know which updates are actually security updates
Configuring security only updates raises an obvious question, which is what the system considers to be one.
apt list --upgradable 2>/dev/null | grep -i security dnf updateinfo list security 2>/dev/null | head -20 dnf updateinfo info --security 2>/dev/null | head -30
The metadata comes from the distribution, and how completely it is populated varies. Some packages receive fixes that are never marked as security updates, which means a machine configured for security only can miss them entirely.
The practical consequence is that security only is a reduction in risk from updating, not an elimination of risk from not updating. Reading the list occasionally, rather than trusting the category, is what catches the difference.
Know when the machine actually needs restarting
Updates land on disk and running processes keep using what they loaded at start, so a patched library is not a patched service until it restarts.
ls /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs
needs-restarting -r 2>/dev/null; needs-restarting -s 2>/dev/null | head
lsof +c0 -d DEL 2>/dev/null | awk '{print $1}' | sort -u | head
The last command lists processes still holding files that have been replaced, which is the direct evidence of what is running old code.
Kernel updates need a restart and nothing else does, so the usual answer is to restart the affected services rather than the machine. Knowing which those are turns an unplanned reboot into a two second service restart.
Watch for the update that stops arriving
Automatic updates fail quietly, and a machine that has not updated for months looks exactly like one that had nothing to update.
ls -la --time-style=+%F /var/log/unattended-upgrades/ 2>/dev/null | tail -5
grep -ciE 'error|failed|held' /var/log/unattended-upgrades/unattended-upgrades.log 2>/dev/null
rpm -qa --last 2>/dev/null | head -5
awk '$3=="install"||$3=="upgrade" {print $1}' /var/log/dpkg.log 2>/dev/null | tail -3
The date of the most recently installed package is the single most useful number here. If it is months old on a machine configured to update automatically, the mechanism has stopped and nobody was told.
The usual causes are unglamorous: a full disk, a repository that no longer resolves, a package waiting on a configuration file conflict, or a distribution version that has passed its support date and has nothing left to serve. Managing logs and log rotation deals with the first.