Things I Stopped Self-Hosting (And Why Cloud Won in My Home Lab)

High-level summary

• Speaker: Brandon Lee (Virtualization How To).
• Theme: Which services he deliberately stopped self-hosting in his home lab, why managed/cloud solutions won for those cases, and the criteria he uses to decide what to self-host vs move to SaaS/cloud.

Core message: Self-hosting is valuable for learning and control, but some services add unacceptable ongoing operational overhead, risk, or fragility. He moved those to managed/cloud providers to reduce stress and increase reliability while keeping the parts of his lab he finds valuable.

---

Services he stopped self-hosting

1. Email

   • Problems:
     • Deliverability complexity (DKIM, SPF, reverse DNS, IP reputation).
     • ISPs often block outbound port 25 on residential links.
     • Frequent silent breakage and constant troubleshooting.
   • Decision: Moved to a managed email provider to avoid constant email troubleshooting.
   • Tradeoffs: Privacy concerns exist, but Brandon already uses cloud email on phones/work. Truly private messaging typically wouldn’t use standard email anyway.

2. Public / authoritative external DNS

   • Problems:
     • Large blast radius: if public DNS fails, dependent services and TLS certs/API endpoints can appear offline.
     • Susceptible to home power or ISP outages when self-hosted at home.
   • Decision: Use a managed public DNS provider (Cloudflare). Retains internal DNS on-prem.
   • Notes: Uses split-horizon/internal DNS for different internal/external records. Mentions Technitium DNS clustering as an interesting internal DNS project (auto-transcript name may vary).

3. Remote access gateways (exposed VPN servers)

   • Problems:
     • Edge exposure risk — inbound VPN servers (WireGuard/OpenVPN) can be attractive targets after other compromises.
   • Decision: Switched to zero-trust connectivity solutions that avoid opening inbound firewall ports.
   • Examples / alternatives: Services in the Tailscale category and zero-trust proxies like Pomerium/Teleport (auto-transcript may have errors). Core benefit: no inbound ports, better UX, reduced compromise risk.

4. Push / notification services

   • Problems:
     • Fragile notification chains and unreliable delivery; debugging notifications consumed too much time.
   • Decision: Use hosted push providers for reliability; integrate hosted push with alerting/monitoring.
   • Specifics: Uses a hosted push broker (auto-transcribed as “MailRise”) plus Pushover for device notifications. Recommends Pushover as a reliable paid option (small one-time/device fee). Notes self-hosted options exist (Gotify, Ntfy — transcript had variants like “Goify”/“Notify”).

5. Password manager (most controversial)

   • Problems:
     • High-risk: catastrophic loss or sync failure could lock him out of many accounts.
     • Backup/replication complexity and potential chicken-and-egg recovery problems (needing passwords to recover infra).
   • Decision: Use a cloud password manager for critical personal/business credentials. May keep purely lab-specific credentials on-prem if desired.
   • Notes: Acknowledges solid self-hosted projects (Vaultwarden / Bitwarden RS), but judged the operational risk/cost too high for critical secrets.

---

Services he continues to self-host

He keeps control of core infrastructure and services where local control, learning, or flexibility outweigh operational costs:

• Storage
• Internal DNS
• Identity services
• Reverse proxies
• Logging
• AI tooling
• DevOps platforms
• Other infrastructure components used for experimentation and learning

---

Decision criteria he recommends

• Measure time/stress vs learning/value: if a service consumes more time troubleshooting than the value it returns, consider moving it off-prem.
• Consider uptime and peace-of-mind when away: if a service makes you uneasy while traveling, that’s a negative signal.
• Avoid single points of failure for recovery: don’t self-host a service (like a password manager) that you’d need to recover everything else.
• Split responsibilities: keep things that benefit most from local control and experimentation self-hosted; move high-fragility or high-ops-cost services to managed/cloud.

---

Other notes

• He ran a giveaway for a Blink ST9 Max during the video (winner announced).
• Tone: Not anti-self-hosting — he still self-hosts extensively in areas he values. The emphasis is on being intentional about what to self-host versus delegate.
• Auto-transcribed product/project names may be slightly off. Possible corrections include:
  • “Twate” → Tailscale
  • “Panggalan” → Pomerium / Teleport
  • “Goify” / “Notify” → Gotify / Ntfy
  • “MailRise” → some hosted push/email broker
  • “Technidium” → Technitium

---

Source

• Brandon Lee — Virtualization How To (video summarized).