Caddy Config Generator
Create concise, automatic-HTTPS Caddyfiles for reverse proxies and file servers.
Caddy Settings
Reverse Proxy Settings
Configuration Health
Detailed Analysis
Best Practice Analysis
Production Readiness
Overview
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 It Works
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 Recommendations
- 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.