An unpatched server is a sitting target. Automated scanners sweep the internet constantly, probing for known vulnerabilities that should have been fixed months ago. The gap between a disclosed bug and a compromised server can be measured in hours, not days.
This guide walks you through what patching means, why it matters, and how to build a working update routine from scratch—even if you have never touched a Linux command line before.
What patching actually means
A patch is a software update that fixes security flaws, bugs, or adds minor features. When a vulnerability gets discovered in Apache, OpenSSH, the Linux kernel, or any package your server runs, the vendor releases a patch.
Your job is to apply it before attackers do their job.
Think of your server as a building. Every software package is a door or window. A vulnerability is a broken lock. The patch fixes the lock. Skipping patches leaves broken locks everywhere.
Why unpatched servers get owned fast
Public vulnerability databases publish detailed reports the same day vendors release patches. Attackers reverse-engineer those patches to build exploits within hours.
I have seen compromised servers where the attack came thirty minutes after a critical remote code execution bug went public. The server admin planned to patch "next week." By then the box was mining cryptocurrency and port-scanning other networks.
Automated bots do most of the work. They do not target you personally—they scan entire IP ranges looking for version numbers and open ports that match known exploits.
What you are patching
Your server runs dozens or hundreds of software packages:
- Operating system kernel: the core that manages memory, processes, and hardware.
- System libraries: shared code used by multiple programs (glibc, OpenSSL).
- Services and daemons: web servers (Apache, Nginx), databases (MySQL, PostgreSQL), SSH, mail servers.
- Installed applications: WordPress, control panels like cPanel, custom code.
Each one can have vulnerabilities. Each one needs regular updates.
The two patching strategies
You can patch manually or automatically. Both have trade-offs.
Manual patching
You SSH into the server, check for updates, review the list, then apply them. Full control. You see exactly what changes. You can test on a staging server first.
Downside: you have to remember to do it. Miss a week and you are exposed.
Automatic patching
The server installs security updates on a schedule without your intervention. Fast response to critical bugs. No human delay.
Downside: an update might break something at three in the morning. Rare, but it happens.
Most hosting environments use automatic security patches with manual approval for major version upgrades. That is the balance I recommend.
Your first manual patch run on Ubuntu or Debian
Let's walk through a complete update cycle on an Ubuntu or Debian server. You need SSH access and sudo or root privileges.
Connect to your server:
ssh username@your-server-ip
Update the package index. This refreshes the list of available updates from the repositories:
sudo apt update
You will see lines scroll by as it contacts each repository. No packages are changed yet.
Now see what updates are available:
apt list --upgradable
This prints every package with a newer version waiting. Could be three, could be fifty.
Apply all available updates:
sudo apt upgrade -y
The -y flag answers "yes" to prompts automatically. Packages download and install. Some services might restart.
For kernel updates and certain system packages, you need the full upgrade command:
sudo apt full-upgrade -y
This handles dependency changes and removes obsolete packages.
Reboot if the kernel was updated:
sudo reboot
A file named /var/run/reboot-required appears after kernel or certain library updates. Check for it:
ls /var/run/reboot-required
If it exists, reboot soon. The old kernel is still running until you do.
Patching on CentOS, AlmaLinux, or Rocky Linux
Red Hat-based distributions use yum or the newer dnf package manager. The workflow is similar.
Update the package metadata:
sudo yum check-update
or
sudo dnf check-update
Apply all updates:
sudo yum update -y
or
sudo dnf upgrade -y
Reboot if kernel or core system libraries updated:
sudo reboot
Check if reboot is needed:
sudo needs-restarting -r
That command tells you explicitly whether a reboot is required.
Setting up automatic security updates on Ubuntu
Install the unattended-upgrades package:
sudo apt install unattended-upgrades -y
Enable it:
sudo dpkg-reconfigure --priority=low unattended-upgrades
Select "Yes" when prompted.
By default it installs security updates automatically. Configuration lives in /etc/apt/apt.conf.d/50unattended-upgrades. Open it:
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
Key settings:
Unattended-Upgrade::Allowed-Originscontrols which repositories are auto-updated. Security repos are enabled by default.Unattended-Upgrade::Automatic-Rebootset totrueallows automatic reboots if needed. Set a time withUnattended-Upgrade::Automatic-Reboot-Time "02:00";to avoid daytime disruption.Unattended-Upgrade::Mailsends email reports. Add your address.
Save and exit. The service runs daily via a systemd timer.
Verify it is active:
systemctl status unattended-upgrades
Automatic updates on CentOS and AlmaLinux
Install dnf-automatic:
sudo dnf install dnf-automatic -y
Edit the config:
sudo nano /etc/dnf/automatic.conf
Change apply_updates from no to yes under the [commands] section to enable automatic installation.
Set emit_via to email and configure email_to if you want notifications.
Enable and start the timer:
sudo systemctl enable --now dnf-automatic.timer
Check status:
systemctl status dnf-automatic.timer
What about control panels like cPanel or Plesk?
Control panels have their own update mechanisms. cPanel updates itself automatically by default through /usr/local/cpanel/scripts/upcp. You can configure update preferences in WHM under "Update Preferences."
Plesk updates via its web interface under Tools & Settings > Updates. You can enable automatic installation of security patches.
Important: updating cPanel or Plesk does NOT update your operating system packages. You still need to patch the underlying OS separately using the methods above.
Patching web applications: WordPress, Joomla, Drupal
Your hosting software is only half the picture. Web applications run on top and have their own vulnerabilities.
WordPress, plugins, and themes release security updates constantly. Enable automatic updates for minor WordPress core releases in wp-config.php:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
For plugins and themes, install a management plugin or use WP-CLI:
wp plugin update --all
wp theme update --all
Outdated plugins are the number one entry point I see in compromised WordPress sites.
How often should you patch?
Security updates: immediately, or automatically within twenty-four hours. No exceptions.
Regular package updates: weekly for production servers. Daily if you are comfortable with automatic updates and have good monitoring.
Major version upgrades (Ubuntu 22.04 to 24.04, PHP 7.4 to 8.2): plan these carefully, test in staging, then schedule during low-traffic windows.
Before you patch: take a snapshot
If your host offers VM snapshots, take one before major updates. DigitalOcean calls them snapshots, AWS calls them EBS snapshots, Linode calls them backups.
A snapshot lets you roll back if an update breaks your application. It costs a few dollars and saves hours of panic.
For smaller updates and automatic patching, snapshots are overkill. But before a PHP major version jump or a dist-upgrade, always snapshot.
Testing patches in staging first
If you run a business-critical site, mirror your production server in a staging environment. Apply updates there first. Run automated tests or click through core user workflows.
If staging works fine for twenty-four hours, push the same updates to production.
Many small sites skip staging due to cost and complexity. That is fine if you have snapshots and can tolerate brief downtime.
Monitoring what got patched
Keep logs of what updated and when. On Debian/Ubuntu, check:
less /var/log/apt/history.log
On Red Hat systems:
sudo dnf history
If something breaks after an update, these logs show exactly what changed.
Some admins log into a shared Slack channel or send daily cron emails summarizing updates. Simple but effective.
What if a patch breaks something?
It happens. A PHP update changes behavior and your checkout form stops working. An Apache config syntax changed and the service will not start.
First step: read the error logs. On Ubuntu/Debian:
sudo journalctl -xe
For Apache:
sudo tail -f /var/log/apache2/error.log
For Nginx:
sudo tail -f /var/log/nginx/error.log
Roll back the specific package if needed. On Debian/Ubuntu you can downgrade, though it is tricky and not officially supported. Better to restore from snapshot.
On RHEL/CentOS:
sudo dnf history undo last
This rolls back the most recent transaction.
Patching is not enough: reduce your attack surface
Updates fix known bugs. They do not fix poor configuration.
Disable unused services. If you do not run FTP, remove the FTP server. Fewer packages means fewer vulnerabilities.
Use a firewall to block unused ports. ufw on Ubuntu is simple:
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
Now only SSH, HTTP, and HTTPS are open.
Run services as non-root users. Never run a web server or database as root. Default installs usually get this right, but verify.
Track security advisories
Subscribe to security mailing lists for your OS and major software:
- Ubuntu security notices: subscribe at the Ubuntu security notices page.
- Debian security announcements: check the Debian security tracker.
- Red Hat/CentOS: follow their security advisories portal.
Most critical bugs get announced with a CVE number and severity rating. High and critical ratings mean patch now, not next week.
Automate patch reporting
Set up a daily cron job that emails you the list of available updates without installing them:
On Ubuntu, create /etc/cron.daily/updates-available:
#!/bin/bash
apt update > /dev/null
apt list --upgradable 2>/dev/null | mail -s "Updates available on $(hostname)" [email protected]
Make it executable:
sudo chmod +x /etc/cron.daily/updates-available
Install mailutils if mail is not available:
sudo apt install mailutils -y
Now you get a daily summary without logging in.
What to do right now
Log into your server and run a manual update cycle today. If updates are available, apply them. If the kernel updated, reboot.
Then enable automatic security updates using the steps above. Set up email notifications so you know what is happening.
Finally, add a weekly reminder to check for pending updates manually. Five minutes a week keeps most attacks at bay.
Patching is boring. Getting hacked is worse.