A new VPS arrives as a bare operating system with root access and nothing else. What you do in the first few hours decides how much trouble the next year holds.
This is the order that matters.
Before anything: decide what this server is for
One application or several? Will it hold data that must be backed up, or is it disposable? Does anything need to reach it besides you?
Those answers change the firewall, the backup plan and the sizing. Deciding them afterwards means redoing work.
1. Stop logging in as root
Create a normal user with sudo, add your SSH public key to it, confirm you can log in and escalate — in a second terminal, before closing the first. Locking yourself out of a fresh server is a rite of passage worth skipping.
Then disable password authentication and root login in the SSH configuration. This removes the overwhelming majority of automated attack traffic before it starts.
2. Update everything, then decide about automation
Apply all available updates immediately — the image is rarely current.
Then decide how future updates happen. Automatic security updates are the right default for most single-purpose servers: the risk of an unattended update causing trouble is smaller than the risk of an unpatched vulnerability sitting for months. For anything where an unexpected restart is unacceptable, schedule a manual window instead — but schedule it, rather than leaving it to whenever someone remembers.
3. Firewall: default deny
Allow only what is needed — typically SSH, HTTP and HTTPS — and deny everything else inbound.
Specifically do not expose database ports. If the application is on the same server, bind the database to localhost. If it is not, allow one address rather than a range.
4. Add fail2ban
Even with keys only, the authentication log will fill with attempts. fail2ban bans repeat offenders and keeps the logs readable, which matters because a log full of noise is a log nobody reads.
5. Swap, sized modestly
A small swap file converts an out-of-memory kill into degraded performance you can notice. It is not a substitute for adequate memory, and it is a useful safety margin.
6. Log rotation, before logs exist
Configure rotation for application logs at the same time you configure the application. A full disk stops the database writing and produces confusing errors that mention nothing about disk space.
7. Monitoring, while things are calm
At minimum: CPU, memory, disk usage, and an external check that the site responds. Alerts to somewhere you will actually see them.
Set the disk alert at 80%, not 95%. The gap is your time to react.
This is the step most often postponed and most often regretted, because its entire value is in already existing when something goes wrong.
8. Backups, off this machine
Automated, to somewhere else, with a retention period you have chosen deliberately. Databases need a proper dump rather than a file copy of a running database.
Then restore one, to somewhere isolated, and time it. An untested backup is a belief, not a backup.
9. Write down what you did
What is installed, what the firewall allows, where backups go, how to restore, what monitoring exists and where alerts arrive. One page is enough.
This is for the person who has to fix this at 2am, which may be you in a year, having forgotten all of it.
10. Only now, deploy
With the foundation in place, deploying the application is the easy part — and the parts that make a server survivable are already there rather than pencilled in for later.
Sizing, once you have data
Run for a fortnight, then look at actual CPU, memory and disk I/O under real traffic. Most servers are over-provisioned on memory and under-provisioned on I/O, because memory is what the pricing page shows.
Adjust based on the measurement rather than the guess you made at signup.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
