Server Management: The Practical Checklist for Running Your Own Server

Server management is the recurring work of keeping a server patched, reachable only by the right people, backed up, monitored and sized correctly: eight jobs that never finish, and that most people only notice when one of them fails.

Provisioning a server takes ten minutes. Managing it takes the rest of its life. This guide lists the jobs that make up server management, gives you the commands and cadence for each, and ends with an honest look at which of them are worth doing yourself.

Table of contents

• Patching: the job that never ends
• Users, SSH and the firewall
• Backups, and the restore test that proves them
• Monitoring, alerts and logs
• TLS renewals and capacity planning
• The checklist, and what to hand off
• How this fits the rest of the stack
• FAQ

Patching: the job that never ends

Unpatched software is the most common way servers get compromised, and it is boring. A kernel or OpenSSL fix ships, a public exploit follows within days, and the machines that were not updated get scanned and hit. Patching is a schedule, not an event.

On Debian and Ubuntu, unattended-upgrades applies security updates automatically. That covers the operating system and packages from the distribution repositories. It does not cover the application layer: your language runtime installed by hand, your container base images, your WordPress plugins, your npm dependencies. Those need their own routine.

sudo apt update && sudo apt list --upgradable
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
# kernel updates need a reboot; check whether one is pending
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs

Decide when reboots happen and who approves them. The trap is a server that has been up for 400 days and has three pending kernel updates: everyone is afraid to reboot it, so nobody does, and the risk quietly grows. Reboot on a schedule, in a window you have announced, and you never get there.

Users, SSH and the firewall

Access control is the second job. Every account on a server is a way in, so the goal is few accounts, no shared passwords and no root login. Use SSH keys, disable password authentication, and remove accounts when people leave. The first-hour steps are laid out in the VPS configuration checklist, and they still apply months later when you are adding a second engineer.

# /etc/ssh/sshd_config.d/hardening.conf
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy

Then close everything you are not using. A default-deny firewall that allows SSH, HTTP and HTTPS only turns a huge class of problems into non-events, because a database bound to a public port is a common cause of data leaks. Check what is actually listening rather than what you think is listening.

sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ss -tulpn      # what is listening, and on which interface

Finally, review access every quarter. List the users, list the authorized keys, and delete what nobody can explain. Stale keys are how a former contractor ends up with a working login two years later.

Backups, and the restore test that proves them

Backups are not real until you have restored from one. Plenty of teams have a nightly job that has been failing silently for months, or a backup that stores the database dump on the same disk as the database. Both are the same as having no backup.

The rule is three copies, two kinds of storage, one somewhere else. For a typical web server that means a database dump or snapshot, the uploaded files directory and the configuration, copied off the machine to object storage or another region, with retention that covers the time it takes you to notice a problem. Ransomware and slow corruption are not noticed on day one.

# nightly database dump, compressed, shipped off-box
mysqldump --single-transaction --routines appdb | gzip > /backups/appdb-$(date +%F).sql.gz
rclone copy /backups remote:server-backups --max-age 24h

Then test it. Once a quarter, restore the latest backup onto a scratch server and load the site. Time how long it takes, because that number is your real recovery time, and it is usually far worse than the number in the document. The WordPress version of this exercise is in our post on how to back up a WordPress site, and the same discipline applies to any stack.

Monitoring, alerts and logs

You cannot manage what you cannot see. Monitoring answers four questions: is it up, is it slow, is it running out of something, and is it being attacked. The first needs an external check, since a server cannot report that it is unreachable. The other three come from metrics on the box: CPU, memory, disk space and inodes, load and network.

• Uptime: an external HTTP check every minute from outside your network
• Disk: alert at 80 percent, because 100 percent breaks databases and log writers
• Memory: watch swap use and OOM killer messages, not just free memory
• Certificates: alert 21 days before expiry, not after
• Backups: alert when the job does not run, not only when it fails

Alert fatigue kills monitoring faster than any outage. If a channel gets a message every hour, people mute it, and then the real page is missed. Keep alerts to things that need a human within the hour and route the rest to a daily summary. For a deeper look at what to collect, see cloud server monitoring.

