Case study / Self-hosted Infrastructure
Homestead
A small, documented self-hosting stack on one Ubuntu server: reverse proxy, private admin access and off-site backups that are actually tested.
- Category
- Self-hosted Infrastructure
- Date
- Stack
- Ubuntu Server
- Docker Compose
- Caddy
- WireGuard
- Restic
- Links
- Not public yet
- Read
- 2 min
Overview
Homestead is a sample case study for a small self-hosting stack on one Ubuntu server: a reverse proxy, a handful of services, private admin access and off-site backups. The interesting part is not any single tool. It is that the whole setup is written down, reproducible and boring to operate.
The problem
Self-hosted setups tend to grow one late-night fix at a time. A year later nobody remembers why a port is open, which container holds the important data, or whether the backups would actually restore. The server works until the day it does not, and then rebuilding it is archaeology.
Goals
- Rebuild the whole server from documentation in an afternoon.
- Expose only HTTPS to the internet.
- Reach admin interfaces only over a private tunnel.
- Back up everything that matters to another location, and prove the restore works.
Technical approach
Every service is defined in Docker Compose files kept in a repository, with one directory per service and a short README beside each. Secrets live in environment files that are excluded from version control and stored in a password manager.
Caddy is the only public entry point. It handles certificates automatically and routes each hostname to its container. Administration happens over WireGuard: SSH and every admin dashboard listen only on the tunnel interface.
Backups run every day with Restic, encrypted, to a storage provider in another region. Once a month a restore runs into a scratch directory and a checklist confirms the important files are there.
Architecture
Figure 1 shows the boundaries. Visitors only ever reach Caddy. The admin's laptop connects through WireGuard before SSH is reachable at all. Backups leave the server on a schedule.
Technology stack
- Ubuntu Server as the base, with unattended security upgrades.
- Docker Compose for every service.
- Caddy for HTTPS and routing.
- WireGuard for private admin access.
- Restic for encrypted, deduplicated off-site backups.
Challenges and solutions
Knowing what to back up
Each service README lists its data directories and how to restore them. The backup script reads that list rather than guessing, so adding a service means documenting its data first.
Admin panels on the public internet
Binding dashboards to the WireGuard interface means they simply do not exist from the outside. There is no login page for anyone to probe.
Updates without surprises
Images are pinned to specific versions. Updates happen deliberately, one service at a time, with a note in the changelog.
Results
Sample entry. Note real outcomes here once you have them: how long a full rebuild from the documentation took, when the last successful restore drill ran, and how often the server needed unplanned attention.
Lessons learned
- Documentation is part of the infrastructure. A setup nobody can rebuild is a liability.
- The best way to secure an admin panel is to make it unreachable.
- Restore drills turn backups from a belief into a fact.
End of case study