Kong Konnect vs Apache APISIX: which to choose

Kong Konnect vs Apache APISIX: which fits your team

If you are facing a Konnect renewal, a data residency rule or concern about lock-in, the page question is simple: Konnect fits teams that accept a Kong-hosted control plane and want Kong to run the management layer, while Apache APISIX fits teams that need every component inside their own network and can operate the gateway and its etcd configuration store themselves. Both products cover the core gateway job, so the choice is about who runs the management layer and who carries the operational load.

Konnect keeps the control plane in Kong's SaaS, with data plane nodes you can self-host, run as serverless gateways or place in Kong-managed Dedicated Cloud Gateways on AWS, Azure or GCP. Your team still runs any self-hosted data planes, but it does not run the console, the configuration store or the upgrades behind it. APISIX has no hosted control plane. Its traditional deployment mode runs data and control plane together, its decoupled mode shares one etcd cluster between a data plane and a control plane, and its standalone mode reads a YAML or JSON file with no etcd at all. Each mode moves operating work onto your team, and the cost of that work depends on which mode you pick and how many clusters you run. Ask your engineers which mode they can support at 3 a.m. before you commit to one.

The decision turns on three questions: where the control plane must physically live, how much platform operating capacity your team has for etcd, gateway upgrades and certificates, and whether you depend on Konnect's developer portal and analytics. If the portal and analytics are central to your API program, price their replacement before you compare license lines. If your residency or air-gap rule rules out a hosted control plane, APISIX or self-run Kong Gateway OSS becomes the shortlist to test.

Which scenarios favor Konnect and which favor APISIX

This table matches common operating situations to the platform that fits them better, with the condition that tips the choice. Read each row against your own constraints: if the condition holds, the named option is usually the lower-friction path. Where both options can work, the condition column shows what to confirm before committing.

Scenario	Better fit	Condition that makes it so
Small platform team that wants a managed control plane	Kong Konnect	The team does not want to operate a control plane, and Konnect's Kong-managed control plane removes that work, with data plane nodes still in its own environment
Disconnected or air-gapped network	Apache APISIX (standalone mode) or Kong Gateway OSS (DB-less)	Konnect depends on a Kong-hosted control plane, so it is not an option; a file-driven APISIX or DB-less Kong deployment runs without outside connections
Strict data residency requiring every component in your own country or data center	Apache APISIX (traditional or decoupled mode)	Control plane, configuration store and Admin API must stay in-region; confirm with Kong which Konnect control plane regions apply before relying on Konnect
Team already standardized on Kong plugins and decK	Kong Gateway OSS (DB-less or traditional)	Existing routes, services and plugins are maintained as decK-compatible declarative files, so they can move without translation; confirm the open-source plugin set covers your needs
Team with strong Kubernetes and etcd operations skills	Apache APISIX (traditional or decoupled mode)	Staff can run and back up an etcd cluster and the Admin API, and want to own the control plane rather than pay for a managed one
Team that needs config changes applied without restarts from a file	Apache APISIX (standalone mode) or Kong Gateway OSS (DB-less)	Routes are managed as YAML or declarative files in Git; APISIX reloads its file every second and hot-reloads, and Kong DB-less reads its declarative files
Team needing database-dependent plugins such as cluster-strategy rate limiting	Kong Gateway OSS (traditional mode) or APISIX with etcd	Kong's DB-less mode does not support these plugins, so a database-backed topology is required; confirm plugin availability in the open-source edition
Team that wants the newest open-source release line without a fixed support window	Confirm before choosing	Kong's open-source line stays on 3.9 while Enterprise moves ahead, and APISIX's downloads page marks no release as long-term support; plan your own patching for either

How configuration is managed in Konnect and in APISIX

