Your first VPS: what to do after you log in

So you bought a VPS, you got an email with an IP address and a password, and now you're staring at a blank terminal wondering what on earth to do next. That's a normal feeling. A fresh server is just an empty Linux box, and the first hour you spend on it sets the tone for everything that comes after. This is the short list of things we do on day one, in the order we'd actually do them.

First, connect over SSH

SSH is how you talk to a server that has no screen or keyboard plugged in. On Linux and macOS you already have it. On Windows you can use the built in terminal, PowerShell, or PuTTY if you prefer a window with boxes to fill in. Your provider gives you three things: the server IP, a username (usually root to start), and a password.

The command looks like this:

ssh [email protected]

The first time you connect you'll get a message about the host key and whether you trust it. Type yes. Then enter the password. If you're on Bytte.cloud the panel at panel.bytte.cloud shows your IP and login details, so you don't have to dig through your inbox for them.

A quick warning: if the connection just hangs and times out, it's almost always one of two things. Either you typed the IP wrong, or a firewall somewhere is blocking port 22. Double check the IP before you assume something is broken.

Update everything before you do anything else

The image your VPS was built from is a snapshot in time, and that snapshot is often weeks or months old. There will be security patches waiting. Get them first. On Debian or Ubuntu, which is what most people start with, run:

apt update
apt upgrade

The first command refreshes the list of available packages. The second actually installs the newer versions. It might ask you to confirm and it might take a few minutes. If it ever asks about keeping or replacing a config file and you have no idea, keeping the local version is usually the safe default. Once in a while an upgrade touches the kernel and you'll want to reboot with reboot to load it.

Honestly, this one step closes off a surprising number of problems before they ever happen. Do it on day one and then make a habit of it.

Stop living as root

Root can do anything, which sounds great until you fat finger a command and delete something you needed. Working as root all day is a bit like carrying a chainsaw around the house just in case. You want a normal user for everyday work, and the ability to borrow root powers only when you actually need them. That's what sudo is for.

Create a user. Swap dom for whatever name you like:

adduser dom
usermod -aG sudo dom

The first line makes the account and asks you to set a password. The second adds it to the sudo group so it can run admin commands by typing sudo in front of them. Now open a second terminal and log in as that new user to make sure it works:

ssh [email protected]

Once you can log in and run something like sudo apt update successfully, you've got a working everyday account. Keep the first terminal open as root for now, just in case. We'll need it in a minute.

Set up SSH keys and turn off password login

Passwords get guessed. The moment your server is online, bots start hammering port 22 trying common username and password pairs. SSH keys fix this. A key pair is two files: a private key that stays on your computer and never leaves it, and a public key that you copy to the server. The server lets you in only if your private key matches. No password to guess.

On your own machine, not the server, make a key if you don't already have one:

ssh-keygen -t ed25519

Press enter to accept the default location. You can add a passphrase for extra safety, which protects the key if your laptop is stolen. Then copy the public half up to the server:

ssh-copy-id [email protected]

If ssh-copy-id isn't available on your system, you can paste the contents of your .pub file into the file ~/.ssh/authorized_keys on the server by hand. Now test it. Open yet another terminal and run ssh [email protected]. If it lets you in without asking for a password, the key works.

Only once that works should you turn off password login. Edit the SSH config:

sudo nano /etc/ssh/sshd_config

Find or add these lines:

PasswordAuthentication no
PermitRootLogin no

Save, then restart SSH with sudo systemctl restart ssh. Here is the part people skip and regret: do not close your existing session yet. Keep it open, open a brand new terminal, and confirm you can still log in. If something is wrong, your old session is still alive and you can fix it. If you close everything and the key fails, you've locked yourself out of your own server. That spare root terminal we kept open earlier is your safety net.

Put up a basic firewall

By default a fresh server may have ports open that you never asked for. A firewall lets you decide what the world can reach. On Ubuntu the friendly tool for this is ufw, which stands for uncomplicated firewall, and it earns the name.

The golden rule is to allow SSH first, before you turn the firewall on. Skip that and you lock yourself out the instant you enable it.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

That allows SSH and blocks everything else coming in. From here you open ports only as you need them. Running a website? Open the web ports:

sudo ufw allow 80
sudo ufw allow 443

Running a Minecraft server? You'd open 25565. The point is that each open port is a door, and you only want doors where you actually have something behind them. If you changed your SSH port to something other than 22, make sure you allowed that exact port before enabling the firewall.

Install only what you need

It's tempting to load up a new server with every tool you can think of. Try not to. Every package you install is more code that can have bugs, more services that might listen on a port, and more stuff to keep updated. A lean server is easier to reason about and easier to secure.

So install for the job in front of you. A web project might need Nginx and a database. A Python Discord bot needs Python and pip and maybe git. Some genuinely useful basics that we reach for early are:

• htop for watching memory and CPU at a glance
• git for pulling your code onto the server
• fail2ban, which watches login attempts and bans IPs that keep failing
• curl for quick tests and downloads

Add things as the need turns up, not before. If you install something to try it and decide against it, remove it with sudo apt remove so it isn't sitting there forgotten.

Snapshots and backups, before you have anything to lose

This is the boring one that saves you. There are two ideas here and they're not the same thing.

A snapshot is a full image of your whole server frozen at a moment. Most providers let you take one from the control panel. It's perfect right before a risky change. Take a snapshot, do the scary upgrade, and if it goes sideways you roll back to exactly how things were. Take one now, while the server is clean and freshly set up. A clean baseline is a lovely thing to have when something later goes wrong.

A backup is a copy of your actual data, like your website files, your database, or your bot's config, ideally stored somewhere other than the server itself. The reason it has to be elsewhere is simple. If the whole machine has a bad day, a backup that lived only on that machine is gone too. Set up something that copies your important files off the box on a schedule. Even a nightly job that pushes a database dump to another location beats nothing.

And please, test that a restore actually works at least once. A backup you've never restored is just a hopeful guess. We've seen people discover their backups were empty only at the exact moment they needed them, which is the worst possible time to find out. Bytte.cloud plans include backup slots so you have a place to keep these without thinking too hard about it.

Where that leaves you

Run through this list and your first day is well spent. You're patched and current, you log in with a key instead of a guessable password, root login is off, you've got a non root user for normal work, a firewall is blocking the doors you don't use, the server is lean, and you have a clean snapshot to fall back on. None of it takes long, and you only really have to do most of it once. After that you can get on with the fun part, which is actually building the thing you got the server for in the first place.