How I set up a new VPS

Every time I rent a new server I go through the same ritual before I let it do anything useful. This isn't a command manual, although I include the essential ones: it's the order I do things in, why I do them, and the stumbles that taught me not to skip a single step.

You've surely seen the video: "rent a VPS, install your agent and off you go", five minutes and a smiling man. And it's half true: starting up a machine is lightning fast. Making it secure isn't.

If you don't know what a VPS is, think of a slice of a big server that you rent and that behaves like a whole computer for you, on day and night and connected to the internet.

Here I'll explain how to set up a VPS in the order I do it: choosing a provider and machine, first access, users and keys, firewall and updates, backups, what I always install, my mistakes and, at the end, the checklist. The commands I give are for Ubuntu, which is what all six of my VPSs run (reviewed in September 2026 with 24.04). On Debian they're almost identical; in the Red Hat family the names change (dnf, firewalld). You can ask any assistant for the rest by telling it what system you have; what it won't give you is the order or the reasons, and that's what took me time to learn.

My six VPSs aren't all in the same place. I have four at Hetzner and two at IONOS, and the reason is more mundane than it sounds. I chose Hetzner because its data centres are in Europe, which simplifies the conversation about where clients' data lives, and because its panel is simple. IONOS came later, because I already had domains and email there and it was convenient to have everything together with the same Spanish-language support.

I decide the size by the job, not by enthusiasm. A VPS that only receives requests and hands them out can be small, with two cores and four gigs of memory. One that's going to have databases or several services at once I take a bit bigger, with eight gigs. None has a graphics card: that's what the internal network is for, and I tell that story in What runs on each of my machines.

For the system, almost always Linux. Why, and when not, is in Linux or Windows on my servers.

A selection mistake I did make: at the start I took the cheapest VPS for a service that later grew, and two months in I had to migrate it to a bigger machine on a Sunday afternoon. I saved a few euros and lost a whole afternoon.

The first time, I log in however the provider lets me. In my case, the panel lets me load my public key when creating the machine, so the first access is already with a key and as administrator. That first access is for one thing only: getting the house ready so I never have to log in that way again.

The first thing I do is create my own user and give it permission to carry out admin tasks when explicitly requested. I don't work as the administrator user for the same reason you don't walk around your home carrying the keys to the whole building: if something goes wrong, the damage stays smaller.

Then, the access keys. The difference from a password is easy to grasp with a simple comparison: a password is a code someone can guess if they try long enough; a key is a physical key that only you have. The server keeps the lock, your computer keeps the key, and without the key there's nothing to guess.

sudo adduser youruser
sudo usermod -aG sudo youruser
# copy your public key to /home/youruser/.ssh/authorized_keys

Once I've checked that I can log in with my user and my key, I switch off two things: direct administrator login and password login. Before applying it, I check the configuration has no errors:

# in /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no

sudo sshd -t && sudo systemctl reload ssh

I also change the default access port. It cuts the noise in the logs, but it doesn't protect anything on its own: what protects you is the keys, limiting attempts and keeping the system up to date. I don't use two-factor authentication for remote access; I do have it switched on for the provider's panel, because whoever gets in there can open the emergency console and get into everything.

And here comes the classic scare. On the second machine I set up, I disabled passwords before checking that my key worked with the new user. Result: I locked myself out of my own server. I had to get in through the provider's emergency console, which is like getting into your house through the bathroom window, and undo the mess. Since then I have a rule: I never close the open session until I've successfully logged in from another window, with ssh -p PORT youruser@IP.

A firewall is the filter that decides which connections get into the machine and which stay at the door. By default, many freshly created VPSs don't have one active, and everything that's listening is in plain view.

My approach is to close everything and open only what's needed. On a typical machine of mine I leave remote access open and, if it serves a website, the web ports. Nothing else. Databases, admin panels and internal services aren't opened to the outside: if I need to reach them, I go in through the tunnel to the internal network.

With updates I do the same thing every time: I bring everything up to date before installing anything. A freshly created machine comes with the system as it was when the image was prepared, which may be weeks or months old, and there's no point building something on top of known holes. Afterwards I leave automatic security updates switched on and, once a month, I review the rest by hand and reboot if needed.

