Engineer Yusuf Seyitoğlu compared NGINX, Caddy and Traefik for six weeks on the same Kubernetes cluster, running twelve microservices and handling real traffic for a logistics company. NGINX clearly won on performance, Caddy used the least memory, and Traefik was ultimately chosen for most of the traffic for a less eye-catching reason: it reduced the time the team spent publishing and maintaining routes.
The key facts about the proxy comparison in 20 seconds
- NGINX delivered the highest throughput, at around 46,000 req/s.
- Caddy stood out for lower memory use and automatic TLS management.
- Traefik was the slowest, but cut standard route setup time to around four minutes.
- The retirement of ingress-nginx is forcing many companies to choose a replacement.
- The results come from one specific environment and should not be treated as universal.
The test is useful because it did not consist of running a synthetic benchmark for a few minutes. Each alternative spent two weeks handling REST APIs, WebSocket connections and CSV exports ranging from 15 to 40 MB. The environment averaged approximately 35,000 requests per minute, with declared peaks of 61,000, behind an AWS Network Load Balancer deployed across three availability zones.
Even so, the figures should be read as a practical case study rather than a definitive ranking. The original article does not provide all the scripts, configurations, CPU models or full result sets required to reproduce the test independently. There is also an apparent inconsistency in some of the published units: 61,000 requests per minute equals roughly 1,017 requests per second, so Traefik’s reported 36,000 req/s would represent more than 35 times that peak, rather than the threefold headroom claimed in the source text.
The same cluster for three different operating models
The comparison was performed on Amazon Elastic Kubernetes Service (EKS) with twelve services. All three proxies received the same resource requests, two CPUs and 2 GiB of memory per replica, and had to meet the same requirements for encryption, rate limiting and observability.
| Test element | Configuration |
|---|---|
| Platform | Amazon EKS |
| Applications | 12 microservices |
| Declared average traffic | 35,000 requests per minute |
| Declared peak traffic | 61,000 requests per minute |
| Traffic types | REST JSON, WebSocket and CSV downloads |
| Export size | Between 15 and 40 MB |
| Resources per replica | 2 CPUs and 2 GiB of memory |
| Front-end load balancer | AWS NLB across three zones |
| Certificates | ACME and cert-manager |
| Metrics | Prometheus |
| Duration | Two weeks per alternative |
| Route changes measured | 14 |
The schedule began with F5 NGINX Ingress Controller as the baseline. During the following two weeks, Caddy was tested through a parallel ingress class, including an internal HTTP/3 comparison. Traefik occupied the final stage, initially with non-critical services and later with a gradual traffic split.
There is an important distinction in the product names. The community kubernetes/ingress-nginx project, used for years in many clusters, ended maintenance in March 2026. Its official repository has been archived and will receive no further releases, bug fixes or security updates. Existing deployments do not suddenly stop working, but the risk of keeping them exposed increases over time.
That project is not the same as NGINX Ingress Controller, maintained by NGINX and F5. The latter remains active, uses NGINX or NGINX Plus and offers commercial support. The test used this F5 implementation, not the retired community controller.
Performance and resource comparison
| Observed metric | NGINX F5 NIC | Caddy | Traefik |
|---|---|---|---|
| Throughput with 2 KB JSON | 46,000 req/s | 41,000 req/s | 36,000 req/s |
| Difference versus NGINX | Baseline | −10.9% | −21.7% |
| Reported p99 overhead | 0.9 ms | 1.2 ms | 1.6 ms |
| Idle memory | 35 MB | 28 MB | 48 MB |
| Memory with 10,000 connections | 120 MB | 95 MB | 135 MB |
| Standard route setup | 23–25 min | 8–9 min | 4 min |
| First route setup | Not stated | Not stated | 38 min |
| Monthly cost for three replicas | $186 | $142 | $198 |
NGINX was approximately 12.2% faster than Caddy and 27.8% faster than Traefik when the comparison is calculated from the other products’ results. It also recorded the lowest additional latency at the 99th percentile.
That difference matters for services terminating enormous volumes of connections, delivering very large files or operating close to available capacity. In the environment tested, however, all three products provided substantial headroom over normal traffic, assuming the published units are correct.
Caddy ranked second with 41,000 requests per second. It consumed the least memory both at idle and with 10,000 concurrent connections. Its estimated monthly infrastructure cost was also the lowest, although the gap between the three products was only $56 and depended on the exact AWS pricing and resource allocation.
Traefik came last in throughput and used the most memory. In exchange, a new route took about four minutes once the team had established its conventions, compared with more than 20 minutes for the NGINX process based on YAML files, annotations and pull request review.
The first Traefik route took 38 minutes. This figure reveals something quick comparisons often miss: automation reduces work after naming standards, labels, entry points, middleware and permissions have been defined. Reaching that point requires an initial investment in design and documentation.
NGINX wins the benchmark, but Traefik wins daily operations
The main conclusion from the test is that the proxy handling the most requests per second is not necessarily the cheapest one for the organisation. Monthly compute costs were relatively similar, while operator time showed larger differences.
The team estimated that Traefik saved around six hours per month compared with NGINX for routine route changes. Based on the labour costs used in the project, that reduction was worth about $900 per month.
| Observed operating cost | NGINX | Caddy | Traefik |
|---|---|---|---|
| Time per route | 23–25 min | 8–9 min | 4 min |
| Monthly compute cost | $186 | $142 | $198 |
| Hours saved versus NGINX | Baseline | Not quantified | Around 6 hours/month |
| Estimated financial saving | Baseline | Not quantified | Around $900/month |
| Main advantage | Performance and maturity | Simplicity and TLS | Kubernetes integration |
That estimate cannot be transferred directly to another company. A team that rarely modifies routes will not recover the migration effort through those savings. Another organisation deploying services every day could see a much larger difference.
NGINX retained a familiar advantage during reloads. When an invalid configuration was introduced, it rejected the change and continued running with the previous version. This can be inconvenient in a continuous integration pipeline, but it also prevents a syntax error from immediately taking down the production proxy.
Caddy removed much of the complexity associated with certificate management. The project enables automatic HTTPS by default, can obtain and renew certificates through ACME and supports HTTP/1.1, HTTP/2 and HTTP/3. It also accepts dynamic configuration through a JSON API.
That simplicity does not eliminate all Kubernetes work. When several replicas are deployed, certificate storage, persistence and renewal coordination still need to be designed. Caddy is very straightforward on a single machine or in a small environment, but a distributed deployment still requires architecture.
Traefik fitted the cluster’s rate of change better. It watches Kubernetes resources and converts events, labels and custom objects into dynamic configuration. This removes many manual reloads, but it also increases the consequences of an incorrect label.
During the test, a mislabelled pod received public traffic for eleven minutes. The problem was not a proxy failure, but an insufficiently defined convention. The automation did exactly what the configuration instructed, although that was not what the team intended.
Traefik 3.7 also includes a provider designed to interpret ingress-nginx annotations. This feature can accelerate migration because it translates existing rules into Traefik routers, services and middleware. It does not provide identical compatibility: the documentation warns of differences in buffering, forwarded headers and behaviour previously controlled through the NGINX ConfigMap.
A 30-second timeout that looked like a proxy failure
The most visible incident appeared during the gradual cutover to Traefik. The new controller was handling 60% of traffic when several users began downloading large CSV files.
A proxy-read-timeout annotation had been set to 30 seconds, even though some exports required around 42 seconds at the 99th percentile. Both the old controller and Traefik’s compatibility layer respected the configured value. Connections were closed and the error rate rose from 0% to 8% within three minutes.
Support initially blamed the new proxy, while the development team suspected the application had become slower. The cause was simpler: the inherited timeout was unsuitable for that workload. The immediate fix was to raise it to 300 seconds, while asynchronous exports were added to the longer-term roadmap.
The migration also exposed a second issue. The Layer 4 load balancer in front of the cluster had not been correctly included among the trusted sources for forwarded headers. Traefik therefore logged the wrong client address, causing some mobile users to share the same rate-limiting bucket.
Configuring X-Forwarded-For is a security issue, not merely an observability detail. Trusting every source allows a client to forge its address. Failing to trust the correct load balancer means the proxy sees the balancer’s IP instead of the user’s.
The investigation also found that the nf_conntrack table had reached 92% utilisation on two nodes because of the long-running downloads. Changing proxies would not have resolved that kernel limit. The case shows why a 502 error may originate from the controller, the application, the load balancer, a timeout or the node’s connection-tracking capacity.
Which proxy fits each environment?
| Situation | Most reasonable choice | Reason |
|---|---|---|
| Very high traffic with maximum performance as the priority | NGINX | Highest throughput and lowest p99 in the test |
| Very large files or intensive streaming | NGINX | Extensive buffer and streaming controls |
| Experienced team with F5 support | NGINX F5 NIC | Operational continuity and existing expertise |
| Few services and stable routes | Caddy | Simple configuration and low resource use |
| Automatic TLS with little administration | Caddy | Integrated HTTPS and renewal management |
| HTTP/3 and ECH as requirements | Caddy | Built-in support in the official distribution |
| Kubernetes with frequent service changes | Traefik | Dynamic discovery and configuration |
| Urgent migration from ingress-nginx | Traefik | Partial compatibility with existing annotations |
| Routes created continuously by several teams | Traefik | Less manual work after conventions are defined |
| Different requirements within the same platform | Hybrid architecture | Each proxy can handle a different traffic profile |
The company in the test did not end up using a single option. Traefik took over most Kubernetes traffic because it simplified daily operations, while NGINX remained on a dedicated path for CSV exports, where streaming and buffer tuning delivered more value. Caddy was left out of the primary environment, although the author kept it in his staging infrastructure because of its simplicity.
That hybrid outcome is probably the most useful conclusion. NGINX, Caddy and Traefik solve similar problems, but they begin with different priorities. NGINX provides control and performance; Caddy reduces server and TLS administration; Traefik follows service changes inside Kubernetes.
The best choice does not depend only on how many requests each product can process per second. It also depends on how long a team takes to publish a route, what happens when a configuration is wrong and how much expertise is required to diagnose an outage in the middle of the night.
Frequently asked questions
Which proxy was the fastest in the test?
NGINX reached around 46,000 req/s, compared with 41,000 for Caddy and 36,000 for Traefik. The results come from a specific test using 2 KB JSON responses and do not represent every environment.
Why was Traefik chosen if it was the slowest?
The real traffic level was far below its maximum capacity, and the team placed greater value on reducing route configuration time. Traefik took over most of the cluster, while NGINX retained the large-file traffic.
Has NGINX for Kubernetes been discontinued?
The community kubernetes/ingress-nginx project ended maintenance in March 2026. NGINX Ingress Controller from NGINX and F5 is a separate project and remains active.
Can Traefik import every ingress-nginx annotation?
Traefik 3.7 includes a compatibility layer that recognises many annotations, but it does not reproduce every behaviour. ConfigMap settings, buffering, headers and middleware must be reviewed before migration.
Sources:
- Six-week comparison of NGINX, Caddy and Traefik conducted by Yusuf Seyitoğlu.
- Official ingress-nginx repository, retirement notice and end of updates in March 2026.
- Official Traefik 3.7 documentation on ingress-nginx annotation compatibility and configuration differences.
- Official NGINX Ingress Controller repository, maintained separately from the retired community project.
- Official Caddy repository, covering automatic HTTPS, dynamic API configuration, ECH and HTTP/3.