self-hosting（自托管）

Self-Hosting Rules

Before Installing Anything

• Backups first — decide where data lives and how it's backed up before deploying, not after data exists
• Check resource requirements — many services need more RAM than expected, OOM kills corrupt data
• Verify the project is actively maintained — abandoned projects become security liabilities

Docker Fundamentals

• Always use named volumes or bind mounts for persistent data — anonymous volumes are lost on container removal
• Pin image versions (nginx:1.25.3 not nginx:latest) — latest changes unexpectedly and breaks setups
• Set restart policy (unless-stopped or on-failure) — containers don't auto-start after reboot by default
• Use docker compose down not docker compose rm — down handles networks and volumes properly

Networking

• Never expose database ports to the internet — only the reverse proxy should be public
• Use a reverse proxy (Traefik, Caddy, Nginx Proxy Manager) — handles SSL, routing, and security in one place
• Create Docker networks per project — default bridge network lacks DNS resolution between containers
• Bind admin interfaces to localhost only (127.0.0.1:8080:8080) — not all traffic needs to be public

SSL and Domains

• Use automatic SSL with Let's Encrypt — Caddy and Traefik do this natively
• For local/LAN access, use a real domain with DNS challenge — avoids browser certificate warnings
• Wildcard certificates simplify multi-service setups — one cert for *.home.example.com

Security Essentials

• Change all default passwords immediately — bots scan for default credentials within hours
• Enable automatic security updates for the host OS — unpatched systems get compromised
• Use fail2ban or equivalent — brute force attacks are constant
• Keep services behind authentication (Authelia, Authentik) — not everything has built-in auth
• Disable root SSH, use key-only authentication — password SSH is a vulnerability

Backups

• Test restores, not just backups — untested backups are wishful thinking
• 3-2-1 rule: 3 copies, 2 different media, 1 offsite — local RAID is not backup
• Automate backup schedules — manual backups get forgotten
• Back up Docker volumes, not containers — containers are ephemeral, data is not

Monitoring

• Set up uptime monitoring (Uptime Kuma is self-hostable) — know when services die before users tell you
• Monitor disk space — full disks cause silent failures and corruption
• Log rotation is mandatory — Docker logs grow forever by default, fill disks
• Consider resource monitoring (Netdata, Prometheus) — spot problems before they're critical

Maintenance

• Schedule regular update windows — services need updates, plan for downtime
• Document everything you deploy — future you won't remember why that container exists
• Keep a compose file repo — reproducibility matters when hardware fails
• Test updates on staging when possible — production surprises are painful

Home Server Specifics

• Dynamic DNS if ISP doesn't provide static IP — Cloudflare, DuckDNS work well
• UPS protects against power loss corruption — especially important for databases
• Consider power consumption — some hardware costs more in electricity than cloud hosting
• Port forwarding exposes your home network — use VPN (WireGuard, Tailscale) instead when possible

Common Mistakes

• Putting everything on one machine with no redundancy — single point of failure for all services
• Ignoring updates for months — security vulnerabilities accumulate
• No firewall rules — assuming "nobody knows my IP" is security
• Storing secrets in docker-compose.yml committed to git — use .env files, exclude from version control
• Over-engineering from day one — start simple, add complexity when needed