Open Source API Gateways Compared: Kong, Tyk, Gravitee, WSO2
Picking an API gateway usually starts with a search for "open source," and then gets complicated fast. Some projects are open source in name only, with the features a team actually needs held back for a paid tier. Others are open source end to end, with the commercial product built as a wrapper around the same code anyone can run for free. The difference matters more than most comparison pages let on.
This guide compares eight open source API gateways on the criteria that actually predict how a project will hold up in production: license terms, governance model, performance characteristics, and plugin ecosystem. It also covers where WSO2's API tools, management, and gateways fit into that landscape, since the WSO2 API Platform's API Gateway is fully open source and rarely shows up in these comparisons.
What Makes an API Gateway "Open Source"?
An API gateway is open source when its source code is published under a license (commonly Apache 2.0 or MPL 2.0) that lets anyone view, run, modify, and redistribute it without paying a vendor. That's a narrower bar than it sounds. A lot of gateways marketed as "open source" are actually open core: the base proxy is free, but rate limiting dashboards, developer portals, multi-team governance, and enterprise SSO live in a separate commercial product.
Open core isn't dishonest. It's a reasonable business model, and the open-source part of an open-core project is still genuinely open source under its license. What changes with open core is scope, not legitimacy. A team evaluating an open core gateway needs to check which features live in the free tier and which require a subscription. Only then can it judge whether the whole platform is free to run. A fully open platform, by contrast, publishes its full feature set (proxy, policies, and often governance tooling) under the same open license, even if the vendor also sells a hosted or supported version on top.
Quick Comparison Table
| Gateway | License | Core Language | Deployment Model | Best For |
|---|---|---|---|---|
| Kong Gateway | Apache 2.0 | Lua (on OpenResty/NGINX) | Self-hosted, Kubernetes, hybrid, Konnect SaaS | Teams that want a mature plugin marketplace and Kubernetes-native operations |
| Tyk Gateway | MPL 2.0 (core), separate license for the enterprise ee module | Go | Self-hosted, Kubernetes, Tyk Cloud | Go-centric teams who want a lean binary with Redis as its main external dependency |
| KrakenD | Apache 2.0 (Community Edition) | Go | Self-hosted, containers | Stateless, config-driven backend-for-frontend patterns |
| Apache APISIX | Apache 2.0 | Lua (on NGINX/OpenResty) | Self-hosted, Kubernetes | Teams that want an Apache Software Foundation project with etcd-based dynamic config |
| Gravitee | Apache 2.0 (Community Edition) | Java | Self-hosted, Kubernetes, Gravitee Cloud | Teams already invested in the JVM ecosystem needing sync and async API support |
| Envoy | Apache 2.0 | C++ | Self-hosted, Kubernetes (often as a data plane) | Service mesh and infrastructure teams building custom control planes |
| NGINX (open source) | 2-clause BSD-like license | C | Self-hosted, containers | Teams that need a proven reverse proxy and are comfortable configuring gateway behavior by hand |
| WSO2 API Gateway | Apache 2.0 | Envoy Proxy (C++) with Go and Python policies | Self-hosted, Kubernetes, hybrid, API Platform Cloud | Teams that want the gateway and its governance/control-plane tooling under one open license |
The Top Open Source API Gateways, Compared
Kong Gateway
Kong Gateway is one of the most widely deployed open source gateways, built on top of NGINX and OpenResty. Its main draw is the plugin ecosystem: hundreds of community and first-party plugins cover authentication, rate limiting, transformations, and observability, and teams can write custom plugins in Lua, Go, or JavaScript. Kong runs on bare metal, in containers, or on Kubernetes. Its Kubernetes Ingress Controller is a common entry point for teams already standardized on Kubernetes. Load balancing and health checking are built into the core routing layer. Kong Inc. sells Konnect, a managed control plane and SaaS layer, on top of the open source gateway.
Tyk Gateway
Tyk is a Go-based gateway built with a batteries-included philosophy, meaning core API management features like rate limiting, analytics, and quota enforcement ship with the base install rather than requiring plugins. It relies on Redis for distributed rate limiting and token storage, which is its main external dependency. Tyk's open source code is released under MPL 2.0. The repository also contains an ee (enterprise) directory under a separate commercial license. Check which parts of a given feature actually live in the open source tree. Tyk Self-Managed adds a management control plane, dashboard GUI, and developer portal as a paid layer on top of the free gateway.
KrakenD
KrakenD takes a different architectural approach: it's stateless and configuration-driven, with no database or persistent state to manage. That makes it a strong fit for backend-for-frontend patterns. In that pattern, a single gateway instance aggregates and reshapes calls to multiple backend services for a specific client. KrakenD Community Edition is Apache 2.0 licensed, and its low memory footprint under high concurrency is a frequently cited advantage for teams running at scale on modest infrastructure.
Apache APISIX
Apache APISIX is a Lua-based gateway that runs on NGINX and uses etcd for dynamic configuration, which means routes and policies can be updated without a reload. As an Apache Software Foundation project, its governance follows the ASF's standard model of community-driven decision-making rather than a single vendor controlling the roadmap. APISIX has one of the larger plugin counts among the projects here, spanning authentication, traffic control, observability, and serverless integrations.
Gravitee
Gravitee API Management is a Java-based gateway built to handle both synchronous REST traffic and asynchronous, event-driven APIs. That dual focus is less common among the gateways in this list. The Community Edition handles synchronous proxy APIs. Gravitee's event-native features, including the Kafka and MQTT5 endpoints for protocol mediation and the native Kafka Gateway, are part of the commercial Enterprise Edition rather than the open source tier. Gravitee's Community Edition is Apache 2.0 licensed, with the Enterprise Edition adding those event-native features plus advanced analytics and alerting.
Envoy
Envoy is a C++ proxy originally built at Lyft. It's less a turnkey API gateway than infrastructure that other gateways and service meshes build on. It is the data plane underneath projects like Istio and underneath the WSO2 API Platform's API Gateway. Teams that adopt Envoy directly are usually building a custom control plane around it rather than deploying it as a ready-made product. That makes it a better fit for platform engineering teams than for teams that want something to configure and run immediately.
NGINX (open source)
Open source NGINX is a general-purpose web server and reverse proxy, not a purpose-built API gateway. Still, teams often configure it as one, using its location blocks, the limit_req module, and Lua scripting through OpenResty. It uses a permissive 2-clause BSD-like license. The commercial NGINX Plus adds features like active health checks and a REST API for configuration. Because it wasn't designed around API-specific concerns like consumer management or usage plans, teams typically build more of that logic themselves compared to a purpose-built gateway.
WSO2 API Gateway
The WSO2 API Gateway is built on Envoy Proxy and is Apache 2.0 licensed. So is the rest of the WSO2 API Platform repository, which includes its management portal and API portal. That's a meaningful difference from most of the gateways above. With them, the free tier is the bare proxy and the governance tooling sits behind a paid product. WSO2 publishes the gateway and the console used to design, deploy, and monitor APIs under the same open license. The trade-off is a smaller third-party plugin marketplace than Kong's. WSO2 leans on built-in policies from its Policy Hub rather than a large community plugin catalog.
License and Governance: What "Open Source" Actually Means Here
Every gateway in this list carries an open source license, but the licenses aren't identical, and the license alone doesn't tell you what's actually free to use. Kong, KrakenD, Apache APISIX, Gravitee, Envoy, and the WSO2 API Platform's API Gateway are all Apache 2.0, one of the most widely adopted permissive licenses in infrastructure software. Tyk's core is MPL 2.0, a weak-copyleft license. If you distribute the software, you must provide source for modified MPL-covered files. You don't have to contribute those changes upstream or apply that rule to the rest of an application built around it. NGINX's open source distribution uses its own 2-clause BSD-like terms.
The more consequential distinction is between open source and open core. Apache Software Foundation governance keeps a project like APISIX itself free of a foundation-run commercial edition, since the ASF doesn't sell products. That doesn't mean no commercial edition exists anywhere in the ecosystem: API7, a company founded by APISIX's original creators, sells API7 Enterprise, a commercial distribution built on top of the open source project. The distinction is between the upstream project's governance and what third parties build on top of it, not an absence of commercial options. Vendor-backed projects vary the same way. Kong, Tyk, and Gravitee each publish a genuinely open source gateway, then sell a commercial control plane, dashboard, or enterprise module on top of it. That's a legitimate model, and it doesn't make the underlying gateway less open. But it means the free tier is the proxy. Governance, multi-team access control, and a polished UI are often what a team is paying for.
WSO2 draws that line differently. In the WSO2 API Platform, the gateway, the management console, and the API portal ship from the same Apache 2.0 repository. The governance layer isn't automatically a separate paid product. That's a real advantage for teams that want lifecycle management, not just a proxy, without adopting a second commercial system on day one. It doesn't mean WSO2 has no commercial offering. It means the starting point for evaluating cost is different: what ships in the open source tree, rather than what the vendor chooses to keep out of it.
Performance and Plugin Ecosystem
Performance comparisons across these gateways are hard to state as universal numbers, because throughput and latency depend heavily on hardware, plugin chain length, and traffic shape. What's more useful is understanding the architectural choices that drive performance differences. Kong, Apache APISIX, and NGINX all sit on top of NGINX or OpenResty's event-driven, non-blocking request model, which is well suited to high-concurrency workloads. The WSO2 API Gateway runs on Envoy's C++ core instead. Go and Python are used only for its policy layer, not for a separate proxy engine. So its core request handling tracks Envoy's, not a Go runtime's. Tyk and KrakenD, both written in Go end to end, benefit from Go's lightweight concurrency model without depending on an NGINX or Envoy core underneath.
Plugin ecosystem size varies more than raw performance does, and it's often the deciding factor for teams with non-standard requirements. Kong has one of the largest and most mature plugin marketplaces among the gateways here. Its plugins cover nearly every common integration and authentication scheme. It also has a well-documented path for writing custom plugins in Lua, Go, or JavaScript. Apache APISIX also ships a substantial plugin catalog as an ASF project. Tyk and Gravitee take a more batteries-included approach, building common functionality into the core rather than requiring a plugin for it. The WSO2 API Platform's policy model is close to the batteries-included approach. Most common needs (auth, rate limiting, transformations) are built-in policies from its Policy Hub. Teams can also write custom policies in Go or Python. That narrows the extension marketplace but reduces how much third-party code a team has to find and vet.
How to Choose
The right gateway depends more on team constraints than on any single benchmark. A few patterns to weigh:
- Kubernetes-native teams: If you are building on the Kubernetes Gateway API standard, look at the specific controllers that implement it. Examples include Envoy Gateway (a CNCF project distinct from raw Envoy Proxy), the Kong Ingress Controller, and NGINX Gateway Fabric. Don't assume a proxy supports the standard just because it's Kubernetes-friendly.
- Teams standardized on a specific language: Teams that write extensions often gravitate toward the gateway built in that language. Go teams lean toward Tyk or KrakenD, and Lua-comfortable teams lean toward Kong or APISIX.
- Teams that need more than a proxy: Some teams need a developer portal, multi-team API governance, versioning, and a management console. They should check whether that tooling ships in the open source tier or requires a separate commercial platform.
- Teams building for asynchronous or event-driven APIs: Teams that need event-driven APIs alongside REST will find Gravitee's dual sync/async support more directly useful than gateways built around request-response HTTP.
- Teams starting to route traffic to or from AI models and agents: Check whether the gateway has any answer for LLM traffic and Model Context Protocol (MCP) governance. That's a newer requirement most of these projects are still building out.
None of these are hard numerical thresholds. The signal to act on isn't a specific request volume or token count. It's whether the team manages multiple gateways or environments that need consistent policy enforcement. It's whether spend needs to be attributed across teams or products, or whether regulated data flows through requests. It's also whether the operation has outgrown what one engineer can manage by editing YAML files by hand.
How WSO2 Fits In
Most of the comparisons in this space treat "open source API gateway" as synonymous with "bare proxy." Evaluating WSO2 against that frame doesn't quite work, because WSO2 approaches the category differently. The WSO2 API Platform's API Gateway is an Envoy-based, Apache 2.0 licensed gateway. It's also part of a broader open source platform that includes an API Control Plane for centrally managing APIs across environments and, increasingly, across other vendors' gateways.
That control plane is where WSO2's differentiation actually shows up. AWS API Gateway, Azure API Management, Kong, and Envoy usually each come with their own console. WSO2's control plane can bring them under one governance model. It discovers their APIs, applies consistent governance rules, and gives one view across the gateways a team already runs. For AI and agent traffic, WSO2 provides an AI Gateway. Its LLM proxies govern LLM calls, and its MCP proxies govern agent access through MCP. The two flows are monitored separately under a shared governance model. AI traffic doesn't have to pass through the API Gateway as an extra hop.
The honest trade-off is the one already noted above: WSO2's plugin and extension marketplace is smaller than Kong's, and teams with unusual integration needs may find fewer ready-made community plugins to reach for. What WSO2 offers instead is a lifecycle management and governance layer under the same open license as the gateway. That matters most for teams that plan to run more than a handful of APIs. They get that governance without adopting a second, separately licensed product.
Frequently Asked Questions
What is the best open source API gateway?
There isn't a single best option. Kong fits teams that want a mature plugin ecosystem. Tyk and KrakenD suit Go-centric teams. Apache APISIX and Gravitee fit teams that want an ASF-governed project or async API support, respectively. WSO2 fits teams that want gateway and governance tooling under one open license.
Is open source API gateway software actually free?
The gateway itself is free to run under its open source license. Whether the full feature set you need is free depends on whether the project is open core. In open core projects, some governance or management features are only in a paid edition.
What's the difference between open source and open core?
An open source gateway publishes its full codebase, including governance and management features, under an open license. An open core gateway publishes the base proxy as open source but sells additional functionality, like dashboards or multi-team access control, as a separate commercial product.
How can I build my own API gateway?
Most teams don't build one from scratch. They deploy an existing open source gateway like the ones compared here and configure routing, authentication, and rate limiting policies to fit their APIs, rather than writing proxy infrastructure themselves.
Can I run more than one of these gateways at the same time?
It's increasingly common for organizations to run different gateways in different environments and manage them through a shared control plane, rather than standardizing on a single gateway everywhere.
