Spinning up a Linux server takes two minutes on any cloud provider. Making it production-ready takes a bit more discipline — but skip it, and you're one automated bot scan away from a bad week. Here's the checklist we run through before anything goes live.
1. Never run as root
The first login on a fresh server is almost always root. The first thing to do is create a dedicated user with sudo privileges, and disable direct root login entirely. If that account is ever compromised, an attacker still needs a second password to gain full control.
2. Lock down SSH
- Switch from password authentication to SSH key pairs — keys aren't brute-forceable the way passwords are.
- Move SSH off port 22 if you want to cut down on automated scanning noise (this is convenience, not real security on its own).
- Disable root login over SSH specifically, even if you've already disabled it elsewhere.
3. Set up a firewall
A server should expose only what it needs to: typically 80/443 for web traffic and your (possibly custom) SSH port — nothing else. Tools like ufw on Ubuntu make this a five-minute job, and it's the single change that removes the largest number of potential attack surfaces at once.
4. Automate security updates
Unpatched software is still the most common way servers get compromised — not exotic zero-days. Enable unattended security updates for OS-level patches, and keep a regular (ideally automated) process for updating application dependencies too.
5. Set up monitoring before you need it
You want to know about high CPU, low disk space, or a crashed process before a customer tells you. Basic monitoring — even just uptime checks and resource alerts — should exist from day one, not get added after the first outage.
The best time to set up monitoring is before launch. The second-best time is right after the incident that made you wish you had.
6. Plan backups, and actually test restoring them
A backup you've never restored from is a hope, not a backup. Automate regular backups of anything stateful (databases, uploaded files), store them somewhere separate from the server itself, and periodically prove to yourself that a restore actually works.
Putting it together
None of this is exotic — it's a checklist, not a research project. The teams that get burned are almost always the ones that skipped a step to save an afternoon. Treat this list as the minimum bar before anything touches real user data.