Running your own server sounds like something only an experienced linux sysadmin would do. It isn't — not anymore. Here's what it actually involves, layer by layer, and why you own something real at every step.
Big tech cloud services have you renting a room in someone else's building. Self-hosting means you hold the lease on the whole building — foundation to roof. At every layer of the stack, you are the owner, not a tenant.
This page explains the infrastructure that makes self-hosting possible, layer by layer. If you'd rather skip to the software your team actually uses day-to-day, head to the end user experience page.
Think of it as a building. Each floor supports the one above it. You own the whole structure — and you can replace any floor without demolishing the rest.
One layer at a time. The ownership note at the bottom of each explains why having this layer in your own hands makes a difference.
A domain name like yourorg.org is your permanent address on the internet. It's registered through a domain registrar — a company that reserves the name and lets you control where it points via DNS records.
DNS (Domain Name System) is the glue between your domain and your server. When someone visits mail.yourorg.org, their device looks up a DNS record you control, finds your server's IP address, and connects. Change the record, and traffic goes to a different server. That portability is the whole point.
Choosing a registrar with a clean interface and straightforward DNS management matters. I use and recommend Namecheap, which ticks those boxes. There are other solid options — what matters most is that you hold the account in your own name.
A self-hosted server is only as safe as its backups. I set up two complementary layers:
Cloud provider snapshots — most cloud hosting providers offer a way to take a point-in-time copy of your entire server at the click of a button. Hetzner offers these in their web console. Think of this as a full system restore point. Good for recovering from catastrophic failure.
Application-level backups with Borg — Borg is an open source, deduplicated, encrypted backup tool that runs on a schedule (nightly) and copies your app data to an offsite destination. Unlike a full server snapshot, Borg can restore individual files, mailboxes, or databases without restoring the entire machine. I use a Hetzner Storage Box as the offsite destination — it's affordable, in the same European infrastructure, and integrates well. Others may prefer a different offsite destination.
A cloud server (also called a VPS — Virtual Private Server) is a virtual machine you rent by the month. It's always on, connected to the internet, and yours to configure however you like.
I recommend Hetzner — a German cloud provider with data centres in Germany and Finland, fully subject to European privacy law (GDPR). Their pricing is exceptional: a server capable of running email, workspace, and community software for a small team typically costs €6–€20/month. Their web console lets you configure a firewall, take server snapshots, and resize your server — all without touching the command line.
Every server needs an operating system. For self-hosting open source software, Ubuntu LTS (Long Term Support) is the gold standard — free, widely supported, and targeted explicitly by most self-hosting software. Before any apps go on, the server is hardened: a firewall (UFW) that blocks everything except the ports your apps need, SSH key authentication replacing password login, and automatic OS security updates.
End-users on your domain never interact with any of this. They use their email and apps like normal. The OS is invisible infrastructure.
A reverse proxy is a piece of software that sits in front of all your apps and decides which app gets incoming traffic. When a browser requests mail.yourorg.org, it routes to your email server. When it requests cloud.yourorg.org, it routes to your workspace. One server, multiple services, each on its own subdomain.
It also handles SSL/TLS — the encryption that produces the 🔒 padlock in browsers. Certificates come from Let's Encrypt, a free, automated certificate authority. They're issued and renewed automatically. You never need to buy or manually manage an SSL certificate.
I use Nginx as the reverse proxy. Mailcow ships with its own built-in Nginx, so apps installed on the same server as Mailcow can piggyback on that. Other apps use a separate Nginx instance or Caddy.
Docker is the single biggest reason self-hosting is approachable today. It runs each application in its own sealed, self-contained container — like a shipping container on a cargo ship. Each app brings all of its own dependencies with it, so installing Nextcloud doesn't interfere with your email server, and upgrading Discourse can't break anything else on the server.
Installing most open source software now looks roughly like this:
.env file — a simple text file where you set passwords, API keys, and configuration. It lives only on your server, never in the public code.docker compose up -d — Docker downloads the app image and starts itUpdates follow the same pattern: pull the latest image, run compose again. The app upgrades. Your data, stored separately in a volume, is untouched.
Ten years ago, self-hosting meant manually compiling software, managing system-wide dependencies, and hoping nothing conflicted. Docker changed that entirely.
.env file that you hold. This means no vendor lock-in at the application layer, and migrations between servers are clean and repeatable.When an app on your server needs to send an email — a Discourse notification, a Nextcloud password reset, a calendar reminder — it needs an outbound email relay. The right approach depends on your setup:
For internal installs (a private team's Discourse, a private Nextcloud), I use and recommend routing these notifications through a dedicated account on your own Mailcow server via SMTP. It keeps everything sovereign and in-house, with full control over what gets sent and logged.
For public-facing installs — particularly a Discourse community open to hundreds or thousands of users — it's better to use a dedicated transactional email service. I use and recommend Mailgun for this. Sending high volumes of notifications from your primary mail server's IP address risks damaging its sending reputation, which could affect the deliverability of your own email. Mailgun's free tier covers most small community use cases.
You don't need to configure a web server or write a docker-compose file. That's what I'm here for. But you should feel informed, not dependent. Here's the division of labour — and why it's set up this way.
.env files — your secrets, on your server onlyThe community is where the runbooks live — step-by-step maintenance guides written so that a technically curious person can follow them without needing to call anyone.
.env files, migrating to a new server is well-documented and repeatable: spin up a new server, copy containers and volumes across, update your DNS records. Usually a few hours of downtime at most — often less. There is no lock-in to any provider.I help you set up your server. You run it. The community supports you. That's the model.