Konnect keeps the control plane in Kong's cloud, and your data plane nodes connect out to it. Route, service and plugin definitions are authored in the Konnect console or through its APIs, and the gateways pull that state. The operational question for your team is therefore not where the config lives but who can change it and under what approval path. Before you commit, confirm with Kong which Konnect control plane regions and connectivity requirements apply to your data plane nodes, and map who holds Konnect admin roles today. Exporting current state with decK, as described in the sibling data export guidance, is the practical first check on how portable your configuration already is.

APISIX gives you three deployment modes, and the choice decides where configuration sits. In traditional mode, the data and control plane run together and configuration is stored in etcd, changed through the Admin API on port 9180, while client traffic arrives on port 9080. In decoupled mode, separate data plane and control plane nodes share one etcd cluster. In standalone mode, there is no etcd at all: the gateway reads conf/apisix.yaml or conf/apisix.json, checks it for changes every second and hot-reloads without a restart. File-driven standalone mode fits a GitOps workflow well, since the file can be reviewed and versioned like code. The trade-off is that you lose dynamic writes through the Admin API, so your pipeline must become the only writer.

On the Kong side, the closest equivalent to APISIX standalone mode is DB-less mode in self-hosted Kong Gateway, which takes declarative files that can be kept in Git and exposes a read-only Admin API. The key difference to test is plugin scope: database-dependent plugins such as cluster-strategy rate limiting and OAuth2 need traditional mode, so a DB-less design may not carry every Konnect policy across. Ask your team to list each plugin in use and check it against the topology documentation before choosing a mode. Whichever gateway you run, decide up front whether changes flow through Git and CI or through a console, because mixing both on one node is the most common source of configuration drift.

Where your data and control plane sit

Konnect splits the gateway into a Kong-hosted control plane and data planes you run or Kong runs for you, while APISIX keeps every component inside your own network. The cards below show where configuration, logs, identity traffic and operating keys end up under each model, and which requirements make those differences decisive.

Configuration and log location

With Konnect, gateway configuration is authored and stored in the Kong-hosted control plane, and your data planes pull it from there. With APISIX in traditional or decoupled mode, routes, consumers and plugin settings live in etcd inside your network. Check where access logs and analytics are shipped, since a logging plugin that targets an external service moves that data out regardless of where the gateway runs.

Hosting models compared

Konnect offers self-hosted data planes, serverless gateways and Dedicated Cloud Gateways that Kong manages on AWS, Azure or GCP. Self-hosted APISIX has no vendor-run component, so you choose the cloud, data center or air-gapped site. Ask Kong which regions host the control plane for your tenant, and confirm whether a Dedicated Cloud Gateway would hold any of your traffic.

Identity integration and token flows

APISIX's openid-connect plugin can work with identity providers such as Keycloak, Microsoft Entra ID or Okta, covering authorization code, client credentials, token introspection and PKCE flows. Token validation then happens at your gateway, so the identity provider must be reachable from it. Under Konnect, confirm which token and key validation steps depend on the Kong-hosted control plane and whether your identity provider accepts those callbacks from Kong's network.

Residency and air-gap implications

Where a regulator or internal policy requires every component in one country or site, a control plane hosted outside that boundary is a finding in its own right. A fully self-hosted APISIX cluster can run disconnected once images and plugins are mirrored internally. Konnect depends on Kong's cloud for the control plane, so disconnected networks generally need a self-run option. Confirm residency terms with Kong in writing before relying on them.

Who holds the operational keys

Under Konnect, Kong's platform holds the control plane database and the access that your administrators use to publish changes, while you hold the data plane certificates and tokens. With APISIX, your team holds the etcd cluster, the Admin API key and TLS material, and must rotate and back them up itself. Map each key and certificate to an owner and a rotation procedure before choosing a model.

Evidence for assessments

Assessors will ask who can change routes and plugins, where those changes are recorded and how access is reviewed. DeployOpen can prepare the configuration-as-code repositories, access procedures and logging setup that document these controls for your environment. Auditors and certification bodies issue any reports or attestations, so ask your assessor which evidence they accept from each hosting model.

Operating each option by team profile