Logs are the other half. Keep them somewhere they cannot be wiped by the incident that caused them, rotate them so they do not fill the disk, and know where the important ones are: journalctl for services, /var/log/auth.log for logins, and your web server’s access and error logs. When something breaks at 3am, the first ten minutes are almost always log reading.

TLS renewals and capacity planning

Certificates expire on a date, and the failure is total: browsers show a full-page warning and API clients refuse to connect. Automate renewal with certbot or your web server’s built-in ACME client, and then verify the automation with a dry run, because renewal jobs break after a config change and nobody notices for ninety days.

sudo certbot renew --dry-run
sudo systemctl list-timers | grep certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Capacity planning is the slow-motion version of the same problem. Look at the trend, not the snapshot: disk growing 2 GB a week on a 40 GB volume gives you weeks, not years. Memory that sits at 85 percent on a quiet Tuesday will not survive a marketing email. Set a monthly reminder to review CPU, memory, disk and bandwidth against the plan you pay for.

The expensive mistakes here run in both directions. Undersize a server and the site falls over during your best day. Oversize it just in case and you pay for idle capacity every month. Autoscaling between a floor and a ceiling plan is the sane middle, and it is one of the things a platform can do for you rather than something you script yourself.

The checklist, and what to hand off

Here is the whole job as a recurring list. Daily is what is automated and alerts you, weekly is a quick look, and quarterly is the deliberate review.

1. Daily (automated): security updates, backups, uptime and disk alerts, log rotation.
2. Weekly: check pending reboots, review failed logins and error logs, glance at capacity trends.
3. Monthly: update application dependencies, review firewall rules, test certificate renewal.
4. Quarterly: restore a backup to a scratch server, audit users and SSH keys, review plan size.
5. Yearly: OS upgrade planning before end of support, disaster recovery walkthrough.

Add it up and it is a few hours a month if nothing breaks, and a lot more when something does. That is fine if the server is the product, or if you enjoy the work. It is a poor trade if the server is just where your app happens to run. This is the reasoning behind managed VPS offerings, and behind platforms that take the whole layer away.

A sensible split: keep the parts that are specific to your application, and hand off the parts that are the same on every server. Patching, TLS, backups of the database, log collection and scaling are identical everywhere, which is exactly why they are worth not doing by hand.

How this fits the rest of the stack

If you have read this far and decided that most of it is not your business, price the alternative before you commit to another server. The RunxBuild hosting calculator lays out what a web service, a managed database and WordPress cost together. On RunxBuild you push a repository, get build logs, runtime logs, metrics and rollback to a previous deploy, and the operating system is not yours to patch. Managed MySQL and Postgres instances come with backups, and the database docs explain the limits. You can start from the dashboard.

Useful related references:

• VPS configuration: the first-hour checklist
• Cloud server monitoring
• Managed VPS: what you hand over
• Services on RunxBuild

FAQ

What does server management include?

Server management covers patching the operating system and applications, controlling user and SSH access, configuring the firewall, running and testing backups, monitoring performance and uptime, collecting logs, renewing TLS certificates and planning capacity. It is ongoing operational work, not a one-time setup.

How often should a server be patched?

Apply security updates automatically and continuously, and schedule reboots for kernel updates in a regular window, such as weekly or monthly. Application dependencies and CMS plugins need their own routine, at least monthly, because unattended upgrades only cover distribution packages.

How do I know my backups actually work?

Restore one. Once a quarter, load the latest backup onto a scratch server, start the application and check the data. This also gives you a real recovery time, which is usually longer than assumed. A backup you have never restored is only a hope.

What is the difference between managed and unmanaged servers?

On an unmanaged server you run everything: updates, security, backups and monitoring. On a managed one, the provider handles some or all of that, usually the operating system layer. What is included varies widely, so read the scope before assuming backups or security are covered.

When should I stop managing servers myself?

When the server is not your product and the hours spent on patching, backups and alerts outweigh the cost of handing them off. If a missed update or failed backup would hurt the business and nobody owns the checklist, move to a managed platform.