VPS Automatic Security Updates and Reboot Plan (2026): How to Set Up unattended-upgrades, reboot-required, and Maintenance Windows

The official Ubuntu Server documentation places automatic updates under software management, and the core component is unattended-upgrades. It can automatically install security updates, and it can also be configured to decide whether to automatically clean up and whether to automatically reboot.

But these actions should be viewed separately:

• Automatically checking for updates
• Automatically downloading updates
• Automatically installing security updates
• Whether a reboot is needed after updates
• Whether it actually reboots automatically
• Whether services recover normally after the reboot

Many VPSs only get to the third step. The security packages are indeed installed, but the machine is not rebooted, and no one checks the web service, database, or Docker containers. For a personal blog this may be only a minor risk; for a website with orders, logins, and payment callbacks, it can turn into a production incident.

First confirm whether the package is installed:

dpkg -l unattended-upgrades

If it is not installed, you can install it:

sudo apt update
sudo apt install unattended-upgrades

Then check the automatic update configuration:

cat /etc/apt/apt.conf.d/20auto-upgrades

A common configuration looks like:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

These two lines roughly mean: update the package list every day, and run unattended-upgrades.

You can also confirm with apt's own configuration output:

apt-config dump | grep -E 'APT::Periodic|Unattended-Upgrade'

If you only see Update-Package-Lists and not Unattended-Upgrade, it may mean only the package list is refreshed automatically, and security updates are not installed automatically.

Current Ubuntu/Debian systems usually trigger apt-related tasks through systemd timers. You can check:

systemctl list-timers | grep apt

You may see:

apt-daily.timer
apt-daily-upgrade.timer

Then check the specific status:

systemctl status apt-daily.timer
systemctl status apt-daily-upgrade.timer

Do not relax just because you see the timer active. A timer being active only means it will run on schedule; it does not mean every update succeeds.

Checking the logs is more reliable:

sudo ls -lh /var/log/unattended-upgrades/
sudo tail -n 80 /var/log/unattended-upgrades/unattended-upgrades.log

If you want to check apt-related history:

sudo less /var/log/apt/history.log
sudo less /var/log/apt/term.log

Focus on whether there is information like failed, kept back, dependency problem, or dpkg interrupted.

For an ordinary VPS, I prefer to automatically install security updates rather than installing all ordinary updates unattended.

The reasons are practical:

• Security updates are usually more suitable for automation
• Ordinary version updates may bring configuration changes
• Major version changes to databases, language runtimes, and web services are more likely to affect applications
• Small teams or personal sites do not have full regression testing

/etc/apt/apt.conf.d/50unattended-upgrades configures the sources allowed for automatic updates. On Ubuntu, the security pocket is commonly enabled. You can check:

sudo grep -n "Allowed-Origins" -A 20 /etc/apt/apt.conf.d/50unattended-upgrades

Do not copy a big block from the internet without reading the configuration. Different Ubuntu versions, whether Ubuntu Pro is enabled, and whether third-party sources exist can all make the configuration different.

My advice is:

• System security patches: can be installed automatically
• Third-party repositories: be cautious about automatic updates
• Database major versions: do not upgrade unattended
• Business applications: follow your own release process

Automatic updates are meant to reduce low-level security risks, not to do complete change management for you.

On Ubuntu/Debian, the most direct check:

test -f /var/run/reboot-required && cat /var/run/reboot-required

If it exists, it usually outputs:

*** System restart required ***

You can also see which packages triggered the reboot requirement:

cat /var/run/reboot-required.pkgs

Commonly you will see:

linux-base
linux-image-...
libc6

If the kernel was updated and you want to confirm which kernel is currently running:

uname -r
dpkg -l 'linux-image*' | grep '^ii'

If the new kernel is already installed but uname -r is still the old version, that means a reboot is needed to switch over.

unattended-upgrades can be configured to reboot automatically; for example, the relevant option usually looks like:

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";

Here I do not recommend everyone change it to true directly.

The risks of automatic reboot are concrete:

• Services do not start automatically after the machine reboots
• Docker containers do not have a restart policy set
• Firewall rules are lost after the reboot
• Database recovery is slow, and the website returns 502 for a short time
• Disk checks or cloud provider maintenance make startup take longer
• You are in the middle of an SSH session and the machine suddenly reboots
• A small website is unattended, and it is down for half a day before anyone notices

If it is a pure test VPS, automatic reboot is not a problem. If it is a production site, I prefer "automatic installation of security updates + manual/semi-automatic reboot in a fixed maintenance window."

For most small websites, I would arrange it like this:

• Automatically check for and install security updates every day
• Fix a low-traffic maintenance window every week, for example Tuesday 03:30
• Check /var/run/reboot-required before the maintenance window
• If a reboot is needed, first confirm backups, service status, and monitoring
• Run a set of health checks after the reboot

A simple pre-maintenance check:

hostnamectl
uptime
systemctl --failed
df -h
df -i
free -m
test -f /var/run/reboot-required && cat /var/run/reboot-required