Platform teams that already run Kubernetes can host APISIX or Kong Gateway as in-cluster workloads and manage them with the same GitOps pipelines they use for other services. Under APISIX, the team runs the gateway nodes, the etcd cluster that stores routes and plugin configuration in traditional and decoupled modes, the dashboard if they want a UI, and the upgrade and backup routines for etcd. Under Kong Gateway OSS, the team can run DB-less mode from declarative files kept in Git, which removes the database from the picture, or run traditional mode with its own database.

Gateway nodes: Scaling, health checks, TLS certificate rotation and ingress configuration are the team's responsibility under either option.
Configuration store: APISIX traditional and decoupled modes depend on an etcd cluster the team must size, back up and monitor. Standalone APISIX reads a YAML or JSON file instead.
Upgrades: The APISIX downloads page lists 3.19.0, released on September 28, 2026, and does not mark any release as long-term support, so the team must set its own upgrade cadence and testing.
Konnect removal: Konnect's Kong-managed control plane, analytics and portal no longer sit between the team and its gateways, but the team takes on their replacements.
To confirm: Which mode fits your cluster, whether your plugins need database-backed features in Kong, and who on the team owns on-call for the configuration store.

Before choosing, confirm that your engineers can operate the chosen data store and that your plugin needs are covered by open-source releases.

What each option costs to run

Konnect costs and self-run costs are built from different parts. One side pays a subscription that scales with usage, while the other pays for infrastructure, configuration storage and the people who run the gateway, so the cards below separate one-time work from recurring work on each side.

Konnect subscription and metered usage

Konnect is billed as a recurring subscription, and the bill tracks what you run on the platform: gateway services, requests, developer portals and published APIs. Ask Kong for the metered units in your plan and how overages are billed, then model peak request volume rather than average volume. Confirm which features sit in your tier, since the self-hosted control plane is part of Kong Gateway Enterprise, not Konnect.

Gateway infrastructure and data plane hosting

Recurring infrastructure is the compute, load balancers, network paths and storage that run APISIX nodes or Kong data planes in your cloud or data center. Costs rise with request volume, number of regions, high availability replicas and TLS termination load. Konnect-managed Dedicated Cloud Gateways shift this cost to Kong's bill, so compare the hosting you would pay for against the data plane you would otherwise run yourself.

etcd cluster operations

In APISIX traditional and decoupled modes, etcd holds the routes, upstreams and plugin configuration, so you run and back up that cluster. Recurring work covers quorum health, disk and compaction monitoring, certificate rotation and restore testing. Standalone mode removes etcd but moves configuration into files or the Admin API, which shifts the operational work to your deployment pipeline. Ask your team which mode they will run before pricing the staffing.

Implementation and migration effort

One-time work includes exporting Konnect configuration, translating routes, consumers and plugins into the target format, rebuilding authentication with your identity provider and staging the cutover. Moving from Kong to APISIX means translating decK-exported services and plugins, so expect the largest one-time effort on that path. Staying on Kong Gateway open source keeps the configuration model and reduces translation work. Request a fixed scope with a written list of plugins and integrations before any estimate.

Upgrades, monitoring and on-call

Recurring operational cost comes from applying gateway releases, testing plugin compatibility, and keeping metrics, logs and alerts working on your own stack. APISIX 3.19.0 and Kong Gateway OSS 3.9.4 are recent releases, and the APISIX downloads page does not mark any release as long-term support, so you must plan your own upgrade cadence. Open-source Kong's 3.9 line has no published support window, so ask whether your upgrade path needs paid support. Budget on-call rotation for gateway incidents across regions.

Engineering time and support contracts

The largest recurring cost in a self-run gateway is usually the engineering time to own configuration, security patches, plugin development and incident response. Commercial support for open-source gateways is a separate contract from software licensing, and its scope, response times and coverage should be written into the quote. Ask whether the people you need to hire already run similar gateways, because the staffing estimate changes sharply with that answer.

What moving from Konnect to APISIX involves

