How to keep a Linux web server updated and patched?

To keep a Linux web server updated and patched, you install security updates from your distribution's package manager on a regular schedule, enable automatic security updates (such as unattended-upgrades on Ubuntu and Debian or dnf-automatic on RHEL-based systems), reboot or livepatch when the kernel and core libraries change, and keep software installed outside the package manager, like your CMS, Composer and npm packages, and container images, up to date too. You also run a supported OS release, take backups before big changes, and monitor so you know when an update breaks something.

Unpatched software is one of the most common ways servers get compromised. Once a vulnerability is published, automated scanners start looking for it within hours or days. This guide gives you a realistic patching routine for a single VPS or a small fleet: how to update manually, how to automate security fixes safely, how to handle reboots, and how to cover the parts of your stack the OS package manager doesn't know about.

Why Patching Matters So Much

Every piece of software on your server, from the kernel and OpenSSL to Nginx, PHP, and MySQL, occasionally has security flaws discovered in it. When the fix is released, the details usually become public too, which gives attackers a roadmap. Servers that aren't updated become easy, automated targets.

Regular patching helps you:

• Close known vulnerabilities before they're exploited at scale.
• Stay supported: Security fixes only arrive for supported releases.
• Avoid emergency upgrades: Small, frequent updates are much less risky than jumping years of versions at once.
• Meet compliance requirements: Standards like PCI DSS expect timely patching.

Patching isn't glamorous, but it's one of the highest-value security habits you can build.

Step 1: Run a Supported Distribution Release

Updates only protect you if your OS release still receives them. Check what you're running:

cat /etc/os-release
uname -r

Then compare it against the vendor's support timeline:

• Ubuntu LTS releases get five years of standard security maintenance, with longer coverage available through Ubuntu Pro.
• Debian stable releases get security support for roughly three years, followed by a Long Term Support period run by a volunteer team.
• RHEL, Rocky Linux, and AlmaLinux major versions are supported for around ten years.

Interim (non-LTS) Ubuntu releases are only supported for about nine months, so they're a poor choice for production servers. If your release is close to end of life, plan an upgrade or a migration to a fresh server rather than waiting until it stops receiving fixes.

On Ubuntu, the pro tool shows your support status:

pro security-status

Step 2: Update Manually and Understand What Changes

Before automating anything, get comfortable with a manual update. On Ubuntu and Debian:

sudo apt update
apt list --upgradable
sudo apt upgrade

Here's what each command does:

1. apt update: Refreshes the list of available packages from your repositories. It doesn't install anything.
2. apt list --upgradable: Shows which packages have newer versions, so you can see what's about to change.
3. apt upgrade: Installs the updates. It won't remove packages or install new dependencies that would require removing something.

Occasionally, updates need new dependencies or package removals. sudo apt full-upgrade handles those, but read its summary carefully before confirming.

On RHEL, Rocky Linux, AlmaLinux, and Fedora:

sudo dnf check-update
sudo dnf upgrade

To install only security updates on RHEL-family systems:

sudo dnf upgrade --security

After updating, clean up packages that are no longer needed, such as old kernels:

sudo apt autoremove --purge

On RHEL-based systems, sudo dnf autoremove does the same job.

Step 3: Enable Automatic Security Updates

Manual updates are fine for a start, but people get busy. Automatic security updates close the gap between a fix being released and it being installed on your server.

Ubuntu and Debian: unattended-upgrades

Install and enable the package:

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Choose Yes when asked to download and install stable updates automatically. That creates /etc/apt/apt.conf.d/20auto-upgrades:

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

The main settings live in /etc/apt/apt.conf.d/50unattended-upgrades. By default on Ubuntu, only the security pocket is enabled, which is a sensible choice for servers. Useful options to review:

// Email a report (requires a working mail setup on the server)
Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";

// Remove unused dependencies and old kernels
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// Reboot automatically if needed, at a quiet time
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Test the configuration with a dry run:

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

Logs go to /var/log/unattended-upgrades/, which is the first place to look if you're wondering what changed overnight.

