Apache APISIX vs Kong: Migration, Operations, and Team Fit

Apache APISIX and Kong are both extensible gateways built around NGINX/OpenResty, but that similarity does not make them operationally interchangeable. The useful choice is not “which feature list is longer?” It is which product's configuration model, control-plane topology, extensions, upgrade process, and commercial boundary fit the team that will operate it.

Use a two-stage decision: first eliminate any option that cannot meet a hard protocol, policy, deployment, or support requirement; then run a production-shaped proof of concept for the remaining choices. Do not use a vendor benchmark or an empty proxy test as the final decision.

Key Takeaways

Compare exact editions and versions; open-source, enterprise, and hosted offerings are not feature-equivalent.
Choose the configuration source of truth before comparing user interfaces.
Inventory plugin behavior and stored state, not only plugin names.
Rehearse upgrades, rollback, and control-plane failure before migrating traffic.
Make performance one measured dimension alongside correctness, operations, security, and recovery.

Compare the Operating Model

Dimension	Apache APISIX	Kong Gateway	Decision question
Runtime foundation	NGINX, ngx_lua, LuaJIT	NGINX/OpenResty and Lua	Does the team already operate and extend this stack?
Configuration topologies	Traditional, decoupled, and standalone modes	Traditional database, hybrid, DB-less/declarative, and hosted Konnect patterns	Which system owns desired state and distributes it?
Common external state	etcd in traditional/decoupled APISIX; no etcd in standalone	PostgreSQL in traditional/control-plane patterns; no database in DB-less data planes	Can the team operate the selected dependency and back it up?
Declarative workflow	Standalone YAML/JSON or controller-driven workflow	Declarative configuration; decK for compatible control planes	How are changes diffed, approved, promoted, and rolled back?
Extensions	Lua plugins, external plugin runners, and experimental Wasm runtime	Lua and product-supported plugin ecosystem; custom behavior depends on topology and edition	Are required plugins supported and lifecycle-compatible?

The APISIX architecture documentation describes its core, Lua plugins, multi-language plugin runners, and Wasm runtime. The deployment-mode reference distinguishes traditional, decoupled, and standalone behavior. Standalone mode removes etcd from the configuration path, but it changes how complete configuration is delivered.

Kong's deployment-topology documentation distinguishes traditional database, hybrid, DB-less/declarative, and Konnect-managed control-plane patterns. In DB-less mode, each gateway loads configuration into memory; the Admin API is read-only for entity CRUD and database-dependent plugin behavior can be limited. These are workflow choices, not merely installation flags.

Start with Hard Requirements

Create an evidence table for the exact releases and editions under evaluation:

HTTP, gRPC, WebSocket, and stream-routing requirements;
authentication and authorization integrations;
rate-limit accuracy and shared-state needs;
service discovery and Kubernetes Gateway API ownership;
logging, tracing, metrics, and audit requirements;
custom plugin language, sandbox, dependencies, and support model;
FIPS, compliance, support, or managed-control-plane requirements;
offline, air-gapped, multi-region, and data-residency constraints.

A matching plugin name is not sufficient. Compare schema, execution phase, failure behavior, storage, response contract, observability, and edition. If a required capability is commercial in one product and open source in another, record that boundary rather than implying parity.

Choose the Configuration Source of Truth

Configuration ownership drives daily safety.

For APISIX with etcd, protect the Admin API, restrict its network exposure, rotate keys, and define etcd backup and recovery. In standalone file mode, validate and publish complete configuration atomically and know that a malformed or incomplete artifact must not become the desired state.

For Kong traditional or hybrid mode, define PostgreSQL backup, control-plane availability, and CP-to-DP compatibility. In DB-less mode, full declarative loads replace the configured state; the workflow must detect accidental deletion. The official deck gateway documentation provides validate, diff, dump, apply, and sync operations for traditional, hybrid, and Konnect-managed instances, but states that these live-gateway commands do not manage DB-less gateways.

Ask the same questions for either product:

Where is desired state reviewed?
Which tool detects drift?
Is a change incremental or a full replacement?
How is secret material separated from ordinary configuration?
Can the previous known-good state be restored without improvisation?
What continues serving when the control plane or state store is unavailable?

Compare Extensions as Production Code