If systemctl --failed already shows failed services, do not rush to reboot. First figure out whether the failed services are critical. Otherwise, after the reboot it may turn into "originally only one service failed, now the whole site will not open."

Before rebooting the VPS, check whether critical services are enabled:

systemctl is-enabled nginx
systemctl is-enabled mysql
systemctl is-enabled postgresql
systemctl is-enabled docker

If you use Docker Compose, confirm the container restart policy:

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
docker inspect --format '{{.Name}} {{.HostConfig.RestartPolicy.Name}}' $(docker ps -q)

Common policies include:

always
unless-stopped
on-failure

If your website depends entirely on Docker, but Docker does not start on boot, or the containers have no restart policy, the website will likely not recover automatically after the VPS reboots.

When the maintenance window arrives, it is advisable to first leave yourself a record of the current state:

date
uptime
systemctl --failed
ss -lntp

Then reboot:

sudo reboot

If it is a remote VPS, wait 1-3 minutes after the reboot before SSHing back in. Different cloud providers, different kernel updates, and different disk states can all make startup times differ.

After coming back, first check:

uptime
uname -r
systemctl --failed
journalctl -b -p warning --no-pager | tail -n 80

Then check the business services:

systemctl status nginx --no-pager
systemctl status docker --no-pager
curl -I https://example.com

If the website has a database, queue, or cache behind it, check the corresponding services too. Do not stop just because SSH can connect.

I usually prepare a very plain but effective checklist:

systemctl --failed
journalctl -b -p err --no-pager
ss -lntp
df -h
df -i
free -m

For web sites, add:

curl -I https://example.com
curl -I https://example.com/login

Nginx:

sudo nginx -t
sudo tail -n 80 /var/log/nginx/error.log

Docker:

docker ps
docker compose ps
docker compose logs --tail 80

Database:

systemctl status mysql --no-pager
systemctl status postgresql --no-pager

This is not to show off commands, but to avoid "the machine rebooted, but the business did not recover." The loop for security updates should be: install, reboot, verify, record.

Some VPSs really cannot be rebooted casually, for example when running a campaign, data migration, long tasks, or when you temporarily have no one on duty.

At this point, at least do three things:

• Record the reason a reboot is currently needed
• Assess which packages are involved
• Agree on a clear reboot time

You can check:

cat /var/run/reboot-required.pkgs
apt list --upgradable

If it is a kernel security update, the risk of not rebooting for a long time will keep increasing. You can postpone it for a few days, but do not drag it out indefinitely.

Some distributions or commercial solutions support live patching, which can apply some kernel security patches without a reboot. But it is not a silver bullet, and it cannot replace all reboots. For ordinary cheap VPSs, the most reliable approach is still to arrange a maintenance window.

If you use the RHEL family, the idea is the same, but the tools are different.

Common commands:

sudo dnf update --security
sudo needs-restarting -r

needs-restarting usually comes from dnf-utils or the corresponding toolkit. It can determine whether a reboot is needed.

For scheduled automatic updates, check dnf-automatic:

sudo dnf install dnf-automatic
systemctl status dnf-automatic.timer

Different distributions have different configuration file paths, so do not force Ubuntu's unattended-upgrades configuration onto Rocky/AlmaLinux.

If you do not want to deal with a complex process, you can follow this minimum setup:

Once a week, during low-traffic hours, run:

sudo apt update
sudo apt list --upgradable
sudo unattended-upgrade --dry-run --debug

After confirming there are no obvious abnormalities, let the system install security updates automatically, or run manually:

sudo unattended-upgrade

If a reboot is needed:

test -f /var/run/reboot-required && cat /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Before rebooting:

systemctl --failed
df -h
df -i

After rebooting:

uptime
uname -r
systemctl --failed
curl -I https://example.com
journalctl -b -p err --no-pager

Finally, write down the date, updated packages, whether a reboot was performed, and whether there were any abnormalities. Even if it is only recorded in a Markdown file, it is better than relying entirely on memory.

• Confirmed whether unattended-upgrades is installed
• Confirmed /etc/apt/apt.conf.d/20auto-upgrades
• Checked apt-daily.timer and apt-daily-upgrade.timer
• Reviewed the /var/log/unattended-upgrades/ logs
• The automatic update scope covers only appropriate software sources
• Checked /var/run/reboot-required
• Reviewed /var/run/reboot-required.pkgs
• Decided whether to enable automatic reboot
• Production VPSs have a fixed maintenance window
• Before rebooting, checked systemctl --failed, disk, and memory
• Confirmed Docker / Nginx / database start on boot
• After rebooting, checked services, ports, logs, and website HTTP status
• Every patch and reboot has a simple record

The two extremes to fear most with VPS security updates: one is not updating at all, and the other is blindly auto-rebooting. A more reliable approach is to use automation for repetitive, low-risk tasks and put reboots into a maintenance window where you can watch it recover. That way, vulnerability patches will not be delayed for months, and the website will not be rebooted in the middle of the night and left down with no one noticing.