Automating Security Updates with unattended-upgrades

The security update you slap on in three weeks, when you finally get around to it, is the update an attacker exploited two weeks ago. Manual patching is how most VPS servers end up carrying known, patchable vulnerabilities for far longer than they should. unattended-upgrades on Debian and dnf-automatic on Rocky exist to close that gap: they pull and apply security updates on a schedule without ceremony or downtime, while leaving you in control of what actually gets installed.

Why Unattended Patching Beats "I Will Get To It"

When a security advisory ships, the attacker's scanner races the operator's calendar. Every day you wait to patch a public-facing service is a day the exploit is known and available to anyone who targets your box. Unattended patching inverts the incentive: the window between advisory and protection shrinks from "whenever someone remembers" to "within a day, automatically." The fear that automation breaks a running service is usually unfounded when the scope is narrowly security-only and the schedule is sensible. The real engineering is in the configuration — getting the origin filtering, the restart policy, and the notification right so the machine protects itself without needing a babysitter.

Set Up unattended-upgrades on Debian and Ubuntu

unattended-upgrades ships preinstalled on modern Ubuntu and its default behavior — security updates only, applied nightly — is a sane baseline. Install or confirm it, then review the configuration that decides which origins are eligible. On Debian the package may need an explicit install; on either, the allowed origins are the core of the policy.

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
cat /etc/apt/apt.conf.d/50unattended-upgrades

The reconfigure prompts are the fastest safe path, and the 50unattended-upgrades file holds the origin patterns that decide what gets installed. The most important decision is nailing it to security-only: leaving the non-security lines commented out keeps version upgrades (with their bigger blast radius) manual while security fixes flow automatically.

Configure for Your Risk and Maintenance Windows

The defaults are safe but not tuned. The two configuration knobs that matter most are which package origins are eligible and how the system handles a kernel install that wants a reboot. Many hosts prefer to let security packages install automatically while keeping the decision to reboot the machine under human control, scheduled during a true maintenance window rather than at 3 a.m. mid-flood.

sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
Apt::AutomaticRemove::SuggestsImportant "true";
EOF

These directives turn on automatic list refreshes and the unattended upgrade itself. The AutomaticRemove line prunes packages marked important-but-unneeded, keeping the system lean. Whatever you choose, keep the periodic and upgrade toggles on — those two lines are literally the difference between "security updates scheduled" and a config file that does nothing.

The Rocky and Fedora Side: dnf-automatic

On Rocky and other RHEL-family systems the equivalent is dnf-automatic, which ships a timer that runs on a schedule and can be told to apply upgrades without user interaction. The config file /etc/dnf/automatic.conf carries the key decision: whether the timer applies only security patches or everything.

sudo dnf install -y dnf-automatic
sudo sed -i 's/^apply_updates = no/apply_updates = yes/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer
sudo systemctl list-timers | grep dnf

The sed switch flips the central toggle so the timer actually installs what it downloads instead of just reporting. The systemctl enable --now plus the list-timers check confirms the schedule is live — if the timer is not running, you have a well-configured tool that never runs, which is worse than no tool at all.

Notify, Because Silence Is Not Evidence

Automation you cannot see fail violates trust in the whole system. Both patching tools can email a summary per run, and you should enable that on production. A daily "no updates" email is the quiet confirmation that the loop is healthy; a "security updates applied" email is your audit record of what changed and when. Without it, a broken update path runs silently and you only discover the gap while assessing a breach.

For a system that patches the kernel automatically, decide explicitly on the reboot story. If you permit fully automatic kernel replacement, plan for a reboot — either scheduled in off-hours or verified manually. If you prefer to stage kernels and reboot on your own maintenance schedule, keep patching automatic and make the reboot the only manual step. Either policy is defensible; the indefensible one is patching quietly with no reboot plan and no notification.

Takeaway

unattended-upgrades on Debian and dnf-automatic on Rocky turn "remember to patch" into a scheduled, narrow, notified process that closes known-exploit windows within a day. Pin it to security-only, flip the apply toggle, keep the timer alive, and know exactly how reboots happen. A Netbay VPS boots a clean base image ready for unattended patching, so you can close the auto-update loop before your workload ever faces the internet — netbayhosts.in.