Custom plugins become part of the request path. Inventory each existing Kong plugin and map it to an APISIX equivalent, application behavior, external policy service, or intentional removal. Do the same in reverse if moving toward Kong.

For every plugin, record:

Field	Migration evidence
Trigger and phase	When it executes relative to authentication, rewriting, routing, and logging
Configuration	Required fields, defaults, validation, and secret references
State	Local memory, shared database, external store, or stateless
Failure contract	Status, retry, degradation, timeout, and returned headers
Observability	Metrics, logs, trace attributes, and reason codes
Compatibility	Gateway version, topology, edition, and runtime dependencies

Rewrite tests around behavior rather than configuration shape. A transformed YAML file is only a migration input; it does not prove equivalent enforcement.

Plan the Migration as a Reversible Experiment

Inventory routes, services, upstreams, consumers, certificates, plugins, and external dependencies.
Classify hard requirements, optional behavior, dead configuration, and edition-specific capabilities.
Translate a small representative slice, including one authentication flow, one stateful policy, and one failure-prone upstream.
Validate schemas and start the candidate gateway with pinned versions.
Replay sanitized production-shaped traffic and compare status, headers, routing, policy decisions, logs, and traces.
Load test equivalent topologies using a disclosed method rather than inherited vendor numbers.
Shadow or canary traffic without allowing two gateways to mutate the same downstream operation.
Cut over with a rollback threshold, owner, and preserved source configuration.
Observe error rate, tail latency, denials, upstream distribution, resource use, and control-plane convergence.

Do not begin with every route. A representative slice should expose the hardest state, security, and extension differences early.

Evaluate Upgrades and Failure Recovery

Run one upgrade and one rollback in the proof of concept. For both gateways, pin compatibility among data plane, control plane, plugins, declarative schema, and orchestration resources. Test these failures:

configuration store or control plane unavailable;
invalid configuration published;
new and old data-plane versions overlap;
a custom plugin fails to load;
certificates or secrets fail to refresh;
nodes restart with the last known configuration;
rollback occurs after a state or schema migration.

Kong's topology choice changes upgrade sequencing and database work. APISIX's etcd, decoupled, and standalone choices change the dependency and configuration-recovery path. Compare the topology you will actually run, not default laptop installations.

Make a Conditional Decision

APISIX may fit when the team values its dynamic etcd model, standalone options, APISIX plugin set, or its particular integration ecosystem. Kong may fit when the team already operates its declarative/decK workflow, PostgreSQL or hybrid topology, plugin portfolio, or Konnect services. Either can be the wrong choice when a required capability belongs to a different edition, when the team cannot operate its dependencies, or when custom behavior dominates the migration.

Use a weighted score only after hard requirements pass. Suggested dimensions are correctness, policy coverage, change safety, recovery, observability, extension maintenance, latency under representative policy, infrastructure cost, licensing, and support.

Decision Checklist

Are exact versions, editions, and topologies named?
Is the desired-state and drift workflow proven?
Do all required plugins have behavioral tests?
Are backup, upgrade, rollback, and control-plane failure rehearsed?
Are benchmarks topology-equivalent and reproducible?
Are Kubernetes, multi-region, and residency boundaries explicit?
Is the migration reversible until production evidence is sufficient?

Summary

The APISIX-versus-Kong decision is an operating-model decision disguised as a feature comparison. Establish hard requirements, compare equivalent topology and editions, test plugin semantics, and rehearse recovery. The better fit is the gateway whose behavior your team can prove and safely operate—not the one with the most impressive undifferentiated checklist.

FAQ

Is APISIX always faster than Kong?

No universal result is valid across versions, hardware, topology, protocols, plugins, TLS settings, and load shapes. Run a controlled benchmark for the intended deployment.

Can declarative configuration make either gateway GitOps-ready?

It helps, but Git storage alone is not a complete delivery system. You still need validation, secrets handling, diff review, promotion, drift detection, observability, and rollback.

Can a migration tool replace a migration test?

No. Translation can accelerate inventory conversion, but only behavioral and failure testing can demonstrate policy equivalence.

Next Steps

Use the reproducible Traefik, Kong, and APISIX benchmark method, review API gateway plugin design, and plan a reversible rollout with canary traffic.