Gentle Guide to Self-Hosting

Original Article ↗ Hacker News Discussion ↗

Self‑hosting is portrayed as both a joyful way to learn and control your own services and a spectrum that now ranges from renting VPSes to running hardware in your home. Commenters swap practical tips on tools like Docker, WireGuard, Tailscale, Cloudflare Tunnels, and Synology NAS for safely exposing services, handling updates, and working around ISP or IPv6 constraints. A recurring tension centers on what “really” counts as self‑hosting—owning and operating your own hardware versus using third‑party infrastructure—alongside concerns about security, reliability, cost, and how much complexity hobbyists actually want to manage.

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.