Open Source API Gateway
A gateway sits on the request path ahead of everything you publish, so it reads every call before your services do, carries authentication, and becomes the single hop that can take all of your APIs down at once. That makes its routing, throttling, and token logic too consequential to run as a box you cannot inspect. Choosing from open source here means the matching, rate limiting, and authentication behavior is code you can read and test, and the edge itself runs on infrastructure you operate. The layer fronting your backends stops being a cloud dependency you cannot move, version, or reason about under load.
Traefik
HTTP reverse proxy and load balancer that configures routes dynamically from orchestrators and service registries
Kong
Cloud-native API, LLM, and MCP gateway with plugin-based traffic control
NGINX
Event-driven web server and reverse proxy that load-balances HTTP and TCP/UDP, and caches content
Envoy
Cloud-native edge, middle, and service proxy for microservices and containerized apps
Apache APISIX
Dynamic, real-time API gateway with AI proxying, load balancing, and traffic control
Tyk
Open source API gateway for REST, GraphQL, TCP, and gRPC with rate limiting, auth, and analytics
Ocelot
.NET API gateway for service-oriented systems that need a unified HTTP entry point
Kgateway
Kubernetes API gateway built on Envoy and the Kubernetes Gateway API
Envoy Gateway
Open source Envoy Proxy gateway for standalone or Kubernetes-based API traffic management
Our picks
These four span the situations most teams hit, from dynamic edges to stateless aggregation.
Best for dynamic, containerized edges: Traefik Traefik generates routes automatically by watching orchestrators and registries like Docker and Kubernetes, so services get exposed without hand-editing config. It updates configuration without restarts and provisions HTTPS through Let's Encrypt, including wildcard certificates, which fits environments where services come and go.
Best for plugin-driven policy: Kong Kong handles proxying, routing, load balancing, authentication, and health checking, and pushes most behavior into composable plugins per route. It runs natively on Kubernetes through its ingress controller and extends the same control layer to LLM and MCP traffic. Reach for it when you want a broad plugin ecosystem.
Best for multi-protocol, hot-reloaded traffic: Apache APISIX APISIX applies plugin and config changes through hot updates without restarts, and proxies TCP, UDP, gRPC, MQTT, WebSocket, and HTTP/3 beyond plain HTTP. It stays stateless, stores configuration in etcd, and doubles as a Kubernetes ingress controller. It suits mixed-protocol edge and service traffic that cannot tolerate reload downtime.
Best for stateless response aggregation: KrakenD KrakenD is stateless with no central database, so it scales out linearly and starts from declarative, version-controlled config. Beyond routing it aggregates, filters, and transforms responses from several backends into one call. Choose it for GitOps-friendly configuration and response composition rather than a stateful control plane.
What actually separates open source API gateways
Where the gateway sits in your traffic decides most of the rest. A public edge gateway in front of external APIs lives under a different latency budget and blast radius than an internal gateway routing service-to-service calls, and a Kubernetes-native gateway that speaks the Gateway API is a different animal from one that runs cleanly on plain VMs. Traefik and the Envoy-based options lean into orchestrated, dynamic environments, while NGINX and KrakenD are comfortable as standalone proxies. Be clear about whether you are replacing an ingress controller, sitting behind a cloud load balancer, or standardizing routing across several clusters.
Treat policy as the main surface, not an add-on. Gateways differ sharply in how they express authentication, rate limits, request transforms, retries, and version routing, and in whether that policy lives in declarative files, an admin API, a UI, or custom code. Kong and APISIX build around plugins, KrakenD favors declarative GitOps configuration, and Ocelot expresses everything as ASP.NET middleware. Check how policy is scoped across routes, consumers, and tenants, because a gateway that makes one-off rules easy but global policy hard turns painful once several teams publish through it.
Then weigh the operating model. Safe config rollout, zero-downtime reloads, control-plane and data-plane separation, and predictable behavior when the two lose contact matter more than any feature list. If you expect real volume, benchmark with your own headers, authentication checks, and route counts rather than hello-world routes, and confirm that routes, certificates, consumers, and policies export into a format you can keep under version control.
Related categories
Frequently asked questions
What does an API gateway actually handle, and what should it not?+
An API gateway is the routing and policy layer in front of your APIs. It typically manages request routing, TLS termination, authentication handoff, rate limits, request or response transforms, and observability hooks. It should not become where core business logic lives. Keep domain decisions in your services, and use the gateway for cross-cutting controls that need to behave consistently across many APIs.
How is an API gateway different from a load balancer?+
A load balancer mainly spreads traffic across healthy backends. An API gateway understands API-level concerns: routes, methods, consumers, tokens, quotas, and versioned endpoints. Many stacks run both, with a load balancer providing a stable entry point and the gateway applying policy before forwarding upstream. If you only need basic traffic distribution, a full gateway can add complexity you will not use.
Should a gateway replace my Kubernetes ingress controller?+
Not always. Ingress controllers are good at exposing services and basic host or path routing. Gateways add richer policy, consumer management, and authentication integration. Some teams run both, with ingress handling cluster entry and the gateway handling API rules. Options like APISIX, Kgateway, and Envoy Gateway blur the line by serving as the ingress layer themselves, so the split depends on who owns routing and whether non-Kubernetes services must be included.
How much latency does a gateway add?+
Base proxy overhead is usually small; the real cost comes from enabled policies, such as token verification, external authorization calls, logging, transforms, and rate-limit storage. Benchmark with production-like headers, TLS, authentication, and route counts, and measure tail latency rather than averages. A gateway in the hot path also needs capacity headroom, because a saturated gateway can make healthy services look broken.
How should I evaluate authentication support?+
Map your real identity flows before comparing features. Check for OIDC, JWT validation, API keys, mTLS, and token introspection as your systems require. Decide where authorization happens: a gateway can validate identity and enforce coarse rules, but fine-grained business permissions usually belong in the service. Also verify key rotation, clock-skew handling, and what happens when the identity provider is unreachable.
What separates good rate limiting from a simple counter?+
Look past a single requests-per-minute value. Useful rate limiting needs scopes such as consumer, credential, IP, route, and tenant, and stays accurate across multiple gateway replicas. Check burst handling, quota reset behavior, the headers returned to clients, and how limits behave when the backing store is slow. For paid APIs, predictable client feedback and auditability matter as much as enforcement itself.
How should I plan a migration from an existing gateway or reverse proxy?+
Treat it as policy translation, not route copying. Inventory hosts, paths, methods, upstreams, certificates, authentication rules, rate limits, and redirects, then move a small set of APIs first and compare responses, headers, status codes, and latency. Expect cleanup around overlapping routes and implicit defaults. A staged cutover using DNS or load-balancer weighting is far safer than a single switch.