Apache APISIX vs Kong: which gateway to choose

Apache APISIX vs Kong: when each gateway fits

An API platform team that must run its gateway inside its own infrastructure should choose Apache APISIX when a fully Apache-2.0 open-source path and etcd-backed or file-driven configuration fit its operating model. Choose Kong when its plugin ecosystem, hybrid topology and Enterprise support matter more to the team than a single open-source license. The decision turns on four things: the licensing path the organization will accept, where configuration is stored, which plugins the APIs actually need, and how the team will handle the Kong open-source line against Enterprise releases.

Start with licensing. The APISIX repository is Apache-2.0 licensed, and its 3.19.0 release came out on September 28, 2026. The open-source Kong/kong repository is also Apache-2.0 licensed, but its releases stay on the 3.9 line, with 3.9.4 released on October 12, 2026. Kong's version support policy places Kong Gateway 3.9 at end of full support since December 12, 2025, with sunset support ending December 12, 2026. Feature and fix delivery for current Kong versions runs through Kong Gateway Enterprise, where 3.16 is the latest release. Ask Kong which open-source line will receive fixes after the sunset date, and confirm the upgrade path your team would follow from 3.9 to a supported release.

Then check configuration storage and plugin needs. APISIX stores configuration in etcd in its traditional and decoupled topologies and also supports file-driven and API-driven configuration, so a team that wants GitOps-style files can test that model in a lab first. Kong documents traditional mode with a database, DB-less mode with in-memory configuration, and hybrid mode with separate control and data planes. Plugin fit should be tested against your own routes. APISIX runs Lua plugins inside worker processes and supports other languages through external plugin runners, while WebAssembly support is still experimental. Confirm that every plugin on your list exists in the chosen edition before committing.

Which gateway fits which scenario

This table matches common team situations to the gateway that tends to fit better, and names the condition that drives each choice. Read each row as a conditional: the better fit changes if the stated condition does not hold in your environment. Confirm licensing, plugin coverage and support terms with each vendor before committing.

Scenario	Better fit	Condition that makes it so
Apache-governed open source end to end	Apache APISIX	Your policy favors projects under the Apache Software Foundation and Apache-2.0 licensing across the stack. Confirm which features you need exist in the open-source edition.
Already running Kong Enterprise	Kong	Your teams, plugins and policies are built on Kong Enterprise and migration cost would outweigh the benefit. Confirm Kong's current support window for your version.
DB-less or declarative configuration	Depends on the team	APISIX supports file-driven configuration alongside etcd. Kong offers DB-less mode with in-memory configuration. Compare how each handles your review and rollback process.
External plugin runners in Go, Python or Java	Apache APISIX	You need plugins written outside Lua. APISIX supports external plugin runners for other languages. Confirm the runner for your language and its maturity with the project.
Strict upgrade-cadence requirement	Apache APISIX	You need a predictable release line you can track. Check that the release you adopt is within a supported window, since Kong's open-source repository stays on the 3.9 line while Enterprise releases move ahead.

How each gateway is built and deployed

Both gateways sit on NGINX and run Lua inside the proxy, but they store configuration and split their deployment topologies differently. The cards below cover the build, the config stores, the topology options and the operating consequences that follow, so you can match each choice to your own infrastructure team.

NGINX and ngx_lua under LuaJIT

APISIX is built on NGINX and ngx_lua with LuaJIT, so request handling and plugin logic share one runtime. Your team should be comfortable reading Lua stack traces and tuning LuaJIT-related worker behavior, since plugin defects surface inside the proxy path. Ask each vendor which NGINX build, module set and Lua library versions they ship and support, and how they are patched between releases.

Kong's three self-managed topologies

Kong Gateway documents traditional mode, where every node connects to a database, DB-less mode, where configuration lives in memory, and hybrid mode, which separates control and data planes. The choice decides whether you run a database cluster, a declarative config pipeline or both. Confirm which topology your Enterprise edition and support contract cover before you design around it.

etcd as the APISIX config store

In APISIX's traditional and decoupled topologies, etcd holds the configuration that gateway nodes watch. This makes etcd cluster health, quorum, backup and version compatibility part of your gateway runbook. Ask who on your team will own etcd upgrades and disaster recovery, and test a node failure before production traffic depends on it.

File-driven and API-driven configuration

