How to Set Up Your First VPS (Complete Beginner Guide)

Setting up your first VPS can feel intimidating. There are unfamiliar acronyms, a blank terminal staring back at you, and the nagging worry that you’ll break something irreversibly.

I’ve been there. When I set up my first Hostinger KVM server, I spent hours searching for tutorials that explained not just what to type, but why. This guide is what I wish I had on day one.

By the end of this tutorial, you’ll have a VPS that’s online, accessible via SSH, and locked down with a firewall, fail2ban, and key-based authentication. That’s a solid foundation for everything else you’ll want to do — Docker, self-hosting, reverse proxies, you name it.

What is a VPS?

A VPS (Virtual Private Server) is a virtual machine running on shared hardware in a data center. You get your own operating system, your own IP address, and root access to install whatever you want. Think of it as renting a computer that’s always on, always connected, and sitting in a data center somewhere with a very fast internet connection.

Unlike shared hosting (where you’re crammed onto a server with hundreds of other sites), a VPS gives you full control. You choose the operating system, you decide what software runs, and you’re responsible for keeping it secure.

Common uses for a VPS:

• Hosting websites and web apps
• Running Docker containers
• Self-hosting tools like n8n, Nextcloud, or Uptime Kuma
• Running databases (PostgreSQL, Redis)
• VPN server for private browsing
• Running AI models locally with Ollama

Choose a VPS provider

There are dozens of VPS providers. Here are the ones I’ve used or tested, in order of what I’d recommend for beginners:

Hostinger KVM — This is what I personally run. The KVM virtualization gives you better isolation than OpenVZ-based providers, the pricing is aggressive, and the control panel is beginner-friendly. If you’re following along with this tutorial, this is what I’d pick.

DigitalOcean — Clean interface, excellent documentation. Slightly pricier than Hostinger but rock-solid. Their $6/month droplet is a good starting point.

Hetzner — Best value in Europe. If latency to EU matters to you, Hetzner is hard to beat on price-to-performance.

Vultr — Global data center coverage. Good if you need a server in a specific region.

Purchase and create your server

Once you’ve picked a provider, you’ll need to create a server. The exact UI varies by provider, but you’ll always configure these things:

Operating System: Choose Ubuntu 24.04 LTS. It’s the most widely supported Linux distribution, almost every tutorial you’ll ever find is written for it, and LTS (Long Term Support) means it gets security updates for 5 years.

Server location: Pick the data center closest to you geographically. Lower latency means faster SSH sessions and faster page loads for anything you host.

Plan size: For learning, 1 vCPU / 1 GB RAM / 20 GB SSD is plenty. You can always resize later.

Authentication: Most providers will ask you to set a root password or upload an SSH key. For now, set a strong root password (20+ characters, mixed case, numbers, symbols). We’ll switch to SSH keys later in this guide.

After provisioning (usually 30-60 seconds), you’ll get:

• An IP address (something like 203.0.113.42)
• A root password (the one you just set)

Write both down. You’ll need them in the next step.

Connect to your VPS via SSH

SSH (Secure Shell) is how you’ll interact with your server. It gives you a remote terminal session — the same as if you were sitting at a keyboard plugged directly into the machine.

Open your terminal and type:

ssh root@YOUR_SERVER_IP

Replace YOUR_SERVER_IP with the actual IP address from the previous step.

The first time you connect, you’ll see a fingerprint warning:

The authenticity of host '203.0.113.42' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes and press Enter. This adds the server to your known hosts file so you won’t see the warning again.

Enter your root password when prompted. You should now see a command prompt like:

root@your-server:~#

You’re in. You’re now controlling a server in a data center somewhere via an encrypted connection. Everything you type runs on that remote machine.

Update your system

Before doing anything else, bring your server up to date. This installs the latest security patches and package updates.

apt update && apt upgrade -y

apt update refreshes the list of available packages. apt upgrade -y installs all available updates. The -y flag auto-confirms so you don’t have to press Y for each package.

This might take a minute or two depending on how many updates are pending. Let it finish.

Create a non-root user

Running everything as root is dangerous. A single typo in a command could wipe your server. Best practice is to create a regular user and give it sudo access (the ability to run commands as root when needed).

adduser deploy

You’ll be prompted to set a password and fill in some optional info (full name, etc.). The password is required; the rest you can skip by pressing Enter.

Now give this user sudo privileges:

usermod -aG sudo deploy

This adds the deploy user to the sudo group, which means they can run commands with sudo when root access is needed.

Test the new user by switching to it:

su - deploy

Try running a command that requires root:

sudo apt update

If it asks for the password and runs successfully, your sudo access is working. Switch back to root for now:

exit

Set up a firewall with UFW

A firewall controls which network traffic can reach your server. Without one, every port on your server is potentially exposed to the internet.

UFW (Uncomplicated Firewall) is the standard firewall tool on Ubuntu. It’s a user-friendly frontend for the underlying iptables rules.

First, check if UFW is installed (it usually is on Ubuntu):

ufw status

If it says “inactive”, that’s expected. Let’s configure it before enabling.

Allow SSH connections (this is critical — if you enable the firewall without allowing SSH, you’ll lock yourself out):

ufw allow OpenSSH

Enable the firewall:

ufw enable

You’ll see a warning about disrupting SSH connections. Type y to confirm. Since you just allowed OpenSSH, your current connection will stay alive.

Verify the rules:

ufw status verbose

You should see:

Status: active

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)

The firewall is now active and only allows SSH traffic. Everything else is blocked by default. When you later install a web server or other services, you’ll open specific ports as needed.

