Updating a server without downtime
A server must not be left without updates, yet every update risks taking the site down. The risk is managed with a process: small security fixes are installed automatically, major changes follow a plan with a snapshot, testing and a ready rollback, and reboots are grouped into a maintenance window. Here is how to set this up on a single VPS.
Server updates come in two kinds, and they need to be handled differently. Security fixes are released often, change little and almost never break anything, so it is best to install them automatically on the same day. Planned upgrades, such as a new version of the operating system, PHP, the database or the panel, change how programs behave, so they are prepared and tested. Downtime is most often caused not by an update as such but by a major change being installed as if it were a minor one.
Automatic security updates
On Ubuntu Server, the unattended-upgrades package is installed and enabled by default: once a day it installs security updates only, and the other origins in /etc/apt/apt.conf.d/50unattended-upgrades are commented out. The frequency is set in 20auto-upgrades, and the log is written to /var/log/unattended-upgrades/. Debian uses the same package, but a minimal installation may not include it; how to enable it is described on the Debian Wiki page.
On AlmaLinux and other RHEL-compatible systems, the same job is done by dnf-automatic. By default it does not install updates: in /etc/dnf/automatic.conf you set upgrade_type = security and apply_updates = yes, and then enable the dnf-automatic.timer timer.
Neither tool reboots the server by default. That is the right behaviour: a server should not restart at peak time. But the reboot must not be forgotten either, because an updated kernel and libraries only take effect after a restart. On Ubuntu and Debian, the file /run/reboot-required signals that a reboot is needed; on AlmaLinux, the command dnf needs-restarting -r does. It is worth adding this check to your server monitoring and doing the reboot itself in a maintenance window.
A snapshot before a planned upgrade
Before any major change, take a disk snapshot in the host's control panel. If the upgrade goes wrong, it returns the server to its original state within minutes. According to the accsly.io catalog as of November 2026, backup terms are described by 1,644 of 2,247 VPS hosts, and 318 of them explicitly mention snapshots. If your host does not offer snapshots, you need a full backup before the upgrade, one that you have already verified by restoring it.
Two caveats. A snapshot is usually stored in the same place as the server's disk and does not replace a backup: if the storage fails, both are lost. In addition, a snapshot of a running database may be inconsistent, so before taking it you dump the database or briefly stop writes. How to build a complete backup setup is explained in the article VPS backups: strategies and tools, and plans with space for backups are on the page VPS for backups.
Blue-green and rolling updates on a single VPS
Zero-downtime techniques come from large systems with several servers behind a load balancer: blue-green keeps two complete copies and switches traffic from one to the other, while a rolling update takes servers out of service one at a time. On a single VPS, the same ideas apply to the application, though not to the operating system itself.
- Release directories. Each version of the site is deployed to its own directory, such as
releases/2026-11-07, and the web server points to acurrentsymlink. The new version is prepared alongside (dependencies, build, cache), and then the link is switched with a single command. Rolling back means pointing the link at the previous directory. - Two application instances. The new version is started on another port or in another container, checked, and then nginx is switched over to it. Reloading the nginx configuration does not drop connections: according to the nginx documentation, the master process first checks the configuration and keeps running with the old one if there is an error, while the old worker processes finish serving their clients. Still, run
nginx -tbeforehand. How to run applications in containers is described in the article Docker on a VPS: getting started. - Backward-compatible database migrations. While both versions are running, the database has to work for both. So schema changes are split into steps: first add the new columns and tables, deploy the code that uses them, and remove the old ones only in the next release.
Upgrading the operating system itself to a new major version cannot be done without downtime on a single server. It is more reliable to set up a second VPS with the new system, move the site to it, test it and switch DNS, having lowered the records' TTL in advance; how to do this is explained in the article Domains and DNS for a server owner. For the duration of the move, it is convenient to take the second server with hourly billing. How to choose a system version so that such moves happen less often is covered in the article Linux distributions for a server: Ubuntu, Debian, AlmaLinux.
Kernel updates without a reboot
Kernel live patching fixes critical vulnerabilities in the running kernel without rebooting the server. On Ubuntu, this is Livepatch, part of the Ubuntu Pro subscription, which is free for personal use on up to five machines. RHEL-compatible systems have their own mechanisms, including commercial services.
The technology has its limits. Only functions that the kernel can trace can be patched, a restriction described in the Linux kernel documentation, so some fixes only arrive with a new kernel. Canonical states plainly that Livepatch does not replace scheduled reboots; it only lets you postpone them to a maintenance window. And most importantly for a VPS: only KVM virtualization gives you your own kernel. On OpenVZ and LXC the kernel is shared and the host updates it; more on this in the article KVM or OpenVZ: which to choose.
Maintenance window and rollback
A maintenance window is a time chosen in advance when traffic is lowest, usually night-time in your main audience's time zone, when reboots and planned changes are allowed. The time is taken from the site's analytics, not picked at random. If customers or employees use the site, they are warned in advance. The window is not only for you: the host also carries out maintenance, and how hosts announce it is covered in the article SLA and uptime: what hosts promise.
The rollback plan is drawn up before the work starts, not after something has broken:
- define the failure signs in advance (errors in the logs, rising response times, a failed check of key pages) and a deadline after which you roll back instead of trying to fix things further;
- for code, switch the symlink or nginx back to the previous release;
- for packages, AlmaLinux has
dnf history undo, which reverts the last transaction; Ubuntu and Debian have no built-in package rollback, so there you rely on the snapshot; - a snapshot restores the entire disk, and everything written after it (orders, messages, sign-ups) will be lost. That is why the site is put into maintenance or read-only mode for the duration of a risky upgrade.
After the update, check the key pages and error logs and compare response times with the usual figures. If you ran load testing before launch, the same scenario will quickly show after a major update whether the site has become slower.