Caddy Config Generator
Generate concise Caddyfiles with automatic HTTPS, reverse proxying, and file serving.
Caddy Settings
Reverse Proxy Settings
What is this tool?
The Caddyfile Generator allows you to rapidly scaffold reverse proxies, file servers, and API gateways using Caddy—a modern, memory-safe web server written in Go.
Caddy's biggest advantage over legacy web servers is its automatic HTTPS. By default, Caddy provisions and renews SSL certificates from Let's Encrypt or ZeroSSL without requiring cron jobs or external tools like Certbot. This generator helps you harness Caddy's simplicity by creating well-structured Caddyfile configurations for static sites, reverse proxies, and load balancers.
How to Use This Tool
1. Define Site Address: Enter your domain name (e.g., example.com). Caddy will automatically bind to ports 80 and 443 and provision an SSL certificate for this domain.
2. Configure Routing: Choose whether you want to serve static files from a directory (file_server) or reverse proxy incoming requests to a backend service like a Node.js or Python application (reverse_proxy).
3. Enable Directives: Toggle features like Gzip/Zstandard compression (encode zstd gzip), request logging, or basic authentication.
4. Deploy: Copy the generated Caddyfile to /etc/caddy/Caddyfile and restart the service. Caddy handles the rest.
Best Practices
- Always use the `encode zstd gzip` directive to serve compressed responses. Zstandard (zstd) offers significantly better compression ratios than Gzip.
- If you are reverse proxying to a backend API that requires preserving the original client IP, rest assured—Caddy automatically sets `X-Forwarded-For` and `X-Forwarded-Proto` for you.
- Use format blocks (like `log { format json }`) when logging to make it easier to ingest Caddy logs into Elasticsearch or Datadog.
- Avoid running Caddy as root if possible. While Caddy needs root to bind to port 80/443, you can use capabilities (`setcap cap_net_bind_service=+ep`) to allow a non-root user to run it.
Common Mistakes
- Defining multiple site blocks without wrapping them in curly braces `{}`. If you have more than one domain in a Caddyfile, each block MUST be enclosed in braces.
- Forgetting to open ports 80 and 443 in your firewall (or AWS Security Group). Caddy requires port 80 to complete the HTTP-01 Let's Encrypt challenge.
- Putting the `file_server` directive inside a reverse proxy block. Directives must be ordered correctly, though Caddy's default directive order usually handles this automatically.
Security Notes
- Use the `header` directive to strip sensitive server information, for example: `header -Server`.
- Enforce Strict-Transport-Security (HSTS) by adding `header Strict-Transport-Security max-age=31536000;`.
- If using Caddy as a local dev server, you can use `tls internal` to make Caddy act as its own Certificate Authority and issue locally-trusted certificates.
Production Tips
- Caddy supports active health checks for load balancing. Use the `health_uri` and `health_interval` subdirectives in your `reverse_proxy` block to automatically route around degraded backends.
- Leverage Caddy's Admin API (running on localhost:2019 by default) to dynamically update configurations without editing the Caddyfile or restarting the process.
- For large configurations, use the `import` directive to split your Caddyfile into smaller, manageable snippets.
Frequently Asked Questions
Do I need to install Certbot to use Caddy?
Can Caddy act as a Load Balancer?
Is Caddy faster than NGINX?
How We Keep Your Configs Safe & Valid
Built-in Error Checking
Every file is checked against official rules. We catch missing fields and bad syntax. YAML indentation errors are flagged right away. Kubernetes, Terraform, and Docker specs are all covered. API versions and labels are verified too. You get valid output every time you generate.
100% Private & Local
All tools run in your browser only. Your API keys never leave your machine. We do not use any tracking scripts. No data is sent to any server. Passwords and secrets stay on your device. Crypto operations use the Web Crypto API. Your privacy is fully protected at all times.
Secure Settings by Default
Configs use safe defaults out of the box. Containers run as non-root users. Root filesystems are set to read-only. Dangerous Linux capabilities are dropped. Network policies limit pod-to-pod traffic. TLS 1.3 is enabled for web servers. Security headers are added where needed.
Ready for CI/CD & Git
Output files are ready for your Git repo. Use them with ArgoCD, Flux, or GitHub Actions. Files use clear formatting and comments. Code review is easy for your team. Indentation and key order are consistent. Test in staging before going to production. Every file is clean and well-structured.
Infrastructure as Code
Store configs in Git alongside your code. Terraform modules include typed variables. Backend configs support remote state locking. Outputs work across multiple modules. Ansible playbooks use clear task steps. Chef and Puppet configs are also supported. Every file works with version control tools.
Monitoring & Tracing
Set up Prometheus with auto-discovery rules. Create Grafana dashboards with template variables. Add alerting rules with severity labels. Use OpenTelemetry for trace collection. Forward logs to Loki or Elasticsearch. Connect to Jaeger or Tempo for tracing. Monitor metrics, logs, and traces together.
Container & Docker Safety
Dockerfiles use multi-stage builds for small images. Base images are pinned to exact versions. Dev files are excluded from final images. Health checks are added for orchestrator use. Containers switch to non-root users. Docker Compose uses named volumes and networks. Resource limits are set in deploy configs.
Multiple Output Formats
Export as YAML, JSON, HCL, or TOML. Kubernetes uses YAML with proper separators. Terraform uses HCL with correct escaping. JSON output has consistent indentation. Copy to clipboard with one click. Preview output with syntax highlighting. Line numbers help you review quickly.