Caddy web server for CTOs: when automatic HTTPS beats raw throughput

Caddy web server for CTOs: automatic HTTPS, reverse proxying, and the real trade-offs

Caddy 2.11.2 shipped in August 2025, and Nginx 1.30.0 shipped on April 14, 2026. Nginx still holds 32.8% web server market share, while Caddy sits below the 1% reporting threshold on W3Techs. Yet Cloudflare Radar data cited in one 2026 comparison attributes about 4% of new ACME certificate issuance to Caddy clients in August 2025, up from 1.8% in 2024. That gap tells a story CTOs should care about. Caddy wins attention where ops pain lives, not where legacy share sits. Tech-Insider comparison

Here’s my thesis. Caddy is an edge server that gives up some peak throughput to cut operational load, and that trade usually pencils out for teams under 50 engineers.

What is Caddy web server, and why do teams adopt it?

Caddy is an open-source web server and reverse proxy written in Go. Most teams run it at the edge in front of app servers, containers, or internal tools. The headline feature is automatic HTTPS via ACME, with sane defaults.

Caddy’s core building blocks look like this:

• Automatic HTTPS: Built-in ACME clients, certificate issuance on first request, renewal ahead of expiry, OCSP stapling, and HTTP to HTTPS redirects with HSTS support. Tech-Insider comparison
• Caddyfile config: A short, readable config format for common cases, plus a JSON config API for automation.
• Reverse proxy: First-class support for upstream pools, headers, retries, and transport settings.
• HTTP/3 support: Native QUIC support, which matters for some mobile and high latency paths. Onidel VPS comparison
• Runtime reloads: Hot reload without dropping connections, which helps during deploys.

The framing I use with peers is simple. Caddy is an edge product wearing a web server badge. Teams adopt Caddy to delete TLS glue and cut down the number of ways the edge can fail.

Caddy vs Nginx: performance, TLS ops, and where the real cost sits

Most CTOs I talk to start with the same question: “Is Caddy fast enough?” For most products, yes. For a few, no.

Automatic HTTPS changes the incident profile

Nginx can do ACME, but Nginx does not ship ACME. Teams bolt on Certbot, acme.sh, or a sidecar built on lego. That setup means timers, file permissions, reload hooks, and a special path for /.well-known/acme-challenge/. You can keep it under control, but the failure modes multiply. Tech-Insider comparison

Caddy flips the default. Operators put a domain name in the Caddyfile and Caddy handles issuance, renewal, OCSP stapling, and redirects. Fireship summarized the practical point in a December 2025 video quoted by Tech-Insider: “Caddy makes HTTPS the default, not a configuration choice.” Tech-Insider comparison

From a leadership angle, automatic HTTPS isn’t a convenience feature. Automatic HTTPS changes who gets paged and how often. Fewer “edge heroics” means less late-night work, and less burnout in the people you can’t afford to lose.

Throughput benchmarks show a real gap, and you need to size it

Caddy’s defaults cost something. A Swetrix reverse proxy write-up cites a benchmark where Caddy’s default setup handled 230,619 requests, while a tuned Nginx instance hit 326,510 requests. The same post reports max latency over 21,000ms for Caddy versus about 2,500ms for tuned Nginx in that test. Swetrix guide

Caddy community benchmarks also show Nginx ahead in raw requests per second in several HTTP/2 and HTTP/3 runs. One table shows Nginx at 2,224 requests per second versus Caddy at 959 requests per second for an HTTP/2 test case. Caddy community benchmarks

Peak throughput matters for a narrow set of systems:

• High RPS static delivery where you already run a CDN and still push origin hard.
• Large fan-in APIs with 1,000+ concurrent clients per node.
• Proxy chains where each hop adds latency and queueing risk.

Most SaaS products don’t live there. Most SaaS products sit around 50 to 2,000 RPS per service, with spikes, and the bigger risk comes from misconfig and expired certs, not raw proxy throughput.

A CTO’s rule: measure “ops minutes,” not just RPS

I use a simple definition with leadership teams.

