What I self-host

Self‑hosting enthusiasts describe how cheap mini‑PCs, containers, and tools like Tailscale, Caddy, Home Assistant, Jellyfin, and the *arr media stack now make it practical to replace many consumer cloud services at home. They debate trade‑offs between Docker/Compose, systemd, Kubernetes and NixOS; SQLite vs Postgres; and public exposure vs VPN‑only access, with recurring concerns around maintenance burden, backups, and the “bus factor” if the primary admin disappears. Several commenters note that AI assistants have drastically lowered the complexity of setup and automation, yet many argue self‑hosting remains a hobbyist pursuit rather than a mainstream alternative to commercial platforms or to transformative technologies like AI.

Overall sentiment on self‑hosting

  • Many find self‑hosting easier and more powerful than ever, yet see it remaining a niche/hobby akin to home‑brewing or woodworking.
  • Strong appeal: control, privacy, avoiding subscriptions, better performance than some cloud services.
  • Skeptics emphasize time cost, complexity, and bus factor (what happens if the “homelab admin” is unavailable or dies).

Self‑hosting vs AI “future”

  • Several think the current AI economy is bubbly but the technology is here to stay and will matter far more than self‑hosting in the long run.
  • Others frame AI as overhyped compared to the very tangible gains from owning your stack.

Deployment: containers, systemd, and orchestration

  • Big split between:
    • Fans of single static binaries (often Go/Rust + SQLite) for simplicity and portability.
    • Fans of Docker/Podman + Compose/Quadlets/k8s for isolation, uniform management, easy upgrades, and migration.
  • Some run everything in Proxmox/LXC, k3s, NixOS or Incus; others prefer plain systemd services with sandboxing.
  • Compose files are praised as both deployment tools and concise architecture documentation.

*Media and arr stacks

  • Many defend Sonarr/Radarr/etc. as lightweight, reliable, and largely “set and forget” once configured.
  • Others see the stack as over‑engineered, fragile, and architecturally messy; several have built or are building unified, all‑in‑one replacements but hesitate to release them publicly (legal/maintenance concerns).
  • Jellyfin gets mixed reviews: great server, but client codec/HDR/subtitle issues and frame pacing problems for some; others work around this with mpv‑based clients or alternative players.

Databases and app design

  • Strong preference for SQLite for self‑hosted apps: no external services, trivial backups, lower operational overhead.
  • Counterpoint: Postgres is fine and often easier when you already have a shared instance with backups and tools; problem is each app shipping its own Postgres container.

Email, networking, and access

  • Full email self‑hosting is described as tedious, mainly due to IP reputation and deliverability, not software setup. Relays and bridges (e.g., to Proton) are common compromises.
  • Many avoid exposing services directly, instead using WireGuard/Tailscale, Cloudflare tunnels, or similar; others happily run public HTTPS with Let’s Encrypt DNS challenges.
  • Convenience for non‑technical family and external sharing (e.g., photos) remains a hard open problem.

Security, reliability, and backups

  • Concerns about exposing complex stacks (*arr, media servers) to the internet, especially in an era where LLMs lower the bar for attackers.
  • Backups commonly use tools like restic, ZFS snapshots, and off‑site or cloud storage; some separate “pet” services from more disposable “cattle” instances.