What it takes to run a wholesale dedicated server in production

Day one: access and hardening

1. Replace password login with SSH keys, disable root login over SSH, move to key-only authentication for every user.
2. Install a host firewall and default to deny inbound; open only the ports the application needs.
3. Enable automatic security updates for the operating system packages, with a reboot policy you understand.
4. Install brute-force protection for SSH and any exposed service.
5. Set up a non-root deploy user with sudo, and log every privileged command.
6. Configure time synchronisation, hostname, and reverse DNS for mail deliverability if the server sends email.
7. Set up a private network or WireGuard tunnel for administrative access, and consider closing SSH to the public internet entirely.

Done carefully this is a day for one server. Done repeatably, with the configuration in version control so the next server is identical, it is two to three days the first time.

Day two: observability

Without metrics and logs you learn about problems from customers. A minimum viable setup is a metrics agent, a log shipper and external uptime checks, feeding a dashboard with alerts that reach a human.

• Host metrics: CPU, memory, disk space and I/O wait, network throughput and errors, temperature.
• Service metrics: the database, web server, queue and cache each expose their own.
• Logs: system and application logs shipped off the host, searchable, retained long enough to investigate last quarter's incident.
• Uptime: checks from outside the data centre, because the server cannot report that it is unreachable.
• Alert routing: who is paged for what, with escalation when nobody acknowledges.

Day three: backups

A backup is only a backup once it has been restored. The design questions are what to back up, where to send it, how long to keep it, and how to know it works.

1. Choose a tool that deduplicates and encrypts: Restic, Borg or a commercial equivalent.
2. Send backups to a different site, ideally a different provider or at least a different data centre.
3. Snapshot databases consistently with their own tools, not by copying files underneath them.
4. Keep at least 30 days, longer for compliance.
5. Restore to a scratch machine every quarter, time it, and write down what went wrong.

Ongoing: patching

Security updates arrive weekly. Kernel updates need reboots. Firmware updates need downtime and a tested rollback. Someone has to read the advisories, decide what is urgent, schedule a window, run it and confirm the system came back healthy.

Ongoing: incident response

The server will have an incident. The disk will fill, a certificate will expire, a deploy will leak memory. The questions are who notices, how fast, and whether they know the system well enough to fix it at three in the morning.

An on-call rotation needs at least three people to be humane, a runbook per alert, and a post-incident review that produces follow-ups. Most small teams have none of these and discover it during the incident.

Ongoing: hardware

Disks fail. Memory develops errors. Watch SMART data and ECC counters so you replace components before they fail, and know your provider's replacement time and how to request it. On a single server with mirrored drives, one failed disk is routine; two in quick succession is a restore.

The honest total

Setup is roughly a week of a competent engineer's time for the first server and a day for each subsequent one if the work was automated. Ongoing is two to four hours per server per month plus the on-call burden, which is less a number of hours than a tax on everyone's attention.