Several applications behind one address, certificates included? WZ-IT exposes internal and local web applications through a managed cloud gateway with reverse proxy, TLS and 24/7 monitoring. Discuss your setup
Comparisons between Caddy, Traefik and nginx usually end at throughput figures. That is understandable, because requests per second are easy to measure, and largely useless for the decision: in almost all business environments the reverse proxy is not the bottleneck. The application behind it is.
Where the three genuinely differ is where their configuration comes from and how much operational work they create after setup. That is how this article assesses them.
All figures from the repositories and vendor pages, as of August 2026.
Table of contents
- The three at a glance
- Three different assumptions
- Certificates: the most common operational cost
- Configuration: written or discovered
- Origin and governance
- Caddy
- Traefik
- nginx
- Which one for which situation
- What a throughput comparison does not answer
- How we approach this at WZ-IT
- Further guides
The three at a glance
Figures from the public repositories and vendor pages, as of August 2026.
| Proxy | GitHub stars | Licence | Current version | Released |
|---|---|---|---|---|
| Caddy | 75,159 | Apache-2.0 | v2.11.4 | 3 Jun 2026 |
| Traefik | 64,559 | MIT | v3.7.11 | 19 Aug 2026 |
| nginx | 31,477 | BSD-2-Clause | 1.30.4 stable, 1.31.4 mainline | continuous |
The nginx star count is misleadingly low. The GitHub repository is a mirror; development has historically run through its own channels, and nginx adoption far exceeds that of the other two.
Three different assumptions
The differences reduce to one sentence each:
Caddy assumes HTTPS is the normal case and nobody wants to think about it. Certificates are requested and renewed as soon as a hostname is configured.
Traefik assumes the environment changes constantly. Instead of reading files it watches Docker, Kubernetes or other sources and derives its routing from them.
nginx assumes the operator wants to specify exactly what happens. The configuration is verbose, explicit and entirely under control.
None of these assumptions is better. They suit different environments, and choosing one that does not match your situation means working against it permanently.
Certificates: the most common operational cost
The most consequential difference in practice. Over the life of an installation, certificates cause more incidents than any other property of the access layer: expired certificates, failed renewals, renewals without reloading the service.
| Proxy | Approach |
|---|---|
| Caddy | ACME built in, issuance and renewal with no extra configuration |
| Traefik | a certificate resolver is configured, then automatic |
| nginx | separate process, usually certbot or acme.sh, with its own schedule |
With nginx, certificate handling is therefore a second system with its own update path and its own failure modes. That is manageable and proven over years, but it is work that simply does not arise with Caddy.
Configuration: written or discovered
The second load-bearing difference concerns where the truth about routing lives.
With Caddy and nginx in a file. That file can be versioned, reviewed and rolled back. Both validate the configuration before adopting a new state and refuse a broken one.
With Traefik in the environment. A Docker label on a container is enough to publish a service. That saves considerable effort with many frequently changing services and shifts the care onto the container definitions: a wrong label takes effect immediately, without anyone having reviewed a configuration.
Operationally: Traefik demands discipline where containers are defined. Caddy and nginx demand discipline with configuration files. Both are workable, but they are different points in the workflow.
Origin and governance
nginx has belonged to F5 since 2019. In February 2024 Maxim Dounin, a long-time core developer, announced a fork called freenginx. The trigger was disagreement over security policy under F5's management, including the handling of a vulnerability disclosure.
That is not disqualifying for a selection, but it belongs in the assessment: nginx is led by a listed company whose decisions have already prompted a fork by core developers. nginx itself continues to ship regularly.
Caddy is developed by a small team around Matt Holt, is under Apache-2.0 and is funded in part through commercial support. Traefik is under MIT and developed by Traefik Labs, which also sells paid extensions.
For all three: the free portion is functional and not restricted through separated directories, as is seen in other areas.
Caddy
Written in Go, distributable as a single executable, configured through a Caddyfile with very terse syntax. Two lines suffice for a service with HTTPS.
The current version v2.11.4 dates from 3 June 2026. At over 75,000 stars, Caddy is the most-watched of the three projects on GitHub.
Strength: the least effort to working HTTPS. Limit: with idiosyncratic requirements the terse syntax reaches its bounds, and the volume of published solutions for edge cases is smaller than for nginx.
Traefik
Also written in Go, designed for dynamic environments. Discovers services through what it calls providers, including Docker, Kubernetes and Consul. Currently v3.7.11 from 19 August 2026, the most recent release of the three.
Strength: in environments where containers come and go, every manual step disappears. Frequently used as an ingress controller in Kubernetes.
Limit: state is distributed across the environment rather than readable in one place. Troubleshooting requires understanding the sources, not just reading a file.
nginx
The reference point the others measure against. Under BSD-2-Clause, currently 1.30.4 in the stable and 1.31.4 in the mainline branch. Configured in its own syntax, extensively documented, and for practically every edge case a proven solution exists.
Strength: maturity, predictability and the largest body of available knowledge. Anyone with an unusual problem is most likely to find an answer with nginx.
Limit: certificates are a separate process, configuration is more verbose, and dynamic environments require additional tooling.
Which one for which situation
| Starting point | Obvious choice | Reason |
|---|---|---|
| Few services, HTTPS should just work | Caddy | certificates without extra work, shortest configuration |
| Many containers coming and going | Traefik | configuration arises from the environment |
| Kubernetes cluster | Traefik or Ingress-NGINX | both established as ingress controllers |
| Unusual requirements, deep existing knowledge in the team | nginx | greatest maturity, documented for every edge case |
| Existing, working installation | keep it | switching without cause only creates risk |
What a throughput comparison does not answer
Who renews the certificates when it fails? Automatic renewal regularly breaks on changed routing, firewall rules or rate limits at the certificate authority. Without monitoring the expiry date you find out on the day it expires.
What happens on restart? Does routing come back before the applications are ready? With discovered configuration that depends on container start order.
How does the proxy behave on long connections? WebSocket connections, large uploads and long-running queries are the typical places where timeouts bite unexpectedly. These settings need adjusting on all three and are regularly forgotten.
Who updates it? The access layer sits at the network edge. An unpatched component in that position is the most exposed one an environment has.
Still unsure which tool fits? The orientation workshop sorts out your requirements and delivers a prioritised topic list with a recommendation per topic. From €1,490 excl. VAT, remote.
How we approach this at WZ-IT
We operate all three depending on the environment. For individual applications on one server we usually take Caddy, because that settles the certificate question. In containerised environments with many services Traefik prevails, and in environments already running nginx we stay with it.
What we set up regardless of the choice is monitoring of certificate lifetimes. That is the most common avoidable incident in this layer, and it announces itself well in advance if somebody is looking.
With platforms such as Coolify the choice is made anyway, because the platform brings its own proxy. That is one more reason not to consider the access layer in isolation.
Further guides
- Self-hosted PaaS compared - platforms that bring their own proxy
- Managed cloud gateway - expose internal web applications through a managed reverse proxy
- Coolify expertise - deployment platform with a built-in access layer
- Managed operations - operations including certificates and monitoring
- Managed open source - application and access layer from one team
Certificates handled manually or routing hard to follow? We bring the access layer into a state where it renews itself and is monitored. Book a call