APISIX also supports file-driven and API-driven alternatives to the etcd-backed model. Declarative files suit GitOps review and reproducible environments, while API-driven changes suit systems that create routes on demand. Decide which pattern your change process needs, then confirm how each one behaves during reloads and how drift between files and running state is detected.

Control and data plane separation

Hybrid mode in Kong and decoupled topologies in APISIX both separate the control plane from the data plane, so proxy nodes can keep serving traffic when the management layer is unavailable. The cost is a second set of components to monitor, secure and upgrade in lockstep. Check how each platform handles certificate distribution and version skew between the planes.

Lua plugins inside worker processes

APISIX runs Lua plugins inside worker processes and reaches other languages through external plugin runners, while WebAssembly plugin support is still experimental. A slow or faulty plugin affects every request handled by its worker, so load testing custom plugins matters more than the plugin count. Ask each vendor how plugin failures are isolated and which languages they support in production.

Capabilities side by side

This table compares Apache APISIX and Kong Gateway on license, configuration storage, topologies, plugin runtimes, identity integration, and observability. Read each row as a question to confirm with the vendor for your version, since the open-source and Enterprise paths differ. The main takeaway is that the open-source version and release line you choose determines much of the upgrade and support picture.

Capability	Apache APISIX	Kong
Open-source license	Apache-2.0, released under the Apache Software Foundation	Open-source repository is Apache-2.0, but its releases stay on the 3.9 line
Configuration storage	etcd in traditional and decoupled topologies, with file-driven and API-driven alternatives	Database in traditional mode, in-memory in DB-less mode, and control and data planes in hybrid mode
Self-managed topologies	Traditional and decoupled, per the architecture documentation	Traditional, DB-less and hybrid, per the deployment topologies documentation
Plugin runtime	Lua plugins run inside worker processes on NGINX and ngx_lua with LuaJIT	Plugins run on the NGINX and Lua base; confirm the runtime model for your version in Kong's documentation
Non-Lua plugin languages	Supported through external plugin runners	Confirm supported plugin languages and out-of-process options with Kong's documentation
WebAssembly plugins	Experimental status per the architecture documentation; confirm before production use	Confirm current WebAssembly support against your Kong Gateway edition
Identity integration points	Confirm OIDC, LDAP and plugin-level authentication options in the APISIX plugin documentation	Confirm authentication plugins and Enterprise identity features in Kong's documentation for your edition
Observability and admin API	Admin API drives configuration; confirm metrics, logging and tracing plugins for your deployment	Admin API and configuration management; confirm metrics and logging options for your edition
Version support	Current release 3.19.0 (September 28, 2026), per the GitHub releases	Latest Enterprise release 3.16 (September 15, 2026); 3.9 open-source releases reach end of sunset support December 12, 2026

What is open source and what is paid for each

Apache APISIX is licensed under Apache-2.0 and is developed as an Apache Software Foundation project. The code, release process and governance sit with the foundation rather than with a single vendor, so the platform itself carries no separate open-source edition and no paid tier that changes which features the software contains. The current reference point is release 3.19.0, published on September 28, 2026. Costs for an APISIX deployment come from the people who run it, the infrastructure it sits on, and any commercial support contract the team chooses to buy from a third party or service provider.

License terms: Apache-2.0 permits commercial use, modification and redistribution, subject to the license's notice requirements.
Governance: Releases follow the Apache Software Foundation project path, so the release cadence is set by the project community.
Current release: 3.19.0 on September 28, 2026 is the reference point for planning upgrades.
Commercial support: Confirm with each vendor which support tiers, response commitments and any proprietary add-ons they offer, since these sit outside the open-source license.

Confirm that your security and legal teams accept the Apache-2.0 notice obligations and that your chosen support path covers the release line you plan to run.

How the Kong 3.9 open-source line affects upgrade risk

The upgrade question for Kong is less about whether the open-source repository is still usable and more about where the support clock runs out. Under Kong's version support policy, which applies to Kong Gateway Enterprise, Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026. Kong's open-source releases stay on the 3.9 line, with 3.9.4 released on October 12, 2026, so a team running the open-source build on 3.9 should map its own deadline against the policy and confirm with Kong what security and maintenance coverage applies to the open-source repository after that date. We do not assume the open-source line lacks fixes. That is a question for Kong to answer in writing.

