Open-source API gateways compared

Which gateway fits which scenario

This table matches common team situations to the gateway most likely to fit, with the fact behind each choice. Scenarios are illustrative, so test each one against your own identity provider, cluster and licensing requirements. Read the Why column as the condition under which the recommendation holds.

Where the open-source line stops for each gateway

How configuration is stored and deployed in each gateway

Plugin languages and authentication options compared

Each gateway extends its request path differently, and that choice decides which teams can write, review and maintain custom logic. The cards below compare plugin languages and the authentication features each product lists, with the identity provider flows you must verify in your own environment before committing.

What running each gateway asks of your team

This sequence walks through the operating tasks that come after selection, from choosing a deployment topology to wiring Kubernetes ingress, so that your team can see which work happens once and which recurs. Each step ends with a check you can use to confirm it is finished before the next one starts.

1. Choose the deployment topology first

   Your platform or gateway team picks the topology before anything else, because it sets the number of stateful components you will operate. Apache APISIX offers traditional, decoupled and standalone modes, where traditional and decoupled use etcd and standalone reads a YAML or JSON file. Kong Gateway offers traditional (database), DB-less and hybrid modes, and Tyk Gateway runs on Redis. Done means the team has written down which components run in each environment and who owns each one.

2. Stand up and back up the configuration store

   Whoever runs the data layer deploys the store the topology requires: an etcd cluster for APISIX traditional or decoupled modes, PostgreSQL for Kong traditional mode, or Redis for Tyk. Backup and restore are one-time design work plus a recurring job, and the recurring job is where effort grows with the number of clusters. Done means a restore has been rehearsed in a non-production environment and the team can state the recovery steps for each store.

3. Set up the license and plugin runtime

   The platform engineer confirms which features the chosen edition includes before building the plugin layer. Kong's OpenID Connect plugin is an Enterprise tier plugin, and the full Tyk Self-Managed stack and Tyk Operator need a license. APISIX runs Lua plugins inside worker processes and uses external plugin runners for Java, Go and Python, while its WebAssembly support is still experimental. Done means every required plugin has a written owner, a license status and a tested runtime.

4. Connect identity providers and authentication flows

   The security or identity engineer configures each identity provider against the gateway, using the authentication options your edition supports. Effort rises with each additional IdP, because each one needs its own client registration, token validation settings and test cases for flows such as authorization code, client credentials or PKCE. Done means each IdP has a passing test for every flow your applications use, with results kept as evidence.

5. Build the upgrade cadence against release lines

   The platform team sets a recurring upgrade schedule against each product's supported release line. Kong's open-source repository stays on the 3.9 line, while Enterprise supported lines carry their own end-of-support dates, so the schedule must follow whichever line you run. APISIX and Tyk publish new releases on their own cadence, and you should confirm the support window for any version you adopt. Done means the team has a dated calendar, a named owner for each upgrade, and a staging rehearsal on every release before production.

6. Wire Kubernetes ingress and routing

   The cluster team deploys the gateway's ingress component and maps routes to Kubernetes resources. Kong ships a Kubernetes ingress controller, Tyk offers a tyk-oss Helm chart and an Operator under license, and APISIX has its own ingress controller with a separate release line. Effort grows with the number of clusters and the number of route definitions that teams manage by hand. Done means a test route is served through the ingress path with the same policies as the non-Kubernetes deployment.

7. Document ownership and run recurring checks

   The operations lead records who owns each recurring task: backups, upgrades, certificate rotation, plugin updates and IdP changes. Ask vendors and your own platform team to confirm the support terms for your edition before you commit, because those terms define what you must run yourself. Done means the runbook names an owner and a review date for each task, and the team has run one full cycle of the checks.

Capability table across the three gateways

This table compares Apache APISIX, Kong Gateway and Tyk Gateway on license, open-core boundary, configuration store, deployment, plugins, identity, Kubernetes and AI features. Cells marked to confirm are areas where the researched facts do not settle the answer, so check them with the vendor before you shortlist. Use the table to spot where a paid tier changes what you can run yourself.

Each gateway in brief, with its license

Each of these three gateways is open source at its core, but the license terms differ in ways that affect what you can run without paying. Read each card for the license boundary, the release line you would actually deploy, and the one condition under which that gateway is the right pick.

