Gentle Guide to Self-Hosting

Original Article ↗ Hacker News Discussion ↗

Practical self‑hosting setups

  • Many run services on VPSes (e.g., Hetzner, Linode) using Ansible, Docker Compose, or platform-like tools (Coolify, Cloud Seeder).
  • Others prefer home hardware: old laptops, used Dell rack servers, or NAS appliances (Synology), often with Docker or lightweight VMs.
  • Some use curated directories (awesome-selfhosted, selfhostedworld) and app‑specific tools (e.g., Miniflux with Telegram, reverse proxies, Portainer) to manage stacks.
  • DNS automation (e.g., scripts updating records when home IP changes) is common for dynamic IP connections.

Security, networking, and remote access

  • Consensus that exposed services must be updated regularly and ports minimized; SSH should avoid root login and favor keys.
  • Tools like fail2ban/crowdsec recommended to limit brute‑force attempts; some enjoy leaving SSH on 22, others avoid scans by using non‑standard ports.
  • Many advocate avoiding direct exposure: use WireGuard, Tailscale, or Cloudflare Tunnels for remote access; some prefer self‑hosted or WireGuard‑only variants for more control.
  • Tailscale praised for ease, including behind CGNAT, though bandwidth limits via DERP relays are noted.
  • IPv6 is seen as making random scanning harder today, but not a security guarantee.
  • Several suggest LAN‑only hosting or strong upstream auth (e.g., SSO in front of services) for beginners.

Debate over what counts as “self‑hosting”

  • Strong disagreement: some say only services on your own hardware in your own space qualify; others include VPS/shared hosting if you control the software and data.
  • Historical perspectives: “self‑hosting” once meant running hardware on your own line; goalposts have moved with cloud adoption.
  • New terms proposed: “home hosting,” “indie hosting,” “digital sovereignty,” “home‑running,” “on‑cloud self‑host.”
  • Key axis of disagreement: infra control vs application/data control; privacy and ToS constraints highlighted as differentiators.

Costs, providers, and trade‑offs

  • Hetzner and Oracle Cloud free tier cited as cost‑effective; Oracle’s generous free resources balanced by concerns about vendor lock‑in or “soul cost.”
  • PikaPods praised conceptually but criticized for per‑app pricing that scales poorly with many small, rarely used services.
  • Some note home servers can cost more in electricity than low‑end VPSes; others value the autonomy and learning regardless of cost.

Orchestration: simplicity vs complexity

  • Many argue Kubernetes/K3s is overkill for small homelabs; Docker (or Docker Swarm) usually sufficient, especially for single‑node setups.
  • Others enjoy k3s/k8s for education and robustness (e.g., Ceph storage surviving disk pulls).
  • Alternatives like NixOS + containers, Talos + Flux + Renovate are mentioned for reproducibility and easier patching.

Onboarding, risk, and community

  • Self‑hosting described as joyful: mix of learning, challenge, and utility.
  • Some criticize the linked article for focusing on shared hosting and for light treatment of threat modeling.
  • Recommended learning communities: /r/selfhosted, /r/homelab, /r/homedatacenter, Lemmy self‑hosted communities, and Matrix rooms focused on self‑hosting.