Which API gateway fits which team: Apache APISIX vs Kong vs Tyk
If your team must self-host an API gateway and needs OIDC, AI or MCP features, the first question is not which gateway is fastest but which license boundary your organization can accept. Each of the three options draws that line in a different place, and the right choice follows from it. Apache APISIX is the fit when you want Apache-2.0 licensing across the gateway and its plugins, with configuration held in etcd or in files. Kong is the fit when the open source line is acceptable as a base and you are prepared to move OIDC and newer releases into Kong Gateway Enterprise. Tyk is the fit when an MPL-2.0 gateway is acceptable but the Dashboard, Developer Portal and Operator are budgeted as commercial licenses.
Start by mapping your required features to those boundaries. The Kong/kong repository is Apache-2.0 and its releases stay on the 3.9 line, while Kong's OpenID Connect plugin is marked as an Enterprise tier plugin, so OIDC is not part of the open source gateway. The APISIX openid-connect plugin is part of the Apache-2.0 project, and its documentation lists Keycloak, Microsoft Entra ID and Okta among supported identity providers. Tyk Gateway code is MPL-2.0 except the ee folder, and the Tyk README places the Dashboard and Operator under license. Confirm in writing which of your specific AI or MCP controls sit in each open tier, since the README descriptions alone do not settle that for every feature you need.
Apache APISIX vs Kong vs Tyk by scenario
This table maps common gateway situations to the platform that fits each one best, with the reason and the condition under which another option would be the better choice. Read each row against your own licensing budget, deployment model and existing stack, then confirm license terms with each vendor before you commit.
| Scenario | Best fit and reason | Choose another platform when |
|---|---|---|
| OIDC login at the gateway without a paid tier | Apache APISIX: its openid-connect plugin is part of the Apache-2.0 project and supports authorization code, client credentials, introspection and PKCE flows. | Your identity provider needs a flow APISIX does not cover in your tests, or you already buy Kong Enterprise and want its supported OIDC plugin. |
| Configuration stored in etcd or a database | Apache APISIX: traditional and decoupled modes keep configuration in etcd, while standalone mode uses a YAML or JSON file or API instead. | You want PostgreSQL as the configuration store, where Kong's traditional mode with a database fits better, or your team has no etcd operating experience. |
| Kubernetes ingress | Kong: its Kubernetes ingress controller is listed in the open source README, and DB-less or hybrid topologies suit declarative cluster use. | Your team prefers APISIX's own ingress controller (APISIX Ingress Controller 2.2.0, released August 18, 2026) or already runs APISIX in other environments. |
| MCP or AI gateway use | Kong or Tyk: the Kong README lists LLM and MCP gateway features, and Tyk describes its gateway as supporting MCP alongside REST, SOAP, GraphQL and gRPC. | You need AI gateway functions from the APISIX plugin catalog, which covers AI gateway functions per its documentation; confirm specific AI features against your use case. |
| Redis-based stack | Tyk: the open source Tyk Gateway runs with Redis, so it fits a team that already operates Redis and wants no etcd or PostgreSQL dependency. | You want APISIX's etcd-backed model or Kong's PostgreSQL traditional mode, or you need the Tyk Dashboard, which requires a license. |
| Team already running Kong Enterprise | Kong: staying on Kong Gateway Enterprise keeps one topology, one support window and Kong Manager or Konnect across environments. | Your budget or support window no longer fits Enterprise, or you want the open-source Apache-2.0 APISIX plugin set without an upgrade path tied to Kong. |
| Dashboard and developer portal required | Tyk or Kong: both offer a management interface, but Tyk's Dashboard and Developer Portal are part of its commercial self-managed platform, while Kong Manager and Konnect are product offerings to confirm with Kong. | You want a fully open-source stack, since APISIX's dashboard and portal layers should be confirmed separately in its documentation before you rely on them. |
How configuration storage changes day-to-day operations
Configuration storage decides which stateful systems your team backs up, upgrades and monitors. APISIX in traditional and decoupled modes keeps routes, upstreams and plugin settings in etcd, and its standalone mode drops etcd entirely and reads conf/apisix.yaml or conf/apisix.json, or accepts configuration through an API. Kong offers a database-backed traditional mode, a DB-less mode that holds configuration in memory, and a hybrid mode with separate control and data planes. Tyk's open source gateway runs with Redis, which holds its runtime state, while the Dashboard and PostgreSQL that appear in the full Tyk Self-Managed stack require a license. Count the stores each option adds before comparing feature lists.
Backups and GitOps follow from that choice. An etcd cluster, a PostgreSQL database or a Redis instance needs its own backup and restore test, while a file-driven APISIX standalone deployment or Kong DB-less configuration can be kept in Git and reviewed as a diff before it reaches production. In file-driven APISIX, the gateway checks the file every second and hot-reloads it, so a bad merge reaches live traffic quickly. Ask your team which change review gate applies to each path, and whether a rollback means restoring a database or redeploying a file.
Confirm these points in your own environment and with each vendor before you commit: which storage you must operate for the edition you need, whether the Admin API or Kong Manager is available in the topology you pick, how the Tyk Dashboard and Operator licensing applies to GitOps workflows, and how your cluster size affects etcd or Redis sizing. Apache APISIX deployment modes documents the APISIX options, and Kong Gateway deployment topologies covers Kong's three self-managed topologies.
Apache APISIX vs Kong vs Tyk capability by capability
This table compares protocols, authentication, plugin languages and Kubernetes support across the three gateways, with each cell marked as supplied from documentation or as something to confirm in a proof of concept. Read it as a starting checklist: a gap in one column is often a gap in what the README or docs state, not proof the feature is missing. The main takeaway is that the three gateways overlap heavily on core proxying and JWT-style authentication, so the decision usually turns on OIDC placement, plugin language fit and the commercial components you need.
| Capability | Apache APISIX | Kong Gateway | Tyk Gateway |
|---|---|---|---|
| Protocols listed in project docs | HTTP, HTTPS, HTTP/3 with QUIC, gRPC, WebSocket, MQTT, Dubbo, TCP/UDP (supplied) | Routing and proxying per README; LLM and MCP gateway features listed (supplied); confirm protocol matrix for your version | REST with native OpenAPI, SOAP, GraphQL, gRPC, TCP and MCP (supplied) |
| OpenID Connect support | openid-connect plugin in open source, working with Keycloak, Auth0, Microsoft Entra ID, Google and Okta; authorization code, client credentials, introspection and PKCE flows (supplied) | OpenID Connect plugin is an Enterprise tier plugin, not part of open source (supplied); confirm licensing before design | Open source gateway lists JWT and bearer tokens; confirm OIDC flow coverage and whether it needs the Dashboard or licensed components |
| Token and basic authentication | Supported through plugins; confirm the exact plugin set for your version | JWT, basic auth, OAuth and ACL in the open source README (supplied) | JWT, bearer tokens, Basic Auth and client certificates (supplied) |
| Plugin languages | Lua inside workers; external plugin runners for Java, Go and Python; WebAssembly is experimental (supplied) | Plugins written in Lua, Go or JavaScript (supplied) | Middleware plugins in Python, JavaScript, Go or any gRPC-capable language (supplied) |
| Built-in plugin breadth | More than 100 built-in plugins covering authentication, security, traffic control, observability and AI gateway (supplied) | Routing, load balancing, health checks and auth in README; confirm full plugin catalog and tiers | Rate limiting, quotas, API versioning, per-operation access control and IP allowlisting (supplied); confirm plugin count |
| Kubernetes support | Separate APISIX Ingress Controller, version 2.2.0 released August 18, 2026 (supplied); confirm Gateway API coverage | Kubernetes ingress controller listed in README (supplied); confirm Gateway API and Konnect fit | Tyk Operator for declarative management requires a license; tyk-oss Helm chart installs the open source gateway (supplied) |
| Management interface | Admin API on port 9180 in traditional mode (supplied); dashboard options to confirm for your edition | Kong Manager web interface and Konnect cloud control plane (supplied) | Tyk Dashboard and Developer Portal are part of the licensed self-managed platform (supplied) |
| Commercial-only components | Vendor support and enterprise offerings come from third parties such as API7.ai; confirm scope | OIDC and newer releases sit in Kong Gateway Enterprise (supplied) | Dashboard, Developer Portal, Tyk Pump and Operator need a license (supplied) |
Which features sit behind a license in each gateway
Apache APISIX is an Apache-2.0 licensed project, and its documentation describes more than 100 built-in plugins covering authentication, security, traffic control, observability and AI gateway functions. The gateway itself and these plugins are presented as open source, so the license question for most teams is whether a specific feature or companion product sits outside that scope. The Ingress Controller follows its own release track, which matters for Kubernetes teams that pin versions.
- Plugin catalog: The plugins are documented on the project site, but confirm that each one on your list is in the Apache-2.0 distribution you plan to deploy.
- Ingress Controller: APISIX Ingress Controller 2.2.0 was released on August 18, 2026, while the gateway's 3.19.0 was released on September 28, 2026. Record both versions in your change process.
- Release support: The APISIX downloads page does not mark any release as long-term support, so there is no published LTS window to plan against. Ask for the maintenance policy for the branch you choose.
- OIDC: The openid-connect plugin works with Keycloak, Auth0, Microsoft Entra ID, Google and Okta, and supports authorization code, client credentials, token introspection and PKCE flows. Confirm that your identity provider and flow are covered in the version you deploy.
- Commercial companion: API7 Enterprise is a commercial product from API7.ai built on APISIX. Features it adds are outside the open source project, so price it separately if your requirements point there.
Check that every plugin and flow you need appears in the open source distribution, and ask the project or API7.ai in writing which features, if any, are gated.
Kong's open source repository is Apache-2.0 licensed, but its releases stay on the 3.9 line, while newer versions ship as Kong Gateway Enterprise. The OpenID Connect plugin is marked as an Enterprise tier plugin, so it is not part of the open source gateway. Plan around two lifecycles: the open source line and the Enterprise release track with its LTS windows. The Kong Gateway version support policy sets out the dates.
- Open source line: The Kong/kong releases stay on 3.9, with 3.9.3 released on June 17, 2026 and 3.9.4 released on October 12, 2026. Ask Kong which fixes the open source line will receive after its support ends.
- 3.9 support dates: Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026. Any 3.9 deployment needs an upgrade path before the second date.
- Enterprise releases: Kong Gateway (Enterprise) 3.16 is the latest version, released on September 15, 2026. The LTS releases 3.10 and 3.14 are supported until March 31, 2028 and April 7, 2029.
- Management and identity: Kong Konnect, the cloud control plane, and Kong Manager, the web interface, should be checked feature by feature. The supplied sources do not settle which of their parts run in the open source gateway.
- Topologies: Traditional, DB-less and hybrid modes are documented for self-managed use. Confirm whether hybrid mode or any other topology needs an Enterprise license.
Check, in writing, which edition each plugin, Kong Manager feature and Konnect capability on your list requires, and what Kong's plan is for 3.9 deployments after December 12, 2026.
Tyk separates its licensing by component. The gateway code is under MPL-2.0, but the ee folder is under a separate commercial Enterprise Edition license, and the Dashboard, Developer Portal and Operator require a license. Tyk states that the gateway ships with no feature lockout in the gateway itself, so the commercial boundary sits around the management layer and the ee code. The Tyk LICENSE file is the starting point for the exact split.
- Gateway license: Tyk Gateway code is MPL-2.0 except the ee folder. Ask what the ee folder contains before you rely on any gateway feature in production.
- Self-managed platform: The full self-managed platform runs Tyk Gateway, Tyk Dashboard, the Developer Portal, Tyk Pump, Redis and PostgreSQL, and needs a license.
- Operator: The Tyk Operator for Kubernetes-native declarative API management requires a license. This matters if your GitOps design depends on it.
- Open source footprint: The open source gateway runs with Redis and installs through Docker, the tyk-oss Helm chart, Ansible, packages or source. Gateway v5.15.1 was published on October 2, 2026.
- Hosted option: Tyk Cloud manages the full stack and is available with a free trial. The README does not set out subscription pricing, so request it in writing.
Check which features you need fall under the ee folder or the licensed components, and whether your team needs the Dashboard and Developer Portal at all.
What drives the running cost of each gateway
Running cost for these three gateways comes from four places: which features sit behind a commercial license, which stateful services you must operate, how often you must upgrade to stay supported, and how much engineering time goes into custom plugins. The cards below set out what to check in each area and which figures only a vendor quote can confirm.
Licensed tiers for identity and dashboards
The open-source Kong repository does not include the OpenID Connect plugin, which Kong marks as an Enterprise tier plugin, so OIDC on Kong means a Kong Enterprise subscription. Tyk's Dashboard, Developer Portal and Operator need a Tyk license, while the Tyk Gateway itself is MPL-2.0. APISIX's openid-connect plugin is part of the Apache-2.0 project. Ask each vendor in writing which features your identity and management model requires, and what the license price covers.
Stateful services you operate
APISIX traditional and decoupled modes depend on an etcd cluster for configuration, while standalone mode avoids etcd by reading a YAML or JSON file. Kong traditional mode requires PostgreSQL, and DB-less mode holds configuration in memory. Open-source Tyk runs with Redis, and the full self-managed Tyk platform adds Dashboard, Pump and PostgreSQL. Each of these is a service your team patches, backs up and monitors, so count them in the operating model before comparing license fees.
Kong 3.9 sunset and LTS dates
Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, so an open-source Kong 3.9 deployment will need a planned move. Kong's LTS releases 3.10 and 3.14 are supported until March 31, 2028 and April 7, 2029. Confirm with Kong which support tier covers your deployment and what an upgrade path to a supported line costs before you commit to a version.
Release cadence on each side
APISIX publishes a continuing release line, and its downloads page does not mark any release as long-term support, so your team sets its own patch and upgrade rhythm. Tyk Gateway releases are published on GitHub on a frequent cycle. Budget staff time for regular testing of each upgrade against your plugins, routes and identity flows, and ask each vendor which releases receive security fixes and for how long.
Plugin development time by language
APISIX plugins are written in Lua inside worker processes, or in Java, Go or Python through external plugin runners, with WebAssembly still experimental. Kong plugins are written in Lua, Go or JavaScript. Tyk middleware can be written in Python, JavaScript, Go or any language with gRPC support. The staff time you need depends on which languages your team already maintains and how many custom plugins you expect to carry across upgrades.
How to run a fair three-way gateway proof of concept
This sequence puts APISIX, Kong and Tyk on identical terms, so the results reflect each gateway's behavior and licensing rather than differences in test setup. The output is a written comparison that a platform owner can sign off on before any production commitment.
Fix the OIDC flow and identity provider
Agree one identity provider, one OpenID Connect flow (for example, authorization code with PKCE for a browser-facing API or client credentials for a service caller) and the exact claims each route must check. Record the values in a shared test plan that the security and identity team signs off on. Note that APISIX's openid-connect plugin supports these flows with providers such as Keycloak, Okta and Microsoft Entra ID, while Kong's OpenID Connect plugin is an Enterprise tier plugin, so the Kong test needs an Enterprise license or the team must record that the requirement is not met by the open source line. Done when the test plan lists the flow, provider, claims and the license each gateway needs for that flow.
Choose the production storage mode for each gateway
For each platform, name the topology you would run in production: APISIX traditional, decoupled or standalone with etcd or a file, Kong traditional, DB-less or hybrid with PostgreSQL or in-memory configuration, and Tyk with Redis and its Dashboard if you plan to use it. Test the mode you would actually operate, not the simplest one, because the storage choice drives backup, failover and GitOps behavior. Ask the vendor or the documentation which mode is supported for your target environment before you build. Done when each gateway has one named mode in the test plan with a reason tied to your operating model.
Deploy each quick start or chart on the same cluster
Install the APISIX, Kong and Tyk gateways on one test cluster or VM set with the same CPU, memory, network path and upstream test service. Use each project's documented quick start or Helm chart, such as the Kong quick start with PostgreSQL, the APISIX getting started guide and the tyk-oss Helm chart, and record the versions you pinned. Keep the proxy and Admin ports documented for each product so routing tests hit the same paths. Done when all three gateways route a test request to the same upstream and the install notes list the exact versions, images and configuration files.
Reproduce one custom plugin in each language
Write one small plugin that performs the same action, such as adding a header from a lookup and logging the request ID, in each language the platform supports. For APISIX, test a Lua plugin and an external plugin runner, and record that WebAssembly support is experimental. For Kong, test the Lua, Go and JavaScript options the documentation describes. For Tyk, test the Python, JavaScript and Go middleware paths. Measure build effort, reload behavior and failure modes, and confirm each language option against the current documentation before you commit. Done when every plugin runs on the same test traffic and the team has a short log of what each language required.
Test license-gated features against written requirements
Compare the requirements list from step one with what each open source edition delivers. Test the Tyk Dashboard, Developer Portal and Operator only if you hold a license, and mark them as unverified in the open source test otherwise. Check Kong Manager, Konnect and the Enterprise plugins the same way, and check APISIX's built-in plugin set against the requirement list. Record each feature as available in open source, available only under a license, or not confirmed, and ask each vendor in writing to confirm the items you could not test. Done when every requirement has one of those three labels with the evidence or vendor confirmation attached.
Record the upgrade path for the pinned versions
For the version each team would pin, write down its support window and the next upgrade step. Use the published dates: Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, while 3.10 and 3.14 are LTS releases with support until March 31, 2028 and April 7, 2029. Confirm APISIX's release policy with the project, since the downloads page does not mark any release as long-term support. Note the Tyk release cadence from its GitHub releases page. Ask your provider how upgrades are scoped and tested. Done when the test plan has a dated upgrade path for each gateway and an owner for each upgrade decision.
Where switching between gateways gets expensive later
Switching costs sit in each gateway's configuration model, not in the proxy itself. In Apache APISIX, routes, upstreams and plugin settings live in etcd in the traditional and decoupled modes, or in a conf/apisix.yaml file in standalone mode, so the migration unit is the set of objects behind the Admin API on port 9180. Kong stores entities in PostgreSQL in traditional mode or in a declarative file in DB-less mode, and Tyk stores API definitions that map to its own schema and Redis-backed state. None of these export formats is a drop-in for the others, so an exit means translating every route, consumer, policy and certificate, then retesting each one. Ask each vendor for a documented export or dump procedure for your deployment mode before you rely on it.
Custom plugins carry the sharpest lock-in. APISIX plugins written in Lua run inside worker processes, while external runners add Java, Go and Python, and Kong plugins are written in Lua, Go or JavaScript. Tyk plugins can be written in Python, JavaScript, Go or any gRPC-capable language. A plugin written for one gateway will not run on another, so the rewrite cost scales with the number of custom plugins you have, and it is worth inventorying them now.
Identity configuration is where a licensing decision becomes a migration decision. APISIX's openid-connect plugin is part of the Apache-2.0 gateway, while Kong's OpenID Connect plugin is an Enterprise tier plugin and Tyk's Dashboard and Operator require a license. If your OIDC flows, token introspection or per-operation access rules depend on a licensed component, replacing that tier later means re-implementing the identity layer and retesting every client. Confirm current entitlements with each vendor's licensing terms before you commit, and record which components each gateway needs to run your production traffic. Keep route definitions, plugin configuration and policy files in version control from the first day, so the configuration is a reviewable artifact instead of a database snapshot. Plan the cutover as a change window: DNS time-to-live values, client allowlists, certificate chains and any hard-coded gateway addresses all need a date, an owner and a rollback. Before committing, check each platform's exit path in writing, including the export format, the supported deployment mode and whether the vendor's docs describe moving configuration out.
What buyers ask before hiring help with an API gateway
What drives the cost of a self-hosted API gateway project?
The cost follows the written scope: how many routes, plugins, identity providers and environments are in play, and how much hardening and testing is required. Your internal staff time is a separate cost that recurs after launch. A useful quote lists each deliverable (architecture, deployment, identity integration, plugin work, backup and restore, documentation, handover), the environments covered, the assumptions about your infrastructure and any ongoing support or upgrade retainer. Ask whether licenses for commercial components are included or billed by the vendor. DeployOpen does not publish a price list, so a quote follows from the written scope.
How long does a gateway implementation take, and what sets the timeline?
No general duration can be stated without the scope. The main drivers are the number of identity integrations, the count and complexity of custom plugins, how many environments must be built (development, test, production, disaster recovery), and how quickly your change approvals and network work move. Identity integration and certificate handling often set the critical path, while plugin count matters less once a pattern is established. Ask for a timeline tied to named milestones in the written scope, and confirm which items depend on your teams.
What does your team need to provide during a gateway project?
Plan for four types of access and ownership before work starts: administrative access to your identity provider to register clients and configure claims, network change approvals for routing and firewall rules, and named owners for each route, upstream service and certificate. Certificate ownership is often overlooked, so confirm who renews certificates and who holds the private keys. Ask DeployOpen to list these dependencies in the scope so that delays are visible early.
Can our team run APISIX, Kong or Tyk without outside help?
Many teams can, provided they have engineers comfortable with NGINX-based or Go-based infrastructure, the chosen configuration store and Kubernetes or virtual machine operations. The operating model needs people for upgrades, certificate rotation, monitoring, backup of the configuration store (etcd for APISIX traditional and decoupled modes, PostgreSQL for Kong traditional mode, Redis for Tyk), and on-call response. Confirm the staffing with your own platform leads, and consider whether a retainer for upgrades and testing fits better than in-house coverage.
Does OIDC in Kong require Kong Enterprise?
Yes. Kong's OpenID Connect plugin is marked as an Enterprise tier plugin in Kong's plugin documentation, so it is not part of the open source gateway. The open source Kong repository provides JWT, basic auth, OAuth and ACL authentication. If OIDC is a hard requirement, confirm the current edition and entitlement terms with Kong before you design around it. APISIX includes an openid-connect plugin in its open source distribution, which supports flows such as authorization code and PKCE.
How do Tyk's licensed components change the design?
Tyk Gateway itself is under the Mozilla Public License 2.0, but the ee folder carries a separate commercial license. The Tyk Dashboard, Developer Portal, Tyk Operator and the full Self-Managed platform need a license. A design that relies only on the open source gateway, with Redis and configuration managed through files or APIs, avoids those costs but takes on more operational work. If you need a graphical management console, a self-service developer portal or Kubernetes-native declarative management, include that licensing in the cost comparison from the start.
What do support windows mean for gateway upgrades?
A support window tells you how long a version receives fixes, which sets how often you must upgrade. Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, per Kong's version support policy, which applies to Kong Gateway Enterprise. Kong's long-term support releases are supported until dates listed in the same policy. APISIX's downloads page does not mark any release as long-term support, so confirm the upgrade cadence you will adopt. Build upgrade testing and rollback into the plan, whichever gateway you choose.
How is a fixed-scope gateway engagement agreed in writing?
Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Expect the written scope to name the platform and version, the environments, the identity integrations, the plugins or policies to be built, the testing and documentation deliverables, and the client responsibilities listed above. Ongoing support, upgrades and continuous testing are available as retainers and are scoped separately. Ask for changes to be handled through a written change request so that cost and timeline shifts are visible.
How DeployOpen helps choose and implement an API gateway
DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an API gateway shortlist across Apache APISIX, Kong and Tyk, the work starts with the licensing and component boundaries that decide what you can run without a commercial agreement.
How we scope
- Confirm which gateway features your APIs need, such as OIDC, MCP or AI routing, before choosing a platform.
- Map each shortlisted product's open-source components against the editions you would actually license.
- Agree deliverables, timelines and responsibilities in writing before any work begins, as engagements are fixed-scope.
How we build
- Select a deployment mode for your environment, such as etcd-backed, database-backed or file-driven configuration.
- Integrate the gateway with your identity provider, certificates, rate limits and logging inside your own infrastructure.
- Test authentication flows, routing, failover and configuration reloads against the scope agreed in writing.
How we hand over
- Document the architecture, configuration sources, upgrade path and any component that requires a commercial license.
- Provide runbooks covering backups, configuration change procedures and the steps for rolling out version upgrades.
- Walk your platform and security teams through the running system and the evidence produced for compliance reviews.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Track vendor release and support windows so your team knows when a version needs planning.
- Confirm with each vendor which features and support terms apply to your chosen edition before renewing.
