Summary

George V’s introductory guide to self-hosting for beginners, covering motivation (is it right for you?), hardware choices, key concepts (reverse proxy, dynamic DNS, SSH hardening), backup strategy, Docker, and automation with Ansible. Honest about the trade-offs: self-hosting requires maintenance and tolerates downtime.

George V 針對初學者的自托管入門指南,涵蓋動機(是否適合你?)、硬件選擇、關鍵概念(反向代理、動態 DNS、SSH 強化)、備份策略、Docker 和使用 Ansible 進行自動化。對自托管需要維護並容忍停機時間的權衡持誠實態度。

Key Points

  • Self-host if: you enjoy tinkering, learning broadly, and running services at near-zero cost. Skip if: you need high reliability and hate troubleshooting
  • Hardware starting point: Raspberry Pi, old PC, or refurbished enterprise hardware; electricity cost is the main ongoing expense
  • Reverse proxy (Nginx): single ingress point routing subdomains to different services on different ports
  • Dynamic IP: use ddclient + Cloudflare (or DuckDNS/No-IP) to keep DNS records updated automatically
  • SSH hardening: key-only auth, no root login, fail2ban, no password auth (PasswordAuthentication no)
  • Backups: 3-2-1 rule; RAID is NOT a backup; use borgbackup/Duplicati + monitoring (Healthchecks)
  • Docker: containerize everything to avoid dependency conflicts; docker-compose for multi-service management
  • Automation: Ansible for reproducible server setup; author went from 2-day manual redeploy to 15-minute automated redeploy

Insights

The “should you self-host?” decision tree is honest and useful: the upside is learning + cost savings + data control; the downside is ongoing maintenance and accepting imperfect reliability. The 3-2-1 backup rule (3 copies, 2 media types, 1 offsite) and “RAID ≠ backup” are the most important operational lessons — many beginners skip backups until they lose data. The Ansible automation payoff story (2 days → 15 minutes) is a compelling concrete argument for infrastructure-as-code even on personal setups.

Connections

Raw Excerpt

If you plan on using your server for storing important data, ALWAYS have backups, it will save your skin in the long run. RAID is not a backup — mistakes happen and that’s when real backups come in handy.