Ops minutes: the number of engineer minutes per month spent keeping the edge correct, patched, and certified.

Caddy tends to reduce ops minutes by removing ACME scaffolding. Nginx tends to win on CPU and latency once you tune it hard.

A team can buy CPU.

A team can’t buy back trust after a public cert outage.

How to run Caddy as a reverse proxy in production

Caddy in front of an app server. The real production work isn’t the first reverse proxy line. The real production work is headers, health, retries, and safe reloads.

A minimal Caddyfile that ships real value

Stack Harbor’s production guide shows the smallest useful config: one host, one upstream, HTTPS terminated, and no extra moving parts. Stack Harbor guide

app.example.com {
  reverse_proxy localhost:3000
}

That config gives you TLS and redirects with almost no surface area.

Headers, identity, and audit trails

Most apps need the original host and client IP. Stack Harbor calls out passing Host and X-Real-IP upstream. Stack Harbor guide

A practical pattern:

app.example.com {
  reverse_proxy localhost:3000 {
    header_up Host {host}
    header_up X-Real-IP {remote_host}
  }
}

If your security team relies on IP allowlists, that header chain becomes part of your audit story. Put the header contract in writing and test it in staging.

Docker and multi-replica certificate coordination

Caddy shines in container fleets, but the certificate store becomes shared state. The lucaslorentz/caddy-docker-proxy project recommends multiple Caddy replicas and a shared /data volume that supports multiple mounts. The same doc notes that multiple instances coordinate certificate issuance when they share /data. caddy-docker-proxy repo

That detail matters. “Stateless edge” falls apart the moment you scale replicas without shared certificate state. Plan the storage layer early.

Wildcard certs and on-demand TLS gotchas

Coder’s docs describe a common trap. On-demand TLS can add 5 to 30 seconds on first visit to a new subdomain, since Caddy generates a new certificate. Coder recommends wildcard certificates for production, which require DNS challenges and extra modules. Coder tutorial

That delay can break user trust in a dev platform, and it can trigger false alarms in synthetic monitoring. Products that create subdomains per tenant or per workspace should plan wildcard certs from day one.

A short production checklist you can hand to your team

I call this the Caddy Edge Readiness Checklist. Print it and use it in change reviews.

• TLS mode: Decide on per-host ACME, wildcard DNS-01, or internal PKI.
• Certificate storage: Use shared /data for replicas, and back it up.
• Header contract: Set Host, X-Real-IP, and X-Forwarded-* rules, then test.
• Health behavior: Define upstream health checks and failure handling.
• Reload path: Pick API reload or service restart, and prove zero downtime.
• Logging: Standardize JSON logs and ship them to your SIEM.
• Rate limits: Add basic abuse controls at the edge, not in app code.

Teams that follow that list avoid the common “it worked on a VPS” failure.

Enterprise implications: what changes for CTOs

Caddy looks like a web server choice, but the choice changes how teams ship and how teams fail.

1. Certificate risk moves from “process” to “product behavior.”
   Caddy’s automatic HTTPS reduces the number of manual renewal paths. That shift lowers the chance of an expired cert incident, and it reduces the need for a dedicated “TLS owner.” The Cloudflare Radar data point cited by Tech-Insider, 4% of new ACME issuance tied to Caddy clients in August 2025, signals real adoption of that model. Tech-Insider comparison

2. Shadow deployments get easier, so governance must tighten.
   A single engineer can expose an internal tool with one Caddyfile stanza. Speed helps, but unreviewed public endpoints pile up fast. Pair Caddy adoption with an edge inventory in our Command Center tool at /command-center, so you can track domains, certs, and owners.

3. Performance conversations become more honest.
   Benchmarks show tuned Nginx can beat Caddy on raw RPS and tail latency. Swetrix guide Caddy community benchmarks
   That gap forces a useful question. Are you CPU-bound at the edge, or are you change-bound in ops? Most orgs are change-bound.

4. Edge ownership becomes a leadership decision, not a config decision.
   Caddy’s simplicity tempts teams to let every squad own its own edge. That model breaks once you have 30+ services and shared auth patterns. A platform team should own the edge templates, and product teams should own routes and upstreams.

