Self-Host

Deploy and maintain self-hosted services with security, backups, and long-term reliability.

Security Scan

This is an instruction-only self-hosting best-practices guide that is internally consistent with its stated purpose and does not request credentials or perform installs.

Purpose & Capability

The skill is a guidance document for deploying and maintaining self-hosted services; declaring that either docker or podman be available is reasonable and proportional to the topic. No unrelated binaries, credentials, or config paths are requested.

Instruction Scope

SKILL.md contains only high-level recommendations and operational best practices (backups, networking, SSL, monitoring, etc.). It does not instruct the agent to read files, access environment variables, contact external endpoints, or perform system-level actions.

Install Mechanism

No install spec or code files are provided; this is instruction-only so nothing is downloaded or written to disk by the skill itself.

Credentials

The skill requests no environment variables, credentials, or config paths. That is appropriate for an advice-only skill and avoids unnecessary access to secrets.

Persistence & Privilege

The skill is not force-included (always: false) and does not attempt to modify other skills or system settings. It also allows autonomous invocation by default, which is normal for skills and not a concern here given the instruction-only nature.

Assessment

This skill is a coherent set of self-hosting recommendations and does not request credentials or install code. It's safe from a permissions/credential perspective, but it's instructional only — following its advice may require you to run commands or change network/configuration on your own systems. Before applying any changes, back up data, review commands and compose files yourself, avoid exposing admin/UIs to the public, and use trusted releases for any software you install (pin versions and verify downloads). If you want automated scripts or installers, ask for an explicit, auditable script and review it before running.

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