A practical plan starts with an inventory: which Kong version each environment runs, whether those environments use traditional, DB-less or hybrid topology as described in Kong's deployment topologies documentation, and which plugins are in use. Then decide the target line. The version support policy lists Kong Gateway (Enterprise) 3.16 as the latest version and 3.10 and 3.14 as LTS releases supported until March 31, 2028 and April 7, 2029. Test the upgrade in a non-production environment that mirrors the database or declarative configuration, because the migration path depends on the topology you run. Confirm before committing whether the plugins and Enterprise-only features you need exist in the open-source build, since parity is not implied by the shared repository name.

APISIX takes a different approach to release timing. The apache/apisix releases page shows regular version numbers, with 3.19.0 released on September 28, 2026, so a team evaluating both gateways should compare the actual release history it can verify in each project rather than relying on a single date. For APISIX, the upgrade question centers on the etcd configuration store and any Lua or external plugin runners in use, which should be tested against each target release. Ask Kong for its written support commitments for the open-source line and ask the APISIX community or your implementation partner to confirm the upgrade path for your plugin set before the 2026 deadline shapes your schedule.

What drives running cost for each gateway

Running cost for either gateway comes from the infrastructure it needs, the people who can operate it, and the upgrade cycle that keeps it supported. Kong's Enterprise edition adds a subscription layer that APISIX's Apache-2.0 release does not carry, so the cards below separate what you pay vendors from what you pay your own teams and your own infrastructure.

Infrastructure footprint by topology

Traditional APISIX runs etcd as the configuration store, while Kong's traditional mode uses a database and its hybrid mode adds separate control plane nodes. Each topology has its own node count, quorum or database high availability design, and backup path. Ask your architects to size the datastore cluster and the control plane separately from the data plane, because those components recur as long as the gateway runs. Confirm the sizing with each vendor's architecture guidance before you commit to hardware or cloud capacity.

In-house Lua and NGINX skills

APISIX plugins run Lua inside worker processes, and Kong's plugin model also centers on Lua. If your team writes custom plugins, the skill to build, test and debug Lua and NGINX behavior is a recurring staffing cost, not a one-time setup task. Teams without that skill will either hire, train, or rely on an external partner. Check whether your engineers can own the NGINX configuration layer, since most production incidents at the gateway edge originate there.

Support contract options

The Apache-2.0 APISIX release has no vendor subscription built into the license, so support comes from a community, a commercial provider or your own team. Kong's Enterprise edition is a commercial product with its own support and version lifecycle, which is a recurring fee you should price through Kong's sales process. Ask each option what response commitments and upgrade assistance are included, and whether the contract covers the datastore and plugin runners as well as the gateway.

Upgrade and regression testing effort

Every gateway version change needs a regression pass across routes, authentication flows and custom plugins. Kong's Enterprise lifecycle moves versions on a published schedule, so you should plan upgrades before a version leaves support, not after. Confirm the upgrade path between the minor releases you intend to run, and budget test environments that mirror production topology. This effort recurs with each release cycle.

Plugin development and licensing

Plugin count is not the cost driver. What matters is who builds and maintains each plugin you depend on, and whether a licensed feature sits behind an Enterprise tier. Custom plugins in either gateway are one-time build work followed by recurring maintenance on every upgrade. Confirm which features your design needs are in the open-source build and which require a commercial license, because moving a feature between tiers later can change both cost and architecture.

Moving from Kong to APISIX or the reverse

This sequence moves routes, upstreams, certificates and policies from one gateway to the other without a single cutover event, so each stage can be checked and rolled back. It produces a documented inventory, a plugin gap list, a chosen configuration store and a retired gateway with its configuration archived.