CTO recommendations: how to decide, deploy, and lead the change

Most teams don’t need a religious war between Caddy and Nginx. Teams need a decision rule, a safe rollout plan, and a named owner.

Immediate actions

1. Pick one production slice: Put Caddy in front of one internal tool, like Grafana.
   Use a real domain, real TLS, and real monitoring. Track ops minutes for 30 days.

2. Run a proxy benchmark that matches your traffic: Test with your payload sizes.
   Use your auth headers, your upstream timeouts, and your concurrency. Compare p95 and p99 latency, not just RPS. Use the Engineering Metrics Dashboard at /tools/engineering-metrics-dashboard to track deploy frequency and change failure rate during the rollout.

3. Eliminate cert glue: Remove Certbot timers and reload hooks in that slice.
   The goal isn’t “Caddy runs.” The goal is “the cert pipeline disappeared.”

Policy framework

1. Edge ownership: Name a single team for edge templates and security defaults.
   Product teams can request routes. Platform teams own the base config.

2. Domain and certificate policy: Require an owner for every hostname.
   Put the owner in DNS as metadata, or in your service catalog. Tie it to on-call.

3. Change control for public endpoints: Require review for new hostnames.
   Caddy makes exposure easy. Your policy has to make exposure deliberate.

If you want a lightweight governance tool, model edge components in our ArchiMate Modeler at /tools/archimate. A simple view of “domains to proxies to upstreams” pays off during incidents.

Architecture principles

1. Prefer one edge per environment: Run one shared edge per cluster or VPC.
   That pattern reduces duplicated config and makes WAF and auth consistent.

2. Keep the edge stateless, except for certificates: Treat /data as state.
   Back up certificate state and test restore. The caddy-docker-proxy guidance about shared /data exists for a reason. caddy-docker-proxy repo

3. Avoid proxy chains: Keep hops under two.
   Swetrix warns about chained proxies and performance. Swetrix guide
   Put auth at the edge, then route to the app. Don’t stack three proxies.

A decision matrix you can reuse in exec reviews

I use this Edge Server Fit Matrix with leadership teams. Score each row 1 to 5.

Use the Build vs Buy Matrix at /tools/build-vs-buy-matrix as a companion. The real choice isn’t Caddy vs Nginx. The real choice is “own edge complexity” vs “buy simplicity with defaults.”

Bigger picture: Caddy is a leadership tool disguised as infrastructure

Caddy’s rise tracks a broader shift. Teams want fewer bespoke scripts and fewer snowflake servers. Teams also want safer defaults, since security teams now audit everything from TLS versions to header handling.

Caddy also fits the talent market. Senior infra engineers still love Nginx, but plenty of product engineers can read a Caddyfile and ship a fix. That matters when teams span time zones and you can’t depend on one edge expert.

The catch is governance. A tool that makes exposure easy can create a long tail of public endpoints with unclear owners. The open question for your org is simple: do you want speed at the edge without losing control, and who has the authority to say “no” when a new hostname shows up at 6 p.m.?

Internal links for deeper work:

• Read our guide to incident postmortems that improve systems and trust at /tools/incident-postmortem.
• Use Command Center for tech portfolio and risk tracking at /command-center.
• See our piece on platform teams as internal product teams (The Art of CTO) at /platform-teams-internal-products.
• Review our guide on SLOs and error budgets for leadership teams (The Art of CTO) at /slos-and-error-budgets-for-leaders.

Sources

1. Caddy vs Nginx 2026: 22% Speed Gap, 32.8% Market Share
2. Caddy vs Nginx on VPS in 2025
3. Caddy as a reverse proxy in production
4. Caddy Reverse Proxy A Practical Guide (Swetrix)
5. Use Caddy as a Reverse Proxy (Coder docs)
6. GitHub: lucaslorentz/caddy-docker-proxy
7. Caddy v2 HTTP/2 and HTTP/3 Benchmarks (Caddy Community)