I'm not going to make the case for self-hosting here. If you're reading this, you already get it. What I want to do instead is be honest about what I actually run, why I made the specific choices I made, and - more interestingly - how the pieces talk to each other in ways that weren't always planned from the start.
The stack runs across four machines. The bulk of Docker workloads are split between a Mac Mini and an Ubuntu mini PC. Network infrastructure - Traefik and CoreDNS - runs on a Raspberry Pi 4, which also handles the NUT server for UPS management; keeping the network layer on its own always-on hardware means a container crash elsewhere doesn't take down routing or DNS. Home Assistant runs on a Raspberry Pi 5 with the Hailo 8 AI HAT. . It's the reverse proxy in front of every Docker-hosted service, and the main reason I chose it over Nginx or Caddy is Docker-native autodiscovery. When I bring up a new container with the right labels, it appears behind a subdomain with automatic TLS, no config file reload required. That removes enough friction that I'm less tempted to leave things running unproxied on bare ports.
Traefik handles Let's Encrypt certificate issuance and renewal. Services that aren't on the public internet use a DNS-01 challenge, so they get valid certs without being exposed to the web. The rest of the stack is effectively Traefik labels plus container configs all the way down.
Tailscale
is the self-hosted alternative.
CoreDNS
is where all private repositories live: infra configs, personal projects, anything I don't want on a third-party server. Public projects still go to is the pipeline runner, hooked directly into Gitea webhooks. Push to a branch, a pipeline runs. The config lives as a .woodpecker.yml at the repo root, which means pipeline definitions are versioned alongside the code. Woodpecker builds Docker images and pushes them to a local registry on the same host.
Local Docker registry
A plain Docker registry container, served behind Traefik. Woodpecker pushes here; docker compose pulls from here. Keeping images local means builds are fast, no rate limits, and nothing depends on an external registry being up. Not sophisticated. Exactly as much complexity as needed.
WUD - What's Up Docker
for local model inference. The main draws are the obvious ones: no data leaves the machine, no per-token cost, models available offline. Local models cover summarization, document classification, and general Q&A; tasks where a smaller model is good enough and keeping data local matters.
Code assistance is the clear exception: small models aren't reliable enough there, so that goes to cloud APIs - Claude or Codex depending on the task. is my default search engine on all devices. It's a meta-search engine. It queries multiple sources and aggregates results. But the key property is that queries don't get tied to an account or used to build a profile. Results are good enough for 95% of searches, and for the other 5% I have a single click to fall back to whatever source I want.
The setup is minimal: one container behind Traefik, set as the default search engine in the browser. It's one of those things that took twenty minutes to deploy and I've never thought about since.
Documents: Paperless-NGX + Paperless-AI
, which hooks into the Paperless-NGX API and uses a local Ollama model to automatically suggest tags, correspondents, titles (and various other custom properties) as documents come in. This closes a loop with the AI section: Ollama isn't just a chat model, it's doing practical classification work for real files. The whole thing runs locally, so no document content touches an external service.
Password management: Vaultwarden
covering how I handle this specifically for Vaultwarden.
Monitoring & management
Prometheus
is the visual management layer. I use it for quick container inspection, pulling logs, and managing stacks without SSHing in every time. It doesn't replace Prometheus, they have different jobs. Prometheus tells me what happened and when; Portainer tells me what's running right now and lets me poke at it.
Homer
is the thread that ties the whole async event model together. It's a self-hosted push notification server. HTTP POST to a topic, and every subscribed client gets a notification. Woodpecker sends build results here. WUD sends image update alerts here. Home Assistant sends automation notifications here. Having one place where things send notifications means I can manage subscriptions in one app and stop checking dashboards compulsively.
The pattern is simple enough that anything can use it: if a script or service needs to tell me something happened, it makes an HTTP request. No SDK, no auth complexity, just a POST.
Pairdrop
is the one thing in the stack that runs on bare OS rather than Docker. It's Home Assistant OS on a dedicated Raspberry Pi 5, which is a deliberate choice: the add-on ecosystem, hardware device support, and the supervisor layer all work better outside a container. Trying to run it in Docker introduced enough friction with USB devices and networking that the clean answer was to give it its own machine.
Frigate runs as a Home Assistant add-on rather than a standalone container, and that placement matters: it gives Frigate direct access to the Hailo 8 AI HAT on the Pi 5 for hardware-accelerated object detection on camera streams. Running it as an add-on keeps the integration tight and avoids the networking gymnastics that come with trying to expose a hardware accelerator across container boundaries.
It integrates back into the rest of the stack through Ntfy, automations that need to notify me fire an HTTP call to the same notification server everything else uses. One less thing to configure separately.
What's next
One thing I'm actively removing is n8n. On paper it's a great fit — nice UI, trivial to set up, an enormous library of nodes. In practice, for the automations I actually run, it's massively oversized. A tool that big has a way of becoming its own maintenance surface, and when I look at what I'm using it for, most of it is simple enough to replace with a script and an HTTP call to Ntfy. Sometimes the right answer is less, not more.
The stack has been stable enough that I've been iterating on individual services rather than adding new ones. The pieces that took the most time to get right were the CI/CD pipeline (getting Woodpecker, the local registry, and WUD to work as a coherent unit) and Paperless-AI (tuning the prompts so document classification is actually useful rather than just technically running).
If any of this is useful as a starting point, most of these services have reasonable official documentation and active communities. The architecture isn't novel, it's mostly standard self-hosting patterns assembled with some thought about how the parts should talk to each other.
SOCIAL SHARE CARD GENERATOR