★ 31,919CBSD-2-Clauseupdated Oct 2026
best for a single box or CDN edge node terminating TLS in front of an app server
An event-driven worker model holds tens of thousands of connections per worker with a flat memory footprint, HTTP/2 and HTTP/3 built directly into core rather than bolted on by a third-party module, and a config language that's its own DSL but handles rate limiting and caching without reaching for extra software — this combination is what pushed nginx past thread-per-connection servers for high-concurrency work in the first place.
Some of what tutorials assume nginx handles — active health checks, session persistence, finer load-balancing control — lives behind the closed-source NGINX Plus, not this repo. Third-party modules need rebuilding against the exact nginx source after almost every minor version bump, since the dynamic module ABI isn't stable across releases. Windows support here is explicitly proof-of-concept, so if that's your target platform, look at Caddy instead.
Our full take →GitHub ↗
★ 78,216GoApache-2.0updated Oct 2026
best for developers who want HTTPS handled automatically with no config-language archaeology
Caddy's whole pitch is that you stop thinking about certificates. Point it at a domain and CertMagic handles issuance, renewal, OCSP stapling, and multi-issuer fallback underneath, so a certificate problem that would take down nginx or HAProxy doesn't take Caddy down with it. It ships as a single static binary with no runtime dependencies, and config is JSON over an API, so you can reload it without a restart and generate it programmatically.
The Caddyfile covers the common cases cleanly, but push past them and you're writing raw JSON or fighting the abstraction — there's no equivalent of nginx's decades of config recipes to copy from. Adding a plugin means recompiling the binary with xcaddy rather than dropping one in at runtime, unlike the plugin systems in Kong or APISIX. And the admin API listens on localhost with no authentication by default, fine alone on one box and a problem the moment you're not.
Our full take →GitHub ↗
★ 65,299GoMITupdated Oct 2026
best for Kubernetes or Docker setups where backends change shape and you don't want to touch a config file for it
Traefik watches your orchestrator and rewires routing the moment a container appears or disappears, with no restart and no dropped connections — the exact moment where nginx-style config reloads tend to cause a blip. Let's Encrypt certificates, including wildcards, are handled automatically, and the middleware system — rate limiting, circuit breakers, auth — is composable through labels or CRDs instead of bolted on as an afterthought.
That flexibility comes with a config surface that sprawls across TOML, YAML, Docker labels, Kubernetes CRDs, and environment variables, and mixing static and dynamic config is a common source of confusion. The plugin catalog is Traefik-hosted, so you can't just point at a community git repo the way you can with some other proxies here. The v2-to-v3 migration also broke routing syntax badly enough that the project ships a dedicated guide for it, worth knowing before building deeply on v3 today.
Our full take →GitHub ↗
★ 6,937CNOASSERTIONupdated Oct 2026
best for teams that need the most hardened raw L4/L7 throughput and are willing to learn the config DSL
HAProxy's reputation comes from two decades of production hardening most projects never get tested against: CI running across FreeBSD, NetBSD, Illumos, and multiple SSL libraries including QuicTLS and wolfSSL catches regressions other proxies simply don't check for. The Lua scripting API and SPOE engine let you extend behavior without touching the C core, and the internals documentation on schedulers and pools is detailed enough to onboard a contributor rather than leave them guessing.
The haproxy.cfg language has a steep learning curve, and ACL and stick-table errors are cryptic enough that you'll be cross-referencing docs.haproxy.org constantly — this particular repo is a bare development mirror, so the README won't orient you the way the full doc site does. Contributing means real C systems programming, not a weekend patch, and a few commercial add-ons, like device-detection integrations, ship as stubbed dummy implementations in the open-source tree, so don't expect them to work out of the box.
Our full take →GitHub ↗
★ 29,099C++Apache-2.0updated Oct 2026
best for infra teams building a service mesh or edge proxy that needs deep observability and dynamic config via xDS
Envoy's xDS API has become close to a standard in its own right — it's what Istio, Ambassador, and a long list of other meshes build on top of rather than inventing their own dynamic config protocol. The extension surface covers protocols most proxies here don't touch — Kafka, Postgres, MySQL — alongside Wasm, Lua, and Go filters, and the stats architecture and hot restart have been proven at Lyft and Google scale with real third-party security audits behind them.
None of that comes cheap to approach. The Bazel-based C++ build is slow and heavy just to get running locally, and the config surface — protos, filter chains, xDS resources — is the steepest of anything here; Traefik and Kong hide far more of this behind labels and a plugin API. If you're not already building mesh infrastructure, this is more proxy than you need.
Our full take →GitHub ↗
★ 44,288LuaApache-2.0updated Oct 2026
best for teams that want a mature API gateway with a wide plugin ecosystem and are fine writing Lua
Kong's plugin system attaches at specific request phases with a predictable execution order, and the DB-less declarative mode is the right fit for teams doing GitOps rather than clicking through an admin UI. Hybrid mode — a real separation of control plane and data plane, not a marketing label — lets you isolate config management from the traffic path, which matters more than it sounds once you're running this across a cluster.
Lua is required for anything beyond the built-in plugins, and OpenResty's dialect — cosockets, shared dictionaries — behaves differently enough from standard Lua that debugging it is its own skill. RBAC, Vault secrets, and real analytics sit behind the enterprise tier, so the ceiling on the open-source version arrives sooner than the docs suggest. And the AI gateway features are more plugins on the same nginx-based proxy rather than new LLM-aware infrastructure — fine if your traffic fits a normal request/response shape, a fight if it doesn't.
Our full take →GitHub ↗
★ 17,244LuaApache-2.0updated Oct 2026
best for platform teams who want hot-reloading gateway config via etcd without an enterprise paywall
APISIX routes and plugins hot-reload through etcd with no worker restart, which matters more in production than it sounds on paper, and the plugin count covers real needs — multiple auth schemes, several logging backends, multi-language plugin runners for Java, Go, and Python. The ai-proxy code does protocol conversion between Anthropic, Bedrock, and OpenAI-compatible APIs rather than just adding an LLM label to the same gateway, and Apache governance means a steadier release cycle than depending on one maintainer.
etcd is a hard dependency for the standard deployment, so even a small setup picks up an extra stateful service to run and watch. Like Kong, extending it means learning LuaJIT and nginx internals rather than writing Go or TOML. And the plugin directory runs past a hundred files with no clear signal of which ones are production-tested versus recently added — the AI plugins especially are new enough that you should test them yourself before trusting them in front of real traffic.
Our full take →GitHub ↗
// questions people ask
Before you choose
Can you run more than one of these together?
Yes, and it's common. HAProxy often sits at L4 in front of a layer of nginx or Envoy doing L7 work, and Envoy runs as the data plane under Istio while Kong or APISIX handles the edge as an API gateway. Running two of these for the exact same job in parallel is the pattern to avoid, not stacking them.
Which of these is fastest for raw throughput?
For pure static file serving or packet-pushing, nginx and HAProxy still lead — both are C, and both have had decades to optimize the hot path. Caddy's performance is close but trails on that specific workload, while Traefik, Envoy, Kong, and APISIX all add per-request overhead from middleware chains and dynamic config lookups that a plain reverse proxy doesn't pay.
Do I need an API gateway, or is a reverse proxy enough?
If you're routing HTTP traffic to a handful of backends, nginx, Caddy, HAProxy, or Traefik cover it without extra concepts. Reach for Kong or APISIX when you need per-route auth, rate limiting, and transformation managed as configuration rather than code spread across services — that's the specific thing an API gateway adds over a plain proxy.
What if I'm deploying on Windows?
nginx's Windows build is explicitly labeled proof-of-concept, not production-ready. Caddy and Traefik, both written in Go, run natively on Windows without that caveat and are the safer picks if Windows is a hard requirement rather than a development convenience.
If you're running a handful of servers by hand, start with nginx if you want full control over the config, or Caddy if you'd rather not think about certificates at all. If your backends live in Kubernetes and change weekly, Traefik or Envoy will save more time than any of the API gateways here, and Kong or APISIX are worth the extra complexity only once you need auth and rate limiting managed as configuration rather than code.