Server Manager is opinionated: every recipe and wizard writes blocks, not nginx server { } or Apache <VirtualHost> or Traefik Docker labels. That's not because the other engines are bad — nginx in particular is a fine piece of software. It's because collapses the most painful part of running a website (HTTPS) into zero config, and the others don't. If you already use nginx, Apache, or Traefik, Server Manager detects your setup and you choose: stay on it (with a small UX trade-off) or run the one-click Migrate to Caddy recipe.
What does a reverse proxy do, again?
The is the public-facing server on ports 80 (HTTP) and 443 (HTTPS). Browsers hit it; it forwards each request to the right internal app behind it — your WordPress, your web app, your API. Your apps listen on internal ports like 3000 or 127.0.0.1:8080; the reverse proxy is the front door that decides what gets routed where.
You need a reverse proxy to:
- Serve HTTPS (the padlock icon). Browsers refuse to send cookies / passwords / payments over plain HTTP these days.
- Run multiple sites on one server at different domains.
- Hide internal ports — visitors hit
https://mysite.com, nothttps://mysite.com:3000.
The four common choices
| Caddy | nginx | Apache | Traefik | |
|---|---|---|---|---|
| Automatic HTTPS (zero config) | ✅ Built-in | ❌ Needs certbot | ❌ Needs certbot | ✅ Built-in |
| Certificate auto-renewal | ✅ Built-in | certbot.timer cron | certbot.timer cron | ✅ Built-in |
| One-line reverse proxy | ✅ reverse_proxy | ❌ multi-line | ❌ multi-line | ✅ Docker labels |
| Sensible defaults (gzip, HTTP/2, TLS) | ✅ On by default | ❌ Off by default | ❌ Off by default | ✅ On by default |
| Live config reload | ✅ Yes | ✅ Yes (SIGHUP) | ✅ Yes (graceful) | ✅ Yes |
| Single static binary | ✅ Yes | ❌ Multi-file | ❌ Modules + libs | ✅ Yes |
| Config file shape | Caddyfile (terse) | server { } | <VirtualHost> + .htaccess | YAML / TOML / labels |
| Best for | "I want HTTPS to just work" | High-traffic + complex routing | Legacy PHP / .htaccess | Docker-centric stacks |
| Learning curve | Low | Medium-high | Medium-high | Medium |
| Performance at extreme scale | Good | ✅ Best | Good | Good |
The same idea in one line each:
- Caddy — "I want HTTPS to just work."
- nginx — "I need maximum throughput and have time to configure it carefully."
- Apache — "I run enterprise PHP apps with
.htaccess." - Traefik — "Everything is in Docker, label it."
Why Server Manager picked Caddy
Three reasons, in priority order:
- Automatic HTTPS is the dominant feature for non-technical users. The single biggest source of friction in deploying a small website is dealing with TLS certificates. Caddy eliminates that friction entirely. The wizard asks you to type a domain; 30 seconds later the site is live on HTTPS with a valid Let's Encrypt cert. No certbot install, no plugin choice, no renewal cron, no config edit. This is the unambiguous win and we're not willing to compromise on it.
- Sensible defaults reduce broken-site bugs. Caddy ships with gzip compression, HTTP/2, modern TLS ciphers, and sane timeouts all on by default. nginx and Apache leave most of these off — which means a real fraction of every nginx deployment ends up with subtly suboptimal config that the user never knew to fix. Caddy makes the right thing the default.
- Caddyfile syntax is approachable. Faro can write Caddyfile blocks reliably; you can read them. The equivalent in nginx requires multi-line
server { listen 80; listen 443 ssl; ssl_certificate /etc/letsencrypt/live/...; ... }blocks that are harder to scan and harder for an LLM to author accurately. Lower-friction syntax = fewer agent errors + cleaner approval reviews.
What you give up by choosing Caddy
We try to be honest about trade-offs. Caddy is not strictly better at everything.
- Maximum performance under millions of requests. nginx still has the throughput edge. For most websites this doesn't matter — the bottleneck is your backend, not the proxy — but if you're serving hundreds of millions of requests per day, nginx will use a bit less CPU.
- Niche nginx modules.
mod_lua/ OpenResty,proxy_cache_path,limit_req_zone,geoip— these are real features Caddy either does differently or doesn't have. If you rely on them, migration isn't a one-click thing. - **Apache +
mod_phplegacy.** Some old PHP apps assume Apache withmod_php(PHP runs inside the Apache process). Caddy uses PHP-FPM (separate process); same functional result, but if you have years of Apache-specific config (custom.htaccess, mod_rewrite chains), porting takes work. - Existing team familiarity. If your team already knows nginx inside out, there's a learning cost to switching. Worth it for the auto-HTTPS, but not free.
For Server Manager's target audience (small teams, hobby projects, single-server deployments), none of these usually bite. The auto-HTTPS win is what matters day-to-day.
What if I keep my current engine?
You can. Server Manager detects nginx, Apache, and Traefik and gives you two supported paths:
- Stay on your current engine. Faro configures it natively in chat:
/etc/nginx/sites-available/+certbot --nginxfor nginx, the Apache equivalent for Apache, Docker labels for Traefik. Same end result for each domain; the recipe palette marks Caddy-only flows with a 💬 via chat badge — they still work, just one extra approval click compared to the Caddy happy path. - **Migrate to Caddy** with the built-in recipe. Translates your existing config to a Caddyfile, rehearses on alternate ports while your current engine keeps serving live traffic, atomically swaps on success, auto-rolls-back on any failure. ~10 minutes; supports nginx, Apache, and Traefik.
Whichever you pick, your existing sites keep serving traffic. Migration is opt-in.
When NOT to migrate
Don't migrate to Caddy if any of these apply:
- You use OpenResty / nginx-lua or other custom-module-heavy nginx features.
- You have **complex Apache
.htaccess** rules with stackedRewriteRule [L,PT,NE]chains. - You run Traefik with custom middlewares (basic auth, rate limit, header rewrite chains) — translatable in theory but the v1 recipe doesn't auto-do it.
- You're a shared host with users you don't trust — you might rely on Apache's
mod_phpper-user isolation models that Caddy doesn't replicate.
The migration recipe's manageability check refuses to run when it detects these. But that's only about the auto-migration recipe — every other Server Manager action (deploy, install WordPress, connect a domain, manage backups, debug a slow site, restart a service) still works via the chat path on your existing engine. Faro adapts to whichever proxy is on the server. Try things; if a UI button is gated, Faro will offer to do the same work via shell commands instead.
Bottom line
Caddy isn't superior in every dimension. It's superior in the one dimension that matters most for the kind of server most Server Manager users run: automatic, reliable HTTPS in zero config. Everything else (sensible defaults, single binary, terse syntax, live reload) supports that primary win.
If you already run nginx / Apache / Traefik and your current setup is healthy, the chat path is fully supported. If you'd like the full one-click Server Manager experience, the Migrate to Caddy recipe is one button away in the of .