Caddy, Traefik or nginx: reverse proxy compared 2026
Editorial note: The information in this article was compiled to the best of our knowledge at the time of publication. Technical details, prices, versions, licensing terms, and external content may change. Please verify the information provided independently, particularly before making business-critical or security-related decisions. This article does not replace individual professional, legal, or tax advice.
Several applications behind one address, certificates included? WZ-IT sets up the access layer and operates it as part of managed operations, including certificates and 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.
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
- 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
Sources
Choose a reverse proxy and have it operated
We set up the access layer, certificates and routing and can take on ongoing operations.
Frequently Asked Questions
Answers to important questions about this topic
For most environments the question is irrelevant. All three handle the traffic of typical business applications without becoming the bottleneck. The bottleneck is almost always the application or database behind them. Where tens of thousands of requests per second genuinely occur, measure against your own traffic pattern rather than adopting published figures.
Yes, that is its core feature. Caddy requests certificates over ACME and renews them on its own as soon as a hostname is configured. With nginx this is usually handled by certbot or acme.sh as a separate process; with Traefik through a configured certificate resolver.
The source of configuration. Traefik discovers services itself, for example through Docker labels or Kubernetes objects, and builds its routing from them. Caddy and nginx are configured through files. In environments with frequently changing containers that removes a manual step.
nginx has belonged to F5 since 2019. In February 2024 long-time core developer Maxim Dounin announced a fork called freenginx following disagreements about security policy under F5's management. nginx itself continues to be released.
Caddy is under the Apache License 2.0, Traefik under MIT, nginx under BSD-2-Clause. All three are unrestricted open source. nginx additionally has a commercial variant from F5 with further features.
As soon as more than one application on a server should be reachable under its own hostname, yes. It also concentrates certificates, routing and access restrictions in one place rather than in each application separately.
Technically yes, the job is the same for all. What has to be carried over is routing rules, certificates, headers, timeouts and edge cases such as WebSocket connections or large file uploads. Those edge cases are the work, not the base configuration.
nginx validates the configuration before reloading and refuses a broken state, leaving the running service intact. Caddy behaves similarly. With Traefik, changes arise at runtime from the environment, so a wrong label takes effect immediately. That is convenient and demands care at the source.
Traefik is designed for it and is often used as an ingress controller. nginx also has a widely used implementation in the Ingress-NGINX controller. Caddy is used less often in Kubernetes.
HAProxy solves a related but different problem: it is primarily a load balancer with very fine-grained control, less a tool for conveniently publishing web applications. In environments with demanding distribution and failover requirements it sits alongside the three compared here rather than competing with them.
Written by
Timo Wevelsiep
Co-Founder & CEO
Co-Founder of WZ-IT. Specialized in cloud infrastructure, open-source platforms and managed services for SMEs and enterprise clients worldwide.
LinkedInLet's Talk About Your Idea
Whether a specific IT challenge or just an idea - we look forward to the exchange. In a brief conversation, we'll evaluate together if and how your project fits with WZ-IT.
Arrange a callback
Companies worldwide trust WZ-IT