The other protection I add is against repeated attempts. I use fail2ban, a program that watches the logs and, when the same address fails several times in a row trying to get in, blocks it for a while.

sudo apt update && sudo apt upgrade
sudo apt install unattended-upgrades fail2ban
sudo ufw default deny incoming
sudo ufw allow PORT/tcp        # the remote access one, before enabling
sudo ufw allow 80/tcp && sudo ufw allow 443/tcp   # only if it serves a website
sudo ufw enable && sudo ufw status verbose
sudo fail2ban-client status sshd

Mind the order: if you switch the firewall on before opening your port, you lock yourself out.

I set up backups before there's anything to back up. If I leave it until there's something important, I forget, and the day you need them comes sooner than expected.

I have two layers. The first is the provider's automatic backups, which save the whole machine every night and keep a few days' worth. The second is a daily copy of the data and configuration to one of the servers on the internal network, in the early hours. If the power goes out at home for a week, the provider's copy is still there. But those two layers aren't fully independent: the provider's backup lives with the machine and under the same account, and if the account or the platform fails, they go together.

The classic rule is 3-2-1: three copies, on two different media, one away from the main site. To get closer to it, since this summer the home copy is duplicated once a week to an external drive that I only plug in for that.

Then there's the test almost nobody does: restoring. A backup you've never restored is a hope, not a backup. I did it for the first time in March 2025, bringing up a new machine from another one's backup. It worked, but I found I was missing a configuration file that wasn't on the list of things being copied. I added it that same afternoon. Since then I do a test restore once a month: I spin up a temporary VPS, load the backup, check the service starts and responds, and delete it.

Once the house is locked up, I install the basics that go on every machine, before whatever is specific to each one:

• A monitoring agent, to see memory, disk and processor without having to log in.
• The tunnel client that connects it to the internal network.
• Docker, because almost everything I run afterwards goes in containers, and that keeps it apart from the system.
• What the agents need: the environment to run their tools and the variables with the API keys, stored outside the code.

Claude keeps me company through all of this. I tell it what system I have and what I want to do, and it guides me step by step. I also hand it the configuration to review for anything left too open. What I don't let it do is work alone: I don't give it free rein on a freshly created machine to configure it while I have a coffee. Every command that touches security, I read, understand and run myself.

The first was leaving security for later. On the first VPS I installed the service I needed and thought I'd deal with the rest at the weekend. Nothing serious happened, but when I looked at the logs there were thousands of password login attempts in three days. It scared me so much that I wiped it and started from scratch. Cost: a lost afternoon and a good while in a cold sweat.

The second, a port that was open when it shouldn't have been. I left a database admin panel exposed "just for testing". I found it open two weeks later, with nobody having got in, as far as I know. It didn't cost me money; it cost me the peace of mind of not knowing for sure.

The third, a machine without backups. A test VPS that became important without warning. When the disk got corrupted, I lost about six hours rebuilding the configuration by hand.

And how long does it take? The first time it took me almost a whole day, between reading, getting things wrong and starting again. Today, with the list and the assistant's help, a machine is ready in just over an hour; that's what the clock said on the last three I set up. These are my times, not a benchmark: they depend on what each machine runs.

A warning that isn't an exaggeration: a freshly created machine with a public address starts receiving automated access attempts very quickly.

On the last VPS I set up, I left the logs unfiltered for the first few hours to see it with my own eyes. The first attempt came twenty minutes after switching the machine on. In the first twenty-four hours I counted more than twelve hundred login attempts, almost all trying the administrator user and textbook passwords. I counted them in the authentication log, with the default port still open; once I changed it they dropped to a few dozen a day. That's what I saw on one particular machine, not a statistic. None got in, because there were no longer any passwords to guess. But seeing that list changes how you think about "I'll do it later".

This is the list I go through on every new machine:

• Provider and size chosen according to the job
• Own user created, direct administrator login disabled
• Key-only access, passwords disabled
• Firewall active, only the essentials open
• System updated and automatic security updates on
• Protection against repeated attempts
• Scheduled backups, one of them away from the provider, and a tested restore
• Base install: monitoring, tunnel, containers

Copy it and make it your own; what matters is always following it in the same order. Which system each machine runs and why, I explain in Linux or Windows on my servers.