Getting Started with Self-Hosting: A Beginner's VPS Guide

Self-hosting is one of those things that looks terrifying from the outside and deeply satisfying once you’re inside. This is the guide I wish existed when I first SSH’d into a blank Ubuntu server and stared at a blinking cursor.

Why Self-Host Anything?

Before we dive into the how, let’s talk about the why. Self-hosting gives you three things that managed services rarely can:

Full control. You decide what runs, when it runs, and how it’s configured. No vendor lock-in, no surprise pricing changes, no features being sunset.

Real learning. Managing a server forces you to understand the stack beneath your applications. Nginx stops being magic; it becomes config files you can actually read and modify.

Cost efficiency at scale. A $6/month VPS can run a dozen small services that would cost ten times that on managed platforms.

Picking Your First VPS Provider

Not all VPS providers are created equal. Here’s what actually matters for a beginner:

What to Look For

The most important factors are network quality, support responsiveness, and control panel usability — not raw specs. A provider with 10% less RAM but solid documentation and a helpful community is worth more than bleeding-edge hardware with no support.

My current recommendations for beginners: DigitalOcean for the best onboarding experience, Hetzner for the best price-to-performance ratio in Europe, and Vultr for global coverage.

Specs for Starting Out

For a first server running 2–3 services:

• 1–2 vCPU
• 2 GB RAM minimum
• 20 GB SSD
• Ubuntu 22.04 LTS (stable, widely documented)

Setting Up Your Server

Once your VPS is live, the first 20 minutes are critical. Do these before anything else.

Initial Security Hardening

# Create a non-root user
adduser dipo
usermod -aG sudo dipo

# Set up SSH key authentication
mkdir -p ~/.ssh
echo "your-public-key-here" >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

# Disable root login and password auth
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

Firewall Setup

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

This blocks everything except SSH and web traffic. Simple and effective.

Installing Docker

Docker is how I run almost everything on my server. Containers isolate services from each other and make updates and rollbacks trivial.

# Install Docker
curl -fsSL https://get.docker.com | bash

# Add your user to the docker group
usermod -aG docker $USER

# Install Docker Compose
apt install docker-compose-plugin

Log out and back in for group changes to take effect.

Your First Container

Let’s deploy something real. Here’s a minimal docker-compose.yml for running Uptime Kuma — a self-hosted status page:

version: "3.8"
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./uptime-kuma-data:/app/data

docker compose up -d

Visit http://your-server-ip:3001 and you’ll see Uptime Kuma’s setup screen. That’s it — your first self-hosted service.

What’s Next

Once you’re comfortable with a single container, the next natural steps are:

1. Set up a reverse proxy — Caddy or Traefik so you can run multiple services behind real domain names with automatic HTTPS
2. Automate backups — because disks die and you will make mistakes
3. Add monitoring — Netdata or Grafana + Prometheus to know when things go wrong before your users do

Self-hosting is a rabbit hole. A very rewarding one. Welcome to the playground.