Self-hosting your first service: what you actually need

Self-hosting has acquired an intimidating reputation, as though it demanded a rack of blinking servers and a certification in network engineering. Operating your own services requires dramatically less infrastructure. You need a modest computer, a handful of well-chosen tools, and the discipline to maintain a few unglamorous habits. What follows is the minimum viable setup, stripped of its mythology.

#A machine that stays awake

Almost anything with a processor and a network connection qualifies. A retired laptop, a second-hand mini PC or a Raspberry Pi can host a surprising number of services from inside a desk drawer, and a rented virtual server costing a few euros per month sidesteps every complication associated with residential internet connections. Both approaches are legitimate. Home hardware offers generous storage without monthly fees; a rented server offers a permanent public address, reliable electricity and somebody else's air conditioning.

Choose a mainstream Linux distribution. Debian and Ubuntu remain the conventional starting points, and almost every tutorial you'll consult assumes one of them.

#A name people can type

A domain costs about the price of a decent lunch per year, and it transforms an unmemorable numeric address into something you can share. Point its DNS records at your machine, and consider placing a service such as Cloudflare in front: it conceals your server's real address and absorbs a substantial quantity of hostile traffic before it reaches you.

Residential connections introduce a complication. Many providers place customers behind CGNAT, which means your router never receives a public address and nobody outside can initiate a connection to you. Tunnelling services such as Cloudflare Tunnel or Tailscale solve this with elegance, establishing an outbound connection that visitors can reach without any port forwarding.

#One front door

Resist the temptation to expose every application on its own port. Install a single reverse proxy (Caddy, Traefik and nginx are the established options) that listens on ports 80 and 443 and dispatches each request to the correct application according to its hostname. The proxy obtains and renews TLS certificates on your behalf, so every service receives HTTPS without individual attention. I've written a separate article about how this server's front door is organised.

#Containers, with pinned versions

Docker with Compose has become the lingua franca of self-hosting, and deservedly so. Each application arrives packaged with its dependencies, isolated from its neighbours, and described in a short file you can read, copy and restore. A minimal service definition resembles the following:

services:
  uptime:
    image: louislam/uptime-kuma:1.23.16
    restart: always
    volumes:
      - ./data:/app/data

Notice the explicit version tag. The latest tag invites an unattended update to break something at three in the morning, whereas a pinned version changes only when you decide it should. Upgrade on purpose, read the release notes, and retain the previous compose file so you can retreat if necessary.

#Backups you've tested

Nobody regrets an excessive backup. The traditional guideline, the 3-2-1 rule, recommends three copies of your data on two different kinds of storage, with one copy stored at a different location altogether. Tools such as restic or Borg make encrypted, deduplicated, scheduled backups uncomplicated to automate.

The decisive ingredient is rehearsal. A backup you've never restored is a hypothesis, not a safeguard. Every few months, restore one onto a spare machine and confirm the application starts and the data looks correct, long before the day you need it in earnest.

#Security habits

Security for a small server consists, above all, of reducing exposure and keeping software current. Configure a firewall that admits nothing beyond the ports you intend to publish. Prefer SSH keys to passwords, or at minimum combine a long, unique password with something like CrowdSec or fail2ban, which bans addresses after repeated failed attempts. Switch on automatic security updates for the operating system. Store secrets in environment files excluded from version control, never inside a public repository.

None of this requires paranoia. It requires consistency.

#Watch it from the outside

Sooner or later your server will fail at an inconvenient moment, and you'd prefer to discover that before your visitors do. A small monitoring service such as Uptime Kuma, running on a different machine if possible, checks your sites every minute and sends a notification when something stops responding.

#Begin with one thing

The most dependable way to abandon self-hosting is to migrate everything during a single ambitious weekend. Pick one service you'll use every day, perhaps a password manager, a photo library or a personal website, and operate it for a month. Once backups, updates and monitoring have become routine for that first service, the second one consumes a fraction of the effort.

If you'd prefer a graphical panel to manage containers, deployments and backups, RivetPanel exists for that purpose.