My Selfhosted Stack in 2026, Audited

Once a year I do an audit of my selfhosted setup. Not a "check for updates" pass — an honest review of every service with one question: if this disappeared tonight, would I actually miss it? Anything that fails the question gets a backup, an export, and a delete command.

This year's audit killed four services and promoted two. Here is the whole stack, what survived, and why.

The rules I self-host by

Before the list, the rules, because the rules are what keeps the stack maintainable by one person with a job:

1. Everything in Docker Compose. One directory, one compose.yaml per stack, all under a git repo. If a service cannot be described in a compose file, it is already too complicated.
2. Backups before features. No new service gets installed until its backup job exists and I have done a restore test. Not a backup plan — a restore.
3. Reverse proxy or it did not happen. Every service sits behind a proxy with TLS. Nothing exposes a raw port to my LAN except the proxy.
4. Boring releases only. I run stable branches and update monthly, not daily. Selfhosting is a hobby that should look like gardening, not firefighting.

What's running

The load-bearing walls

Reverse proxy — one container that terminates TLS for everything, with certificates renewed automatically. This is the single most valuable service in the stack; it turns "a dozen apps with weird ports" into "a dozen normal https URLs."

Reverse proxy's bodyguard — an auth layer in front of anything that does not have good native authentication. Selfhosted apps have wildly uneven security. Putting a uniform login wall in front of the shaky ones is the cheapest security win available.

Backups — the unsexy king. Restic to a local target plus an encrypted offsite copy, scheduled, with a monthly restore drill I actually do. My entire philosophy of selfhosting is downstream of this one service. If you only copy one thing from this post, copy that sentence.

Monitoring — uptime checks and a dashboard that answers "is anything down and is the disk full" at a glance. Disk-full is, was, and forever will be the number one killer of homelabs.

The daily drivers

Photos. The family photo library, selfhosted, with automatic phone backup. This is the service I would rescue first in a fire. It also replaced the most expensive subscription, which paid for the disks inside a year.

Files and sync. A personal sync folder across laptops and phone. Versioning turned on, because the single most common restore request in any file system is "yesterday's copy of the file I overwrote."

Notes and documents. A markdown-notes service with a mobile app. My rule for note apps: the data must be plain files on disk that I can grep. Any notes app that imprisons my writing in a database I cannot trivially export does not survive the audit.

Media server. For my own legally obtained media, streamed to the TV. This is the hobby part of the hobby — it gets tinkered with more than it gets used, and I have made peace with that.

RSS reader. I moved my reading off algorithmic feeds years ago. An RSS server on my own hardware, read on my phone in dead time, is the highest-leverage attention investment I have made.

This year's promotions

A homepage dashboard. I resisted this as pure cosmetics for years. Then I installed one and discovered its actual job: it is an inventory. When every service is a tile, the ones that are stale, unused, or broken become visible — which is exactly what an annual audit needs. Sometimes a pretty UI is an operations tool in disguise.

A small VM host for throwaway experiments. One machine that exists to be broken. Want to try a new database? A sketchy container from a random blog post? It goes in the sandbox VM, never in the production compose directory. This reduced my "oops" incidents to zero by giving me somewhere legal to be reckless.

This year's deletions

Four services failed the disappearing test:

• A selfhosted analytics tool — I am the only visitor to my own sites that matter, and the blog's static build already logs what I need.
• A recipe manager — used twice, then everyone went back to screenshots in the family chat. Deleting it felt like defeat and then immediately felt like relief.
• A password manager replica — I tried, and I will say plainly: this is a category where the hosted options' audits and constant security updates are worth more than my control. Some things want professional full-time attention.
• A second, redundant sync tool that existed only because I never uninstalled it after a migration. The most common service in any homelab is the one left over from a previous homelab.

What I would tell someone starting from zero

Start with three things and nothing else: backups, a reverse proxy, and one service you will use every day (for most people that is photos or files). Live with that for a month. The temptation on day one is to install forty services because a listicle said they were cool; by month three, forty services is why people quit selfhosting entirely.

Second: buy the backup target before you buy the fun hardware. The order of operations matters because it encodes the priority.

Third: write down your restore procedure. A backup you have never restored is a rumor. My drill takes twenty minutes twice a year and it is the only reason I sleep through disk warnings.

The honest ledger

Running your own stack is not cheaper than subscriptions once you count your time, and I have stopped pretending otherwise. What you buy is not savings — it is optionality and memory. My photos do not depend on a company's pricing team. My notes are plain files that will outlive every app I have ever used them with. My reading list is mine.

That is the trade, and after this year's audit — four deletions, two promotions, one tidy compose directory — I am still, boringly, on board.

Current stack: 12 services, 3 disks, 1 sandbox VM, 0 subscriptions for things I care about. See you at next year's audit.