The sequence turns Konnect's SaaS-managed configuration into an APISIX deployment your team runs, with traffic moved in stages and each dependency on Konnect-only features replaced or retired. The output is a tested cutover plan and a Konnect-free production gateway.

Inventory services, routes, consumers and plugins
Your gateway owner and API product owners list every Konnect service, route, consumer, credential type and plugin in use, including the upstream systems each one calls. Mark which plugins have a direct APISIX equivalent, which need a different approach and which depend on Konnect features such as the developer portal or analytics. The step is done when every live API appears in one inventory with an owner and a plugin mapping status.
Export Konnect configuration with decK
The platform team uses decK to run a gateway dump against the Konnect control plane and stores the resulting declarative YAML or JSON file in a version-controlled repository. Compare the export with the live inventory to confirm nothing was left out, such as disabled routes or plugins scoped to individual consumers. The step is done when the export is committed, reviewed and reproduced in a scratch environment.
Translate routes, upstreams and plugins to APISIX
Engineers rewrite the exported Kong services, routes and consumers as APISIX routes, upstreams, consumers and plugin configurations, and check each plugin's options against the APISIX plugin documentation. Plugins without an APISIX equivalent are redesigned, for example by moving logic to an upstream service or to a custom plugin written in Lua or through a supported plugin runner. The step is done when the APISIX configuration loads in a test environment and every route returns the expected responses.
Rebuild authentication flows against your identity provider
Security engineers reconnect each API's authentication to your identity provider, using the APISIX openid-connect plugin for OIDC flows or the appropriate key and token checks for service clients. They test authorization code, client credentials and token introspection paths, and confirm which claims downstream services expect. The step is done when test tokens from each client type are accepted or rejected as the policy requires, and the results are recorded for your security review.
Stand up APISIX and run traffic in parallel
The platform team deploys APISIX in the topology your architecture requires, whether traditional mode with its own etcd cluster or decoupled or standalone mode, and sends a copy or a small share of production traffic through it while Konnect continues to serve clients. Compare status codes, latency, rate-limit behavior and logs between the two paths. The step is done when the differences are explained and accepted, and the on-call team has runbooks for the APISIX deployment.
Replace Konnect-only features separately
Konnect's developer portal, analytics dashboards and Konnect-managed control plane have no direct APISIX counterpart, so the product owner assigns each one a replacement, such as an external portal, a self-hosted metrics and logging stack, or an APISIX dashboard for administration. Confirm which features your consumers and auditors depend on before cutover. The step is done when each Konnect-only feature has a named replacement, an owner and a tested path for your users.
Cut over and retire Konnect
After parallel results are accepted, the team switches DNS, load balancer or ingress targets to APISIX, keeps a documented rollback path to Konnect for a period agreed in your change plan, and then disables Konnect data planes. Retire Konnect only after you have confirmed that exported configuration, credentials and audit records are stored under your control. The step is done when all production traffic flows through APISIX and the Konnect subscription is ended in writing.

Questions buyers ask before switching from Konnect

How much effort does moving from Konnect to Apache APISIX take?

The effort depends mainly on how many services, routes, consumers and plugins you run, and how many of those plugins have a direct APISIX equivalent. A small set of routes with standard authentication and rate limiting is a much smaller job than a estate with custom Lua plugins, multiple workspaces and portal-published APIs. Start by exporting your Konnect configuration with decK, then count each entity type and mark every plugin as mapped, replaced or unsupported. That inventory gives you the scope to compare across vendors. Ask any implementation partner to price the work from that written inventory rather than from a general estimate.

Can our own team migrate off Konnect without outside help?

A capable platform team can do it internally if it has hands-on experience with NGINX, etcd, Kubernetes or Docker, and time to test. The main gaps are usually not the gateway itself but the surrounding work: the APISIX Admin API and dashboard replace Konnect's management UI, and you must also rebuild identity integration, observability, backups and upgrade routines. Be honest about bandwidth during the cutover window. If the team lacks those skills or capacity, a fixed-scope engagement with written deliverables can cover the build, testing and handover while your staff keep ownership.

