Setting up a VPS: the first hour

The two previous articles in this series explained what a VPS is and whether a server of your own pays off at all, and how to compare and choose a VPS, that is, whom to rent it from. This one starts the moment the provider sends you the access details. The server is already running, it has a public address, and within minutes it starts receiving login attempts from bots that sweep the internet looking for poorly secured machines.

I describe what I do in the first hour, before running anything else on the server, and why in this particular order. I do not give a list of commands to copy. Commands depend on the system and the provider, and each one is worth understanding before you run it, because a mistake in the login settings can lock you out of your own machine.

Three decisions made at the order stage

Where should the machine sit? Mine runs in a data center in Warsaw. The previous article explains why that matters: compliance with data protection law is easier to show, responses reach visitors faster, and support works in the same time zone.

Which system should it run? I chose Debian, version 12. On a server, predictability matters more than novelty, so I prefer a system that changes rarely and announces its changes well in advance. The choice also has a practical side: a popular system makes it easier to find documentation and answers to unusual questions.

How big a machine to start with? I started with 6 cores, 11 GB of RAM and a 99 GB disk. I enlarged it after less than four months, without moving anything and without reinstalling the system. When growing is that simple, there is no reason to buy a bigger machine than you need today.

The first hour: five steps in a fixed order

1. Your own administrator account instead of the default one

On a new machine the provider creates an account with a predictable name, and a predictable name hands an attacker half of the login details for free. So I create my own account with administrator rights, check that I can log in to it and run administrative commands from it, and only then lock the default account. The order is what matters most here, because the reverse order ends with a door slammed shut and the key on the wrong side.

2. Logging in with a key only

A password can be guessed; a cryptographic key, in practice, cannot. I switch off password logins and direct logins to the root account. Every computer I administer the server from has its own key, so a lost laptop means revoking one key rather than replacing all of them.

3. Firewall: everything closed, only what must be open is open

I start by blocking all incoming traffic and then open three ports: one for remote login and two for websites. Databases and supporting services work inside the server’s internal network and cannot be seen from the internet at all. During a review in September 2026 I checked this on the machine itself: only those three ports are listening to the outside world.

4. Blocking after failed attempts, and login alerts

A firewall cannot tell the owner apart from a bot trying one password after another on the login port. A second mechanism does that: after a few failed attempts, the address goes on a block list. On top of that, a script regularly reads the login log and sends me an alert when someone logs in from an unknown address or a new account appears on the system.

One number shows the scale well. In September 2026 the file recording failed login attempts took up 61 MB on my server, and every entry in that file is one failed attempt.

5. Updates and the clock

The system installs security patches by itself. The automation does not restart the machine, though, so a new system kernel waits on the disk until someone decides to restart. For me a restart is always a separate, planned decision, because this server runs more than a dozen services and client websites.

The last item of the first hour sounds trivial: the time zone and clock synchronization. Yet the clock decides whether the times in the logs, in the backups and in the alerts can be matched against each other when something goes wrong.

Before the first application goes up

After the first hour the server is secured, but it does not do anything yet. Before I run the first application on it, I set up four things that are hard to add later.

A backup from day one. A script makes a backup every day at three in the morning, encrypts it and stores it in two places: the server keeps it for seven days, and cloud storage at another provider keeps it for thirty. On top of that there is a paid backup of the whole machine on the server provider’s side, described in the previous article. The rule is simple: a backup that sits only on the same machine will go down with it.

Keeping the disk tidy. Every service has its own directory, and passwords live in a separate file that only the administrator can read. The configuration files contain no passwords at all, so the configuration can be kept in a repository, compared and restored without the risk of leaking database access along with it.

One way in from the internet. All applications run in containers behind a single proxy that receives the traffic, routes it to the right service and renews certificates on its own. I will describe this layer separately in the installment about Docker.

Uptime monitoring. A tool checks every minute whether the websites and applications respond, and it lets me know when one of them stops responding. The next installment of the series is about that tool.

Three mistakes I made on this server

The first configuration was incomplete. After the server had been running for some time, I carried out a full security review. There was no sign of a break-in, but the review found a few things I had missed during the first configuration, and I fixed all of them right away. This case shows well why a security review is worth scheduling permanently and repeating, rather than doing it once after the server goes live. On my server it comes back regularly, on a schedule.

The backup check was looking at the wrong thing. It verified that the backup file was intact, not that it was recent. When new backups stopped being made, the check kept reporting that everything was fine, and the gap was only caught by a review of the server. I lost nothing, because the cloud storage held earlier backups. The lesson is simple: a backup check has to look at the date of the last run, not only at whether the file opens.

An automatic update I never asked for. The tool that updates containers replaced, overnight, the version of the proxy that carries traffic to every website on the server. Nothing broke, and the change was caught by a review. Now the versions of the key components are pinned, and every replacement reaches me as an alert with the version number before and after the change.

All three mistakes share one cause: something looked as if it worked, so it raised no suspicion. That is why the first hour is only the beginning of the work on a server, not its end.

When to hand it over to someone else

After the first hour come reviews and updates, and alerts need an answer on weekends too. If nobody in the company will take care of that, it is worth running the numbers the same way as with the subscriptions in the first article of this series. I set up and run servers like this for companies, and the scope of that work is described on the page Your own server instead of subscriptions.

First-hour checklist

1. Your own administrator account, tested before the default account is locked.
2. Key-only logins, a separate key for every computer, no logins to the root account.
3. A firewall that closes everything except the ports you really need.
4. Blocking addresses after failed attempts, and an alert on logins from unknown addresses.
5. Automatic security patches, with restarts planned as a separate decision.
6. Time zone and clock synchronization.
7. A backup stored off the machine, with a check on the date of the last run, before any data lands on the server.

What comes next in this series

In the next installment I will describe monitoring: a tool that checks every minute whether my websites and applications respond and alerts me when one of them stops responding. After that I will go through, one by one, the other tools that run on this server.