Install fail2ban

fail2ban monitors your server’s log files and automatically bans IP addresses that show malicious behavior — like repeatedly failing SSH login attempts. It’s one of the simplest and most effective security measures you can add.

apt install fail2ban -y

Create a local configuration file (so your settings survive package updates):

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edit the local config:

nano /etc/fail2ban/jail.local

Find the [sshd] section and make sure it looks like this:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
findtime = 600

This means: if an IP fails SSH login 5 times within 10 minutes (600 seconds), ban it for 1 hour (3600 seconds).

Save the file (Ctrl+O, Enter, Ctrl+X) and restart fail2ban:

systemctl restart fail2ban
systemctl enable fail2ban

Check that it’s running:

fail2ban-client status sshd

You should see it’s active with 0 currently banned IPs (since you just set it up).

Set up SSH key authentication

Passwords can be brute-forced. SSH keys can’t (practically speaking). Switching from password-based login to key-based login is the single biggest security improvement you can make.

Generate an SSH key pair (on your local machine)

Exit your server session first (type exit or press Ctrl+D) so you’re back on your local machine.

ssh-keygen -t ed25519 -C "your-email@example.com"

ed25519 is a modern, secure key type. When prompted for a file location, press Enter to accept the default (~/.ssh/id_ed25519). Set a passphrase if you want extra security (recommended), or press Enter twice for no passphrase.

This creates two files:

• ~/.ssh/id_ed25519 — your private key (never share this)
• ~/.ssh/id_ed25519.pub — your public key (this goes on the server)

Copy the public key to your server

ssh-copy-id deploy@YOUR_SERVER_IP

Enter the password for the deploy user when prompted. This command copies your public key to the server and sets the correct file permissions automatically.

cat ~/.ssh/id_ed25519.pub | ssh deploy@YOUR_SERVER_IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh"

Test key-based login

ssh deploy@YOUR_SERVER_IP

If everything is set up correctly, you should log in without being asked for a password (or only asked for your key passphrase, if you set one).

Disable password authentication

Now that key-based login works, disable password authentication entirely. SSH into your server and edit the SSH config:

sudo nano /etc/ssh/sshd_config

Find and change these lines (they might be commented out with #):

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Setting PermitRootLogin no is important — it prevents anyone from SSH-ing in as root, even with a key. You’ll use your deploy user and sudo for everything.

Save the file and restart SSH:

sudo systemctl restart sshd

Set up automatic security updates

Your server should install critical security patches automatically. Ubuntu has a tool for this called unattended-upgrades.

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Select “Yes” when prompted. This enables automatic installation of security updates. Your server will check for and apply security patches daily without you having to SSH in and run apt upgrade.

Verify your setup

Let’s do a quick sanity check. Run through this checklist:

# Check UFW is active
sudo ufw status

# Check fail2ban is running
sudo fail2ban-client status sshd

# Check unattended-upgrades is enabled
sudo systemctl status unattended-upgrades

# Check you're not logged in as root
whoami

If whoami returns deploy (or whatever you named your user), UFW is active, fail2ban is running, and unattended-upgrades is enabled — your VPS is properly set up and secured for a beginner.

What’s next?

Your VPS is online and secured. Here’s what I’d tackle next, in order:

1. Install Docker — Containerize everything you run. It makes deployment, updates, and cleanup so much easier.
2. Set up a reverse proxy — Traefik or Nginx Proxy Manager lets you run multiple services on one server with automatic SSL certificates.
3. Self-host something useful — n8n for automation, Uptime Kuma for monitoring, or whatever tool you’ve been wanting to try.

Each of these has a dedicated tutorial on this site. You’ve got the foundation — now build on it.

Troubleshooting

”Connection refused” when trying to SSH

• Server isn’t running: Check your provider’s dashboard. Make sure the server is powered on.
• Wrong IP address: Double-check the IP in your provider’s control panel.
• Firewall blocking SSH: If you accidentally blocked SSH, use your provider’s web console (browser-based terminal) to fix the UFW rules.

”Permission denied (publickey)” after disabling passwords

• You didn’t copy the SSH key correctly. Use your provider’s web console to log in, then re-enable PasswordAuthentication yes in /etc/ssh/sshd_config temporarily, restart sshd, and redo the key copy step.

”sudo: command not found”

• You’re likely on a minimal server image. Install sudo: log in as root via the web console and run apt install sudo, then add your user to the sudo group.

Server feels slow

• Check if you’re running out of RAM: free -h
• Check disk usage: df -h
• Check what’s using CPU: top or htop (install with apt install htop)

FAQ

How much does a VPS cost?

Plans start around $4-6/month for a basic server with 1 GB RAM. That’s enough for learning, running a few Docker containers, or hosting a low-traffic website. You can scale up as needed.

Is a VPS the same as a dedicated server?

No. A dedicated server gives you an entire physical machine. A VPS is a virtual machine sharing hardware with other VPS instances. For most use cases, a VPS is more than sufficient and significantly cheaper.

Can I run Windows on a VPS?

Technically yes, but Linux (specifically Ubuntu) is the standard for VPS work. It’s lighter, faster, free, and virtually all server software is built for it. This site focuses on Linux-based VPS setups.

What if I break something?

Most providers offer snapshot/backup features. Before making major changes, take a snapshot. If things go wrong, restore from the snapshot. It’s like an undo button for your entire server.

Do I need to know Linux to use a VPS?

You’ll learn as you go. This tutorial covered the essential commands. The more you use your server, the more comfortable you’ll get with the terminal. It’s a skill that compounds — every command you learn makes the next tutorial easier.