What does our team need to provide during the migration?

You need to supply access to the Konnect organization, a decK export for each control plane, a list of consumers and their credentials, and named owners who can approve behavior changes. You also need the hosting environment for APISIX, including the etcd cluster in traditional or decoupled mode or a file-driven standalone setup, plus TLS certificates, DNS control and a staging environment that resembles production. Confirm early who can approve cutover and rollback decisions, because those approvals often set the pace more than the technical work.

How long does the cutover take, and what drives that?

The timeline is driven by the number of traffic paths, how much you can run in parallel, and how many consumers must change their endpoints or credentials. Running both gateways side by side and shifting traffic route by route generally reduces risk but extends the calendar. Teams with strict change windows, regulated approval steps or many external API consumers need more time for notification and testing. Ask for a schedule in the written scope that lists staging, parallel run, traffic shift and rollback criteria as separate milestones.

Can we replace Konnect's developer portal and analytics?

Yes, but not with a one-to-one feature match, so plan the replacement separately. APISIX provides observability plugins and integrates with external logging and metrics systems, which you run yourself, while the developer portal and API catalog need a separate tool. Options include a self-hosted portal from another open-source platform or a catalog built on Backstage. Confirm whether your consumers depend on self-service key issuance, published documentation or usage dashboards, because those features determine the replacement scope and cost.

What do we do about Konnect plugins with no APISIX equivalent?

Start by listing every plugin in use and checking it against the APISIX plugin documentation, which describes more than 100 built-in plugins. For gaps, you can choose a built-in plugin with similar behavior, write a custom plugin in Lua or use a plugin runner in Java, Go or Python, or move that function into the upstream service or an external component. Each option has a maintenance cost that recurs with every upgrade, so record who owns each custom plugin and how it will be tested. Some Konnect or Kong Enterprise plugins may not have an open-source counterpart, so confirm those before committing.

Which Kong edition do we need for a fully self-hosted control plane?

A fully self-hosted control plane with its own local control and data planes falls under the commercial Kong Gateway Enterprise offering, according to Kong's pricing page. The open-source Kong Gateway under Apache-2.0 is a self-run data plane with declarative or database-backed configuration, and it does not include Konnect's hosted control plane or the Enterprise management features. If you need a self-managed control plane without Kong's commercial licensing, APISIX in traditional or decoupled mode, or standalone mode, is the open-source route. Confirm license terms with Kong before you decide.

How DeployOpen helps you evaluate and move

DeployOpen plans, implements, hardens, documents and supports self-hosted gateways inside your own cloud accounts, data centers or air-gapped networks. For a move from Kong Konnect to Apache APISIX, the first piece of work is an inventory: which services, routes, consumers and plugins Konnect currently serves, which of them depend on Konnect-only features such as the developer portal or analytics, and which identity provider and TLS certificates sit behind them. That inventory decides the shape of the APISIX deployment, whether traditional mode with a shared etcd cluster, decoupled mode, or standalone mode driven by a YAML or JSON file, and it sets the scope of the translation work. Engagements are fixed-scope, so the deliverables, such as the deployment design, the translated configuration, the hardening baseline, the cutover runbook and the operating documentation, are agreed in writing before work starts.

Every quote follows from that written scope. DeployOpen does not publish a price list, so the fastest way to get a comparable proposal from us or from any other implementation partner is to supply the same inputs: the number of gateways and environments, the plugins in use, the identity providers involved, the regions or networks the gateways must run in, and whether monitoring, backup and testing of the new platform are in scope. Ask every bidder to state which items are one-time (design, translation, migration testing, cutover) and which recur (platform upgrades, certificate and patch handling, on-call coverage, and continuous security testing). Ongoing support, upgrades and continuous testing are available as a retainer, so the decision after cutover is whether your own platform team can carry those tasks or whether a retainer should take them on.

Kong Konnect vs Apache APISIX