Inventory routes, plugins and consumers
The platform team exports the current gateway state: routes, services, upstreams, consumers and credentials, certificates, global and per-route plugins, and any custom plugin code. For Kong, this usually means reading the declarative configuration or querying the Admin API in traditional or hybrid mode. Record which routes carry live traffic and which are dormant. The step is done when every route and consumer appears in one inventory file that the owning teams have reviewed and signed off, with no unexplained entries.
Map plugins and flag gaps
For each plugin in use, the team identifies the closest equivalent in the target gateway and tests its behavior against a sample request. Authentication, rate limiting, request transformation and logging plugins often differ in option names and default values, so the mapping is verified rather than assumed. Custom Lua plugins and any plugin without a clear equivalent go on a gap list with an owner and a decision: rebuild, replace or drop. Confirm each mapping against the current plugin documentation for the exact version you run, since plugin behavior changes between releases. The step closes when the gap list has no open items without a named owner.
Decide the configuration storage target
APISIX stores configuration in etcd in its traditional and decoupled topologies, and also supports file-driven and API-driven configuration. Kong offers traditional mode with a database, DB-less mode with in-memory configuration, and hybrid mode with separate control and data planes. The team picks the target that matches its operating model: etcd where the team already runs and backs up etcd, file-driven configuration where changes flow through Git review, or API-driven configuration where other automation calls the admin interface. Document who may change routes in production and how changes are audited. The step closes with a written decision record that names the storage model and its backup owner.
Build the target and run both gateways in parallel
The team deploys the target gateway in the same environment, loads the translated configuration into a non-production copy, and runs both gateways side by side. Synthetic test traffic checks status codes, latency, header handling, authentication outcomes and log output against the existing gateway. Certificates are installed on the new gateway, and upstream services are reached through the same endpoints so that no backend changes are needed. The step is complete when test results show matching behavior for every route in the inventory and the on-call team has run a failover drill on the new gateway.
Rebuild identity wiring and observability
Authentication hooks, token validation, consumer credential stores, and any single sign-on integration are reconnected to the target gateway and tested with real identity provider tokens in a staging environment. Dashboards, alert rules and log pipelines that read the old gateway's metrics or log format are rewritten for the new gateway's output. This step is often the largest source of hidden work, so it is scheduled before any production traffic moves. The step closes when a security reviewer confirms the authentication paths and the operations team confirms that alerts fire on test failures in the new gateway.
Migrate traffic in stages
Production traffic moves route group by route group, starting with low-risk, read-only paths. At each stage the team shifts a defined share of requests using DNS or load balancer weights, watches error rates and latency, and keeps the old gateway ready for immediate rollback. Stages advance only when the prior stage has met its agreed checks. The step produces a migration log that records each route, the date it moved, the checks it passed and any rollback. It is done when all routes serve traffic from the target gateway and the rollback path has been tested.
Retire the old gateway and archive its state
Once every route has run on the target gateway through an agreed observation period, the team disables traffic to the old gateway, exports a final configuration snapshot, and archives it with its certificates and plugin code in a controlled location. Credentials that existed only on the old gateway are revoked or rotated. The team removes the old gateway's infrastructure and updates the architecture documentation, runbooks and compliance evidence to reflect the new system. The step is done when the snapshot is stored, access to the old gateway is removed, and the documentation reflects the target gateway as the sole production system.

Where gateway implementation projects run long

The longest part of a gateway project is rarely the first install. It is the deployment topology decision, the identity and certificate wiring, and the cutover window. Decide the topology before anyone writes a plugin. APISIX offers traditional and decoupled topologies with etcd as the configuration store, plus file-driven and API-driven configuration. Kong documents traditional mode with a database, DB-less mode with configuration held in memory, and hybrid mode with separate control and data planes, per its deployment topologies documentation. Each choice sets who operates the datastore, how configuration is promoted between environments, and how a rollback works. Confirm these with your platform team before scoping.

Plugin parity is the usual source of delay. Teams that rely on custom authentication, request transformation or logging logic must map each one to a supported plugin, a plugin runner in another language, or a rewrite. APISIX runs Lua plugins inside worker processes and supports other languages through external plugin runners, while its WebAssembly support is still experimental. Kong's plugin model and Enterprise-only features differ, so inventory every plugin, its owner and its licensing edition early. Identity integration (OIDC or mTLS to your identity provider), certificate rotation, and observability pipelines also need working test environments, and they often take longer than the gateway itself.

Load testing and cutover close the gap between a working lab and production. Plan a load profile based on your own traffic, run it against the chosen topology, and rehearse failover for etcd or the Kong database, since operating those stores is where many teams lose time after go-live. DeployOpen works on fixed-scope engagements, and the written scope sets the timeline: the plugin inventory, topology, identity and certificate work, test plan and cutover steps are each agreed before work starts. Ask any implementer to show which of those items are included, which are assumptions, and which depend on your environment.