RHEL, Rocky Linux, and AlmaLinux: dnf-automatic

sudo dnf install dnf-automatic

Edit /etc/dnf/automatic.conf and set:

[commands]
upgrade_type = security
apply_updates = yes

Then enable the timer:

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

Package and config names can differ slightly between versions (newer DNF releases have reworked the automatic tool), so check man dnf-automatic on your system.

Should You Auto-Install All Updates?

Security updates from your distribution's stable repositories are designed to be low-risk backported fixes, so applying them automatically is a reasonable default for most web servers. Feature updates, third-party repositories, and major version changes are different: they're more likely to change behaviour, so it's usually better to apply those manually after testing.

Step 4: Handle Kernel Updates and Reboots

Many updates take effect as soon as the affected service restarts. Kernel updates, and updates to core libraries like glibc, only take full effect after a reboot. A server that installs kernel patches but never reboots is still running the old, vulnerable kernel.

On Ubuntu and Debian, check whether a reboot is pending:

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required
cat /var/run/reboot-required.pkgs 2>/dev/null

On RHEL-based systems:

sudo dnf needs-restarting -r

Restart Services That Use Updated Libraries

When a library like OpenSSL is updated, running services keep using the old copy in memory until they restart. The needrestart tool (installed by default on recent Ubuntu versions) detects this after updates and can restart affected services automatically:

sudo apt install needrestart
sudo needrestart

On RHEL-family systems, sudo dnf needs-restarting -s lists services that should be restarted.

Plan Reboots

For a single server, pick a regular low-traffic window, perhaps once a week or whenever a kernel update lands, and reboot then. You can let unattended-upgrades do it with Automatic-Reboot "true", but only if you're comfortable with a short outage at that time and have monitoring to tell you if the server doesn't come back.

For sites that can't tolerate downtime, run at least two web servers behind a load balancer and reboot them one at a time.

Consider Livepatching

Kernel livepatching applies critical kernel fixes to the running kernel without a reboot. Options include:

• Canonical Livepatch for Ubuntu, available through Ubuntu Pro (free for a small number of machines for personal use).
• kpatch on RHEL and its rebuilds.
• KernelCare from TuxCare, a commercial service supporting several distributions.

Livepatching reduces urgency, but it doesn't eliminate reboots. You'll still want to reboot periodically to move onto fully updated kernels.

Enabling Canonical Livepatch on Ubuntu looks like this:

sudo pro attach
sudo pro enable livepatch
canonical-livepatch status

Step 5: Patch Software the Package Manager Doesn't Manage

Your OS package manager only updates packages it installed. A typical web server also runs software from other sources, and each needs its own update routine.

Third-Party Repositories

If you've added repositories for newer PHP versions (such as Ondřej Surý's PPA or the Sury Debian repository), Nginx mainline, MariaDB, Docker, or Node.js, updates from them arrive through apt or dnf too. However, unattended-upgrades on Ubuntu only applies updates from the official security pocket by default, so these may need manual updates, or you can add their origins to Unattended-Upgrade::Allowed-Origins carefully.

Your CMS and Plugins

WordPress, Drupal, Laravel apps, and other software in /var/www aren't managed by the OS. For WordPress, enable automatic minor core updates (on by default), keep plugins and themes updated, and consider WP-CLI in a cron job or your deployment process:

sudo -u www-data wp core update --path=/var/www/example.com/public
sudo -u www-data wp plugin update --all --path=/var/www/example.com/public

Run WP-CLI as the site's user so file ownership stays correct.

Language Dependencies

Applications built with Composer, npm, pip, or other package managers have their own dependencies. Check them for known vulnerabilities as part of your development workflow:

composer audit
npm audit

Then update, test, and deploy. Don't run npm audit fix --force directly on production, since it can install breaking major versions.

Containers

If you run Docker, the host OS updates don't patch software inside your containers. Rebuild images regularly from updated base images, and pull new versions of official images:

docker compose pull
docker compose up -d
docker image prune -f

Pin image tags to a specific major version rather than latest so updates are predictable.

