Self-host n8n on a €6 VPS: Docker + Caddy with Automatic SSL - Common Pitfalls and Best Practices

This guide demonstrates a practical, cost-effective approach to self-hosting n8n: run n8n in Docker and put Caddy in front as the reverse proxy to handle automatic Let's Encrypt issuance and renewal. For small teams and agencies the setup can be complete in ~10 minutes on a modest VPS, but the write-up is valuable mainly for the list of recurring operator errors the author sees during migrations.

Why it matters: self-hosting offers control over data residency, cost predictability, and the ability to customize integrations and security controls. Using Caddy eliminates manual TLS configuration and reduces a major operational headache. For businesses that process sensitive data or want to avoid multi-tenant cloud constraints, this stack is a practical middle ground between fully managed services and bespoke infrastructure.

Common operational errors (as reported): DNS or A record misconfigurations that prevent ACME validation; insufficient PVC/volume persistence leading to workflow loss after container restarts; lax file and folder permissions that break upgrades or cause secrets exposure; and forgetting to enable monitoring/backup, so issues go unnoticed until data is lost. Addressing these requires simple, repeatable controls - validated DNS, persistent volumes, least-privilege permissions, and scheduled backups.

Actionable guidance for leaders: standardize a deployment template (Terraform, Docker Compose or Kubernetes Helm) and include an automated backup and restore playbook. Treat the VPS like an infrastructure product: patch management, monitoring (uptime, disk, memory), alerting thresholds, and periodic security reviews. If SLA or scale becomes critical, evaluate managed n8n or a higher-tier cloud instance - the low cost is attractive, but operational risk grows with client count and compliance needs.