Questions buyers ask before choosing a gateway

Which gateway is cheaper to run?

Neither license is the main cost driver, because APISIX and the Kong open-source repository are both Apache-2.0 licensed, so the difference shows up in operations. Running APISIX means operating etcd as its configuration store in traditional or decoupled topologies, while Kong's traditional mode needs a database and DB-less or hybrid modes change the footprint again. Kong Gateway Enterprise adds a subscription, and its price comes only from Kong, so ask Kong for a quote. Ask your team to price staff time for patching, monitoring and plugin maintenance for each option across the same number of years, since that recurring labor usually outweighs the software line.

How long does an implementation take and what drives it?

Duration depends on the number of routes, the authentication model, the plugins you must replace, and how many environments need parity. Gateways with many custom plugins take longer to rebuild than gateways that use standard plugins, and hybrid or decoupled topologies add networking and certificate work. No duration figure is given here, so ask any implementation partner for a timeline tied to a written scope. DeployOpen works on fixed-scope engagements where scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope.

Can our team do this without outside help?

A team with experience running NGINX-based infrastructure, Lua or another plugin language, and a distributed key-value or database store can usually run either gateway in-house. The harder question is whether you can staff the work continuously, including upgrades, security patches and incident response. Check your team's skills against the topology you choose, and decide whether you need help with the first build, ongoing support, or both. DeployOpen offers implementation, hardening, documentation and retainers for ongoing support and upgrades inside your own infrastructure.

Is Kong 3.9 still safe to run?

Kong's version support policy says Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026. That policy applies to Kong Gateway Enterprise, so confirm with Kong which support tier covers your deployment. The open-source Kong/kong repository's 3.9 line still receives releases, with 3.9.4 released on October 12, 2026, but that does not replace vendor support. Plan an upgrade path to a supported line, such as the LTS releases 3.10 or 3.14, and confirm the dates and terms in writing before you rely on them.

Can we move from Kong to APISIX without downtime?

Zero-downtime migration is possible when both gateways run side by side behind a load balancer or DNS weighting, but it is not automatic because plugin behavior, authentication and configuration models differ. Map every Kong plugin and declarative setting to an APISIX equivalent, then test each route under production-like traffic before shifting any percentage. Confirm the exact plugin coverage in the APISIX plugin documentation for your use cases. Ask any implementation partner to document rollback steps and to define acceptance criteria before cutover.

Does APISIX support external plugins in our language?

APISIX runs Lua plugins inside worker processes and supports other languages through external plugin runners. WebAssembly plugin support is still experimental, so treat it as a risk for production plans. Confirm which runner languages your team uses, how they are deployed alongside gateway nodes, and how they are versioned and tested. If your plugins are written in Go, Java or Python, prototype one representative plugin and measure its latency and failure behavior before committing.

What does an implementation partner need from us?

A partner needs a written inventory of routes, upstream services, authentication methods, existing Kong plugins and custom code, along with target topology, environments and compliance obligations. It also needs named owners for change approval, security review and cutover. Provide traffic patterns and current incident history so the scope reflects real operating conditions. DeployOpen plans, implements, integrates, hardens, documents and supports these platforms inside your cloud accounts, data centers or air-gapped networks, and its engagements begin with written scope and a quote based on that scope.

How DeployOpen helps choose and implement an API gateway

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Apache APISIX vs Kong, we start from your traffic, identity and licensing constraints, then build and hand over a gateway your team can operate.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We document which gateway edition, license path and plugin set your routes actually need.
We confirm the config storage topology (etcd, database or DB-less) against your environment and failure tolerance.

How we build

We deploy the chosen gateway into your cloud accounts, data centers or air-gapped networks.
We integrate identity, routing, rate limiting and logging with your existing systems and test each plugin path.
We run security testing of the gateway and its APIs before it carries production traffic.

How we hand over

We deliver runbooks for upgrades, rollbacks and backups, tied to the version lines your team will run.
We document configuration, plugin choices and the evidence your compliance assessors may ask for.
We walk your platform and security engineers through operation so they can run the gateway without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We plan upgrades around vendor support dates, so a version change does not surprise your team.
A quote follows from the written scope, so ask us to price any change in writing before it begins.

Apache APISIX vs Kong