Snaps and Other Formats

Snap packages update themselves automatically in the background. Flatpaks are rare on servers, but if you use them, flatpak update handles them. Software installed manually from tarballs or source has no automatic updates at all, so avoid that where you can, or track it carefully.

Step 6: Get Notified About Vulnerabilities

Automation handles most updates, but you should still know when something serious happens.

• Subscribe to security announcements for your distribution: Ubuntu Security Notices, Debian Security Advisories (the debian-security-announce mailing list), or Red Hat security advisories.
• Follow the software you depend on: Nginx, PHP, OpenSSL, and your CMS all publish security releases.
• Use vulnerability scanning: Tools like Lynis audit your server configuration, and your cloud provider or a service like Wazuh can flag vulnerable packages.
• Check pending updates on login: Ubuntu's login message shows how many updates are waiting, which is a useful nudge.

For WordPress sites specifically, security plugins such as Wordfence, Patchstack, or Solid Security can alert you when an installed plugin has a known vulnerability.

Step 7: Back Up and Test Before Big Changes

Routine security updates rarely break anything, but major upgrades can. Protect yourself:

1. Take a snapshot or backup: Most VPS providers let you snapshot a server in a minute or two. Do it before major upgrades or big batches of updates.
2. Test on staging: Keep a staging server that mirrors production, and update it first.
3. Update in small batches: Applying updates weekly is far less risky than applying a year's worth at once.
4. Have a rollback plan: Know how you'd restore the snapshot, or downgrade a specific package if needed.

You can hold a package at its current version if an update causes problems while you investigate:

sudo apt-mark hold nginx
sudo apt-mark unhold nginx

On RHEL-based systems, the versionlock plugin does the same job. Don't leave holds in place indefinitely, or you'll miss security fixes.

Step 8: Monitor After Updates

Automatic updates are only safe if you notice when they cause problems.

• Uptime monitoring: An external check that alerts you when your site goes down, especially after automatic reboots.
• Service health: systemctl --failed shows services that failed to start.
• Logs: Check web server and PHP error logs after updates for new warnings.
• Update logs: Review /var/log/apt/history.log, /var/log/unattended-upgrades/, or dnf history to see what changed.

systemctl --failed
tail -n 50 /var/log/apt/history.log

Major Version Upgrades

Moving from one OS release to the next, such as Ubuntu 22.04 to 24.04, is a bigger job than routine patching. You have two main options:

• In-place upgrade: On Ubuntu, sudo do-release-upgrade; on Debian, update your sources and run a full upgrade following the official release notes. Take a snapshot first and read the release notes for breaking changes.
• Rebuild and migrate: Build a fresh server on the new release, deploy your application, test it, then switch traffic over. This is often cleaner, especially if you use configuration management tools like Ansible.

Either way, run the upgrade over a session you can recover, such as your provider's web console, in case SSH drops midway.

A Sample Patching Routine

Here's a simple schedule that works well for many small teams:

1. Daily (automatic): Security updates installed by unattended-upgrades or dnf-automatic.
2. Weekly: Check for pending reboots and reboot in a quiet window. Review update logs and apply non-security updates after a quick look.
3. Weekly or on release: Update CMS core, plugins, and themes.
4. Monthly: Run composer audit or npm audit, rebuild container images, and review third-party repositories.
5. Quarterly: Review OS support dates, remove unused software, and test a restore from backup.
6. As needed: Apply critical fixes immediately when a serious vulnerability is announced.

---

FAQ: Keeping a Linux Server Updated

---

Conclusion

Keeping a Linux web server patched is less about one big effort and more about a steady routine: a supported OS release, automatic security updates, planned reboots or livepatching for kernel fixes, and a separate habit for the software your package manager doesn't cover, like your CMS, application dependencies, and containers.

Start by enabling unattended-upgrades or dnf-automatic today, then add a weekly check for reboots and a monthly review of everything else. Combined with backups and monitoring, this routine closes most of the gaps attackers rely on, without turning patching into a source of downtime or stress.