The first hour on a new VPS, before anything goes live

A new VPS is public the moment it boots. Automated scanners find new addresses in minutes, and the first login attempts usually arrive before you have finished reading the welcome email. Nothing about this is personal. It is a continuous, indiscriminate sweep of the entire address space.

None of what follows is advanced. It is the short list that reliably separates a server you control from one you are sharing without knowing it.

Stop password logins over SSH

Password authentication over SSH is the single most attacked thing on a typical server. Key authentication removes the entire category.

Create a non-root user, copy your key to it, confirm you can log in as that user in a second terminal, and only then turn passwords off. Confirming first matters: turning off password login while your key is not actually working locks you out of your own machine, and recovering means a console session through the provider's dashboard.

Once the key works, disable both password authentication and direct root login, then restart the SSH service. Changing the SSH port is optional and buys very little: it removes noise from your logs, not risk from your server.

Close every port you are not using

The default state of most distributions is that anything a package installs and starts is reachable. A firewall that allows only SSH, HTTP and HTTPS is two commands, and it turns every future accidental exposure into a non-event.

This is the control that saves you later. When you install a database for local use, or a monitoring agent, or a management interface that binds to all interfaces by default, the firewall is the reason it does not become an internet-facing service.

Bind services to localhost as well where you can. A database listening on 127.0.0.1 and a firewall blocking its port are two independent controls, and you want both.

Turn on unattended security updates

Most compromised servers are not broken into through anything clever. They are running a version of something with a published fix that nobody applied. Automatic security updates are one package and one configuration file, and they close the gap between a fix existing and a fix being installed.

Set them to apply security patches automatically and to notify you about the rest. Reboots for kernel updates still need a decision from you, so schedule that rather than leaving it indefinitely.

Give the application its own user

Do not run the application as root. If a vulnerability in your application lets someone execute a command, the only question that matters is what that command can reach.

An application running as a dedicated user with write access to its own directory and nothing else is a contained problem. The same vulnerability in a process running as root is a lost server. This costs you one adduser and some file ownership at setup, and it is the difference between an incident and a disaster.

Make a backup, then restore it

Backups are the control people are most confident about and least entitled to be. A backup job that has been reporting success for a year is not a backup until a restore has been performed from it.

Restore into a scratch directory or a throwaway server. Time it. Write down the steps, because the person doing this next will be doing it at the worst possible moment and probably will not be you. Then check what is actually in the archive: application files without the database, or a database without the uploaded files, is a very common and very unpleasant discovery.

Know when something breaks before a customer does

Uptime monitoring on the public URL, disk space alerting, and a notification if the application process stops. That is the minimum, it is free at small scale, and it changes the failure mode from a customer emailing you to you already being on it.

Disk space deserves specific attention. Log files and container images fill disks quietly, and a full disk takes down a database in a way that is much more annoying to recover from than to prevent.

What this looks like finished

A server where SSH takes keys only, three ports are open, security updates apply themselves, the application runs unprivileged, a restore has actually been performed, and something tells you when it stops. None of it is difficult. It is a couple of hours once, and it removes the majority of the ways a small production server ends up in trouble.

If you would rather not spend the hours, Linux and VPS hardening is a fixed-scope piece of work with a written summary of exactly what was changed and why.