Most of our tools and internal apps run on a home server. Not in the cloud, not on someone else's infrastructure — on a machine in the house that we own and control. We call it homeserve, and it's been running continuously for long enough now that it's become part of the background infrastructure of daily life.
Self-hosting has real trade-offs. It requires more setup than signing up for a SaaS product. When something breaks, you fix it yourself. Updates are your responsibility. But the upsides are significant enough that we've kept going with it and have no plans to change.
What runs on it
The list is longer than it used to be. Media management — films, TV shows, music — handled by applications that talk to each other and keep everything organised. A personal meal planner web app for the house, separate from the public Android app. A travel planning app. A photo and file server. Databases. Internal tools. Routing and SSL certificates for all of it.
Everything runs in Docker containers managed with Docker Compose. Adding a new service is a compose file and a DNS entry. That model has scaled well from a few containers to a lot more without becoming unmanageable.
Why not just use cloud services
Cloud services are convenient. They're also subscription costs that add up, data leaving your house for someone else's servers, services that can shut down taking your data with them, and pricing that can change on someone else's schedule.
Running your own server has a one-time hardware cost, an electricity cost, and your time. Once it's set up, most services run without much ongoing effort. The costs don't compound month over month. The data stays home. Nothing disappears because a company decided the product wasn't profitable.
For someone who builds software, running a home server also has the benefit of being genuinely educational. You understand networking, DNS, reverse proxies, SSL certificates, container orchestration — not because you read about them but because you've configured and debugged them. That knowledge carries across into other work.
What the setup looks like
The core of the setup is a reverse proxy — Traefik — that handles incoming requests and routes them to the right container based on the subdomain. SSL certificates are issued automatically via Let's Encrypt. So each service gets its own subdomain with a proper HTTPS certificate, and adding a new service doesn't require touching a configuration file for every other service.
Storage is on a separate large drive rather than the system drive. That separation means the operating system can be reinstalled or upgraded without touching the data. Containers store their configuration and data in a dedicated directory structure on that drive.
DNS for all the subdomains is managed through Cloudflare. External access to private services goes through Cloudflare's access controls, which adds an authentication layer in front of anything that shouldn't be publicly accessible.
For anyone thinking about starting
The learning curve is real but manageable. Start with one service and something low-stakes — a bookmark manager, a recipe app, a note-taking tool. Get comfortable with Docker basics: what a container is, what a compose file looks like, how volumes work for persistent storage.
From that foundation you can grow as far as you want to. The community around self-hosting is large and helpful. Most problems you'll encounter have been solved before and the solutions are well documented.
It suits us because we build software and we enjoy having the control and the understanding of how things work. It won't suit everyone — there's no shame in using a service that just works. But if the idea of owning your own infrastructure appeals to you, the barrier to entry is meaningfully lower than it used to be.