How much effort and cost do self-hosted gateways involve?

How to choose and pilot a gateway for your shortlist

This sequence turns a shortlist of APISIX, Kong Gateway and Tyk into a documented decision, with each step producing evidence you can take into a vendor conversation or a procurement review.

1. Inventory required authentication flows and identity providers

   Platform owners and the identity team list every client type that will call the gateway, the flows each needs (authorization code, client credentials, token introspection, PKCE, JWT validation or client certificates) and the identity providers they must trust. Compare that list against the authentication options in each product. APISIX's openid-connect plugin names Keycloak, Auth0, Microsoft Entra ID, Google and Okta among supported providers, while Kong's OpenID Connect plugin is an Enterprise tier plugin, so confirm that tier in writing. The step is done when every flow has a named owner and a yes, no or confirm-with-vendor answer per product.

2. Decide the license posture and acceptable paid editions

   Security, legal and procurement agree whether the organization needs a fully open-source gateway, accepts a commercial edition for specific features, or both. Record the license of each core component: APISIX is Apache-2.0, the open-source Kong/kong line is Apache-2.0 but its newer releases ship as Kong Gateway Enterprise, and Tyk Gateway is MPL-2.0 with its Dashboard, Developer Portal and Operator requiring a license. Ask each vendor which features sit behind a paid tier and whether that list is versioned. The output is a one-page license matrix that names the features your design depends on.

3. Select the topology that matches your failure model

   The platform team maps each deployment option to its operating model. APISIX offers traditional, decoupled and standalone modes; Kong documents traditional, DB-less and hybrid topologies; Tyk's self-managed stack pairs the gateway with Redis, and its Dashboard and Pump components sit alongside it. Standalone or DB-less modes reduce dependencies but move configuration into files or APIs that your pipeline must manage. Ask each vendor how configuration changes propagate across nodes and what happens during a control plane outage. The step closes with a topology choice and a short written rationale for each candidate.

4. Test plugin language and extension needs

   Developers list every custom behavior the gateway must perform, such as request transformation, bespoke authorization or AI traffic rules, and note the language each one will be written in. APISIX supports Lua plugins in worker processes and external runners for Java, Go and Python, with WebAssembly support still experimental. Kong's README lists Lua, Go and JavaScript plugins, and Tyk's middleware chain supports Python, JavaScript, Go or any gRPC-capable language. Build one representative plugin in each shortlisted product and measure how long the team needs to write, test and deploy it. Confirm with each vendor how plugin upgrades behave across minor releases.

5. Run a pilot on your Kubernetes platform

   The platform team deploys each shortlisted gateway into a non-production cluster that matches production networking, ingress, certificate management and observability. Kong offers a Kubernetes ingress controller and Tyk publishes a tyk-oss Helm chart, while APISIX has its own ingress controller, so test the Kubernetes integration each vendor actually supports for your Gateway API or ingress patterns. Run load, failover, certificate rotation and configuration reload tests against the same routes. The pilot is complete when every candidate has passed the same test script and the results are recorded side by side.

6. Verify version support windows and upgrade paths

   Operations and the vendor confirm how long each release line receives patches and how upgrades are performed. Kong's version support policy distinguishes full support, sunset support and LTS releases for Kong Gateway Enterprise, and the open-source 3.9 line has its own release dates, so ask which line you would run and when it leaves support. APISIX's downloads page does not mark its current release as long-term support, so confirm the patch policy directly. Tyk's gateway releases are published on GitHub, and you should ask whether the chosen version carries a support commitment. Record the answers with dates taken from the vendor's own policy pages.

7. Document switching costs before signing

   Architecture, security and finance estimate what it would take to move routes, plugins, consumers, certificates and logs to another gateway later. Include the configuration format (etcd keys, Kong declarative or database entities, Tyk API definitions), custom plugin code, identity integrations and any tooling built on the admin API. Ask each vendor for its export and migration tooling and any limits on it, and confirm whether the license terms restrict moving self-managed configuration to a competitor. The output is a switching cost register that accompanies the contract review and a quote built from a written scope of the work.

What changes if you switch gateways later