Companion piece to Hacker Public Radio. Part of the Infrastructure Independence series.

Abstract

Self-hosting is having a moment. It's also attracting a lot of bad advice. This article cuts through the homelab fantasy to answer the questions that actually matter: what is worth hosting yourself, what is not, what the real threat model is, and how to build infrastructure that survives you being unavailable for two weeks.

1. The Honest Threat Model

Most self-hosting guides start with "you should own your data." They are correct and useless. Which data? From whom? At what cost?

The realistic threat model for a privacy-conscious individual or small organization in 2026 is:

1. Commercial surveillance — platforms monetizing behavioral data
2. Data broker aggregation — your data purchased and resold without consent
3. Account compromise — credential stuffing, phishing, session hijacking
4. Platform discontinuation — services shut down or acquired and changed
5. Legal compulsion — platforms complying with government data requests you are not notified of

Nation-state adversaries and advanced persistent threats are not in scope for this article. If that is your threat model, self-hosting is the least of your concerns and this is not the guide for you.

2. What to Host

2.1 Host this

Email, if you have the operational maturity. Email is identity. It is the recovery mechanism for every other account. Losing control of your email domain means losing everything tied to it. The operational cost is real — deliverability, spam filtering, key management — but the control is worth it for anyone with a genuine privacy practice.

Git. Your code, your commits, your history. SourceHut, Forgejo, or a bare git server over SSH. The case was made in post 02.

Password manager. Vaultwarden (Bitwarden-compatible) on hardware you control. Encrypted at rest, accessible over Tailscale or WireGuard. Not on a public IP. Not behind a cloud provider's identity system.

DNS resolver. Unbound or a Pi-hole equivalent. Blocks known tracking and malware domains at the network layer. Does not replace per-application controls but is a meaningful layer.

Media and documents. Immich for photos. Paperless-ngx for documents. These are high-value, low-threat targets — no reason to pay a platform for the privilege of training their AI on your family photos.

2.2 Do not host this

Your primary communications if you cannot guarantee uptime. A Matrix homeserver that goes down on a Friday evening and comes back Monday is worse than Signal. Availability is a security property.

Anything requiring 24/7 human attention to stay secure. Security patches do not take weekends off. If you cannot commit to patching within 48 hours of a critical CVE, do not run a public-facing service.

Certificate authority infrastructure. Use Let's Encrypt. Running your own CA for anything other than internal services is an operational and security liability that almost nobody needs.

3. The Stack That Actually Works

This is what I run on dapla.net infrastructure. It is not the only valid answer. It is an answer that has survived production use.

3.1 Compute

Podman quadlets over Docker Compose. Rootless systemd-managed containers. No daemon running as root. Quadlet files live in /etc/containers/systemd/, managed by systemd, monitored by journald. Restarts on failure. Survives reboots.

# Example quadlet: /etc/containers/systemd/vaultwarden.container
[Unit]
Description=Vaultwarden password manager
After=network-online.target

[Container]
Image=docker.io/vaultwarden/server:latest
AutoUpdate=registry
Volume=storage/vaultwarden:/data:Z
Environment=DOMAIN=https://vault.dapla.net
Environment=SIGNUPS_ALLOWED=false
[email protected]

[Service]
Restart=always

[Install]
WantedBy=multi-user.target default.target

3.2 Storage

ZFS on everything that matters. storage/ pool. Dataset per service: storage/containers/vaultwarden mountpoint at /srv/vaultwarden. Snapshots automated via zfs-auto-snapshot. Off-site replication via zfs send | ssh.

The ZFS snapshot is your first line of recovery. It costs nothing to enable. Not having it costs everything when you need it.

3.3 Networking and reverse proxy

HAProxy, not Nginx. HAProxy's ACL system, health check granularity, and connection handling under load are meaningfully better for a service mesh where you control the full stack. Configuration is more verbose. That verbosity is documentation.

frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/
    default_backend vaultwarden_back
    acl is_vault hdr(host) -i vault.dapla.net
    use_backend vaultwarden_back if is_vault

backend vaultwarden_back
    server vaultwarden 127.0.0.1:8080 check

3.4 Monitoring without the complexity tax

Two things. systemd status and journald for service health. Uptime Kuma behind Tailscale for external reachability checks and alerts. That is it. Prometheus/Grafana is correct at scale. At one to five nodes it is operational overhead with no return.

4. The Survivability Question

Ask yourself: if you are unavailable for two weeks, what breaks?

If the answer is "email," that is a bus factor problem, not an infrastructure problem. Document your stack. Store credentials in the self-hosted password manager and in a hardware-encrypted backup that a trusted person can access. Write a runbook. Runbooks are not bureaucracy — they are the thing that saves your service when you are in the hospital.

Infrastructure independence is not the same as infrastructure solipsism. The goal is resilience, not heroic single-person operation.

5. Start Here, Not There

The single highest-value first step is not standing up a server. It is getting your own domain name and pointing your email to it, even if you use a hosted email provider for now. The domain is yours. The provider is interchangeable. That separation is what independence actually means.

Everything else follows from that decision.

Next in the series: certificate management at scale for a one-person operation. HPR episode and write-up forthcoming.