Kong vs KrakenD: which to choose

Kong vs KrakenD: when each gateway is the right choice

A platform team picking the API layer for self-hosted services should choose Kong when it wants a gateway that can run in traditional, DB-less or hybrid mode, with a wide plugin model and a Kubernetes ingress controller. Kong Gateway documents three self-managed topologies: traditional mode, where all nodes connect to a database, DB-less mode with configuration held in memory, and hybrid mode with separate control and data planes. Choose KrakenD CE when the priority is stateless nodes that operate independently, declarative configuration for GitOps workflows, and response aggregation across backend services. The KrakenD README describes every node as running without coordination or centralized persistence.

The decision turns on four questions. First, topology: does your team want a database or control plane to operate, or nodes that can be replaced freely? Second, plugin needs: will you write extensions in Lua, Go or JavaScript on Kong, or in Lua, Martian or Google CEL on KrakenD? Third, support windows on the open-source line: the Kong/kong repository stays on the 3.9 line, and Kong Gateway 3.9 reaches end of sunset support on December 12, 2026, so confirm what your team will run after that date. Fourth, enterprise features: Kong's OpenID Connect plugin is an Enterprise tier plugin, so if OIDC is required, price the Enterprise tier before you commit to the open-source edition.

Before you shortlist either gateway, run a proof of concept against your own services. Confirm that the aggregation and transformation your backends need are available in the edition you plan to run, and ask KrakenD whether the Enterprise Edition's SLAs, governance and 24/7 support are required for your environment. Ask Kong which features your topology needs are in the open-source line and which require Kong Gateway Enterprise. Your quote should separate one-time implementation work, such as topology design and plugin development, from recurring costs such as upgrades, support and testing.

Which gateway fits which team scenario

This table maps common team scenarios to the gateway that usually fits better and the condition that decides it. Read each row as a starting point, then check the edition column, because several outcomes depend on whether Kong Gateway Enterprise or KrakenD Enterprise is in scope. The main takeaway is that Kong suits teams that need a database-backed or hybrid control plane and a plugin ecosystem, while KrakenD suits stateless edge tiers and Git-managed configuration.

Scenario	Better fit and condition	Enterprise edition dependency
Many microservices with per-route plugins	Kong, when plugins must vary by route or service and you want a large plugin catalog managed through the Admin API or Konnect.	Kong OpenID Connect is Enterprise tier, so OIDC on the gateway depends on a commercial Kong contract.
Stateless edge tier scaled behind a load balancer	KrakenD, when every node should run independently with no shared database, and configuration ships as files with each release.	KrakenD Enterprise adds SLAs and 24/7 support, which matters if the edge tier is production-critical.
Configuration managed only in Git	KrakenD, because its declarative configuration fits GitOps workflows directly. Kong DB-less mode can also use files, but confirm how your CI/CD pipeline handles it.	Confirm with each vendor which governance and management features are in the edition you plan to run.
Backend aggregation and response transformation	KrakenD, since content aggregation, filtering and XML or JSON transformation are core features. Choose Kong only if aggregation can be handled by a separate service.	Not stated in the supplied facts for either edition. Confirm the feature set for your target version.
OIDC without a commercial contract	Neither open-source line should be assumed to cover this. Kong's OIDC plugin is Enterprise tier, and KrakenD's OAuth and JWT support should be checked against your exact token flow.	Yes, this is the decisive case. Confirm OIDC coverage in the open-source edition before committing.
Database-backed control plane with a shared configuration store	Kong traditional or hybrid mode, when operators need one shared store and a central admin view across many nodes.	Hybrid management through Konnect is a hosted control plane. Confirm which parts require a commercial agreement.
Multi-region edge with independent failure domains	KrakenD, because nodes do not coordinate or depend on central persistence, which limits shared failure points.	Confirm enterprise support terms for your regions with KrakenD.
Team with existing Kong operations skills and plugin needs	Kong, when your team already runs Kong and needs Lua, Go or JavaScript plugins. Switching later carries a migration cost that should be scoped in writing.	Kong open-source 3.9 line support windows differ from Enterprise releases, so check support dates before choosing.

How Kong's three topologies differ from KrakenD's stateless nodes

Kong Gateway offers three self-managed topologies, each placing configuration and state in a different spot. KrakenD takes a different route: every node runs independently and reads declarative configuration, so the operational questions shift from database uptime to how configuration reaches each node.

Traditional mode on a shared database

In traditional mode, every Kong node connects to one database, which holds the gateway configuration. Node failures are simple to recover from because any node can be replaced and reads the same state. The cost is that the database becomes a dependency for every node, so you need to plan its availability, backups and upgrades as part of the gateway. Ask your team who owns that database and how a database outage affects traffic handling.

DB-less mode with configuration in memory

DB-less mode removes the database and holds configuration in memory on each node, typically loaded from a declarative file. This suits GitOps pipelines because the file in version control is the source of truth. Changes reach nodes when the configuration is reloaded, so a rollout process must confirm every node has the same version. Check which plugins and admin workflows your team relies on before committing, since runtime changes through the Admin API behave differently here.

Hybrid mode with separate control and data planes

Hybrid mode splits Kong into control plane nodes, which connect to the database, and data plane nodes, which serve traffic without one. Data planes keep routing requests when the control plane is unavailable, which narrows the blast radius of a database problem. The trade-off is a second tier to secure and monitor, plus a sync path between planes. Confirm how your team would handle certificates for control-to-data communication and what happens to configuration changes during a control plane outage.

KrakenD's stateless nodes

KrakenD nodes run without coordination or centralized persistence, so each node is an independent instance configured from declarative files. A node failure removes only that node's capacity, and new nodes start from the same configuration with no database to join. Configuration changes reach nodes through your deployment pipeline, which makes GitOps the natural fit. Confirm how your team will verify that every node runs the same configuration version after a rollout.

Aggregation, plugins and identity: what each gateway includes

This table compares the capabilities named in the supplied sources for Kong Gateway and KrakenD CE. Where a feature is not documented in the sources used for this page, the cell tells you what to confirm in the vendor's documentation before you rely on it. Read the identity and plugin rows first if your authentication model depends on an Enterprise-tier plugin.

Capability	Kong Gateway (open source 3.9 line)	KrakenD CE
Routing and load balancing	Documented in the Kong/kong README alongside health checking	Documented as a core gateway function; confirm balancing options in the KrakenD configuration reference
Aggregation and filtering	Not described in the supplied sources; confirm whether a native aggregation feature or a plugin covers your use case	Content aggregation and filtering listed as a technical feature in the KrakenD README
XML and JSON transformation	Not described in the supplied sources; confirm in the plugin documentation for your release	XML and JSON transformation listed in the KrakenD README
JWT authentication	Listed in the Kong/kong README	OAuth and JWT security listed in the KrakenD README
Basic auth, OAuth and ACL	Basic auth, OAuth and ACL listed in the Kong/kong README	OAuth listed; confirm basic auth and ACL support in the KrakenD documentation
OpenID Connect plugin	Enterprise tier only, so not part of the open source gateway	Not described in the supplied sources; confirm OIDC support in the KrakenD Enterprise Edition scope
Rate limiting	Not described in the supplied sources; confirm in the Kong plugin catalog	Multi-layer rate limiting listed in the KrakenD README
Circuit breakers and telemetry	Health checking listed; confirm circuit breaker behavior and telemetry exporters in Kong's documentation	Circuit breakers listed; telemetry to Prometheus, Jaeger, Zipkin and Datadog listed in the KrakenD README
Kubernetes ingress	Kubernetes ingress controller listed in the Kong/kong README	Not described in the supplied sources; confirm the Kubernetes deployment options with KrakenD
Plugin languages	Lua, Go and JavaScript plugins per the Kong/kong README	Extensions in Lua, Martian and Google CEL per the KrakenD README

What the open-source lines and enterprise editions include

The open-source Kong Gateway is the Apache-2.0 Kong/kong repository, and its releases stay on the 3.9 line. The most recent release on that line is 3.9.4, published October 12, 2026, after 3.9.3 on June 17, 2026. Kong's version support policy applies to Kong Gateway Enterprise and lists 3.9 as ending full support on December 12, 2025 and sunset support on December 12, 2026.

License and release line: The repository is Apache-2.0 and its releases stay on 3.9, with 3.9.4 released October 12, 2026.
Core gateway features: The README describes routing, load balancing, health checking, JWT, basic auth, OAuth and ACL authentication, and a Kubernetes ingress controller.
Plugin languages: Plugins are written in Lua, Go or JavaScript.
Self-managed topologies: Traditional, DB-less and hybrid modes are documented, and the quick start runs Kong with PostgreSQL through Docker Compose.
Enterprise-only plugins: The OpenID Connect plugin is marked Enterprise tier, so it is not part of the open-source gateway.

Confirm with Kong how the 3.9 support dates apply to the open-source repository, and check which 3.9.x patch your team must run before you plan upgrades.

Does your API need aggregation, or a plugin chain?

Decide first whether the gateway should combine backend calls or only govern them. KrakenD is built around endpoints that fan out to several upstream services, merge the responses, and filter or transform the result before it reaches the client. That is its content aggregation and filtering feature. It removes client round trips when a screen or partner call needs data from three services at once: the client makes one request, and the gateway makes the upstream calls. Kong works differently. A request matches a route or service, a chain of plugins runs for authentication, rate limiting, logging and similar policy, and the request is proxied to one upstream. If your clients already call one service per screen, that model is often enough.

Aggregation has a cost. Once the gateway merges responses, the merge rules, field mapping and error handling live in gateway configuration that your API team must review, test and version like application code. A change to one backend contract can ripple into the gateway, and the team that owns the gateway may become a bottleneck. Kong keeps cross-cutting policy in a plugin chain that can be attached to many routes and services, so the same JWT, ACL or rate limit rules apply without each service implementing them. Kong plugins are written in Lua, Go or JavaScript. Check which policy plugins you need in Kong's plugin documentation, because OpenID Connect is an Enterprise-tier plugin and is not part of the open-source line.

Before deciding, test your own aggregation endpoints. Pick two or three screens or partner calls that currently make several client requests, build the merged response in KrakenD CE, and build the same flow as a Kong route with the plugins you need. Measure client round trips, latency against your real upstream timings, and how many files change when one backend field is renamed. Ask who will own the merge logic after go-live. KrakenD says its core framework, the Lura Project, was donated to the Linux Foundation, and the Lura repository is licensed under Apache 2.0 and held by LF Projects, LLC. Confirm the license of any extension you add separately, and check the current KrakenD CE release before you pin a version.

What drives the running cost of each gateway

Running cost for either gateway comes from the same few places: the infrastructure each topology needs, the people who can change it, the support terms you buy, and how often you must upgrade. Kong's cost shifts with the topology you choose, while KrakenD's depends more on how many stateless nodes you run and how much logic lives in configuration versus Go code.

Database and infrastructure in traditional mode

Kong traditional mode makes every node connect to a shared database, so the database becomes a component you size, back up, patch and fail over. Its hosting cost recurs for as long as the cluster runs, and its backup and restore procedures are a one-time design item. Ask the vendor or partner to price the database tier separately from the gateway nodes, and confirm how the database is managed in your environment.

Control and data plane sizing

Hybrid mode splits Kong into a control plane that holds the database and data planes that do not. Cost comes from running two tiers, sizing each for its load, and keeping the link between them healthy across failure cases. Ask how many control plane nodes your design needs, what data plane count you expect at peak, and whether that topology is covered by the license terms you are quoted.

Stateless node count for KrakenD

KrakenD nodes run independently with no shared state, so scaling means adding nodes behind a load balancer rather than sizing a database. Node count recurs as traffic grows, and cost per node is usually modest, but you still pay for load balancing, telemetry and capacity headroom. Ask for the node sizing assumptions behind any estimate and the traffic profile they assume.

Staff skills for plugins and extensions

Kong plugins are written in Lua, Go or JavaScript, so custom work needs engineers who can maintain that code through upgrades. KrakenD customization leans on configuration, with extensions in Lua, Martian or Google CEL, and Go for deeper work. Budget one-time plugin development and recurring maintenance, and ask which languages your team already supports and who will own the code after handover.

Support and SLA on enterprise editions

Kong Gateway Enterprise and KrakenD Enterprise Edition each sell support and service levels on top of the open-source line, and the terms differ. Support is a recurring fee, and the value depends on the response commitments, security coverage and governance features you need. Request the written service levels, escalation path, covered versions and what the quote excludes before comparing totals.

Upgrade effort against the Kong 3.9 sunset

Kong Gateway 3.9 reaches end of sunset support on December 12, 2026, so teams on the open-source 3.9 line must plan a move to a supported line. Upgrades are recurring work, and each one carries testing and plugin regression effort. Ask for an upgrade plan with dated milestones, the cost of moving Enterprise-tier plugins, and whether KrakenD version changes would require similar retesting.

Moving a gateway estate from Kong to KrakenD, or back

This sequence moves live API traffic between Kong Gateway and KrakenD one route at a time, so each route can be proven on the new gateway before the old one is retired. It also shows which parts of the estate carry over unchanged and which must be rebuilt.

Inventory routes, plugins and consumers
Your platform team, with DeployOpen if it is engaged, exports the current Kong configuration from the Admin API or from the declarative file if you run DB-less or hybrid mode. The inventory lists every service, route, upstream, plugin attached at each scope, and consumer with its credential type. Done means every route has an owner, a traffic profile and a named plugin set, and the list is reviewed against live access logs so that unused routes are marked for retirement rather than migrated.
Map Kong plugins to KrakenD features
For each plugin in the inventory, the engineering team checks whether KrakenD provides the same behavior natively, such as JWT validation, rate limiting, circuit breaking, response transformation or telemetry export. Plugins with no direct equivalent are marked for custom work, using KrakenD's documented extension options in Lua, Martian or Google CEL. Done means a signed-off mapping sheet in which every plugin is labeled native, configured, or custom, with an owner for each custom item. Confirm the exact feature coverage against KrakenD's current documentation, since this mapping is the main source of scope risk.
Rebuild authentication and rate limits
Security engineers reproduce the authentication chain in KrakenD's declarative configuration, covering OAuth and JWT validation against the same identity provider and issuer settings. Consumer-based rules move from Kong consumers and ACLs into KrakenD's per-endpoint or per-client limits. Kong consumer credentials are not portable in a standard way, so keys and secrets are reissued or migrated under a controlled process, and any Enterprise-tier Kong plugin such as OpenID Connect must be replaced with an equivalent you have confirmed. Done means each protected route passes positive and negative token tests, and rate limit behavior matches the agreed policy under load.
Run both gateways in parallel behind traffic splitting
Platform engineers deploy the KrakenD configuration alongside the existing Kong tier and place a traffic split in front of both, such as a load balancer or ingress rule that sends a small share of requests to KrakenD. Observability is wired to the same metrics backend on both sides so that latency, error rates and status codes can be compared directly. Done means parity checks pass on response bodies, headers and error codes for the sampled traffic, and any mismatch has a recorded cause and fix.
Cut over route by route
Each route moves to KrakenD in a planned change window, starting with low-risk, read-only endpoints and leaving the most sensitive ones for last. The change record names the route, the rollback step (returning the route to Kong at the load balancer), and the owner who approves the cut. Done means every migrated route has held its error and latency targets through an agreed observation period, and the change log shows a documented rollback path for each one.
Retire the old Kong tier
Once all routes are served by KrakenD and the rollback window has closed, the team removes the Kong nodes, their database or hybrid control plane, and related DNS and certificate entries. Admin API automation, CI jobs and monitoring dashboards that pointed to Kong are either deleted or repointed. Done means no traffic reaches Kong in your logs, the configuration is archived for audit, and the decommissioning record is signed off. If you plan to move back to Kong later, keep the archived inventory and mapping sheet, since they are the fastest way to reverse the sequence.

Where gateway implementations usually run long

Kong Gateway implementations usually run long at the data layer and the network layer, not at the route configuration. In traditional mode, every node connects to one database, so the team has to size that PostgreSQL instance for the Admin API write load and the proxy read path, decide how it is backed up and restored, and rehearse a restore before go-live. In hybrid mode, the work shifts to the control plane and data plane link: confirm which network paths the data planes use to reach the control plane, how certificates are issued and rotated, and what happens to traffic when that link is down. Plugin configuration is the third long item. Each environment (development, test, production) needs its own plugin settings, secrets and consumer records, and the team should decide early whether those are managed through the Admin API, decK or another declarative path. Because the OpenID Connect plugin is an Enterprise tier plugin, confirm its licensing before the design assumes it.

KrakenD implementations run long in a different place. The stateless design means there is no database to size, but the declarative configuration becomes the system of record, so the team must design how endpoint files, backend definitions and environment variables are split, reviewed and promoted through GitOps pipelines. Aggregation testing is the step most often underestimated: each merged endpoint depends on several upstream services, so response shapes, timeouts and partial failures need test cases that cover the gateway's behavior when one backend is slow or returns an error. Auth integration with the existing identity provider usually takes longer than expected in either product, since token validation, claim mapping and scope rules must match what the upstream services already expect. Load testing and the upgrade path also need planned time. Ask each vendor for the current support terms for the version you intend to run, and confirm them against the official pages before you commit.

Fixed-scope work starts with a written scope that names the topology, the identity provider, the plugins or endpoints in use, the environments, the load targets and the upgrade path, with deliverables and timelines agreed in writing before work begins. Ask for the assumptions behind each estimate so you can see which items would change the quote if the design shifts. Confirm each vendor's current support terms, including the support window for the open-source line you plan to run and what the Enterprise edition adds, because those terms change between releases and should come from the vendor, not from this page.

How much effort, time and skill does each gateway need?

What drives the cost of running Kong versus KrakenD?

Both open-source lines are Apache-2.0, so the license is not what separates running costs. The difference is what you operate. Kong's traditional mode connects every node to a database, and its hybrid mode adds control plane nodes that need their own care. Those components bring recurring work: database backups, node upgrades, monitoring and on-call time. KrakenD CE nodes are stateless and configured declaratively, so there is no central database to run. Costs still recur in infrastructure, testing and upgrades. Subscription costs apply only if you buy Kong Gateway Enterprise or KrakenD Enterprise Edition, and each vendor quotes those separately. Ask each vendor for a written list of what each subscription covers, support hours and renewal terms before you compare totals.

How long does a gateway migration take and what sets that time?

No supplied source gives a migration duration, so the time depends on your inventory. The biggest drivers are the number of routes, upstream services and consumers, the authentication flows each one uses, and whether you rely on custom plugins that must be rewritten. Kong's configuration lives in the database, in DB-less files or in a hybrid control plane, while KrakenD uses declarative configuration, so the translation work depends on your current setup. Parallel running, gradual cutover and the number of environments also add time. Fixed-scope engagements agree scope, deliverables and timelines in writing before work starts, so ask for a route-by-route inventory and a written plan before accepting any timeline.

Can an in-house team run Kong or KrakenD without outside help?

Yes, many teams do, provided they already run containers or Kubernetes and manage configuration as code. Kong needs more day-to-day operations if you choose traditional mode, because the database and its backups become your responsibility. Hybrid mode adds a second set of nodes to keep consistent. KrakenD's stateless nodes simplify horizontal scaling, but your team still has to test each configuration change and track releases, such as CE v3.0.1 released on October 13, 2026. Outside help tends to add value in hardening, upgrade testing, documentation and evidence collection. DeployOpen plans and implements self-hosted platforms in your own infrastructure and offers ongoing support as a retainer, so confirm which parts your team would keep.

Which skills does gateway work need: Lua, Go, Kubernetes and CI/CD?

Most day-to-day work needs configuration skills, not programming. Kong's README lists plugins written in Lua, Go or JavaScript, so Lua is needed only if you write or maintain custom Kong plugins in that language. KrakenD extensions use Lua, Martian or Google CEL, so your team needs the language that matches the extension you plan to build. Kubernetes skill matters when you run Kong's Kubernetes ingress controller or deploy KrakenD in clusters. CI/CD skill matters for declarative configuration, because both gateways are often managed through version-controlled files and pipeline checks. Confirm with each vendor which extension languages it supports for your planned features, and check that your team can test those extensions before go-live.

Is KrakenD CE enough for production use?

It can be, but the answer depends on your requirements for vendor support and governance. KrakenD Community Edition is Apache-2.0 licensed, and its README describes stateless nodes, declarative configuration, OAuth and JWT security, multi-layer rate limiting, circuit breakers and telemetry to Prometheus, Jaeger, Zipkin and Datadog. KrakenD sells an Enterprise Edition that adds SLAs, security, governance and 24/7 support. If your organization requires a contracted support commitment, that gap matters more than the feature list. The current CE line includes v3.0.0 (September 30, 2026) and v3.0.1 (October 13, 2026). Ask KrakenD which features and support terms apply to CE, and test your own failure and upgrade scenarios before going live.

Does OIDC require Kong's Enterprise tier?

Yes. Kong's plugin documentation marks the OpenID Connect plugin as an Enterprise tier plugin, so it is not part of the open-source gateway. The open-source Kong README still lists JWT, basic auth, OAuth and ACL authentication, which covers some token-based patterns without the OIDC plugin. Whether that is enough depends on your login flow, token validation and session needs. KrakenD CE lists OAuth and JWT security among its features, but the supplied sources do not confirm a full OIDC login flow in CE. Before you commit, map your authentication flows against each product's documentation and ask both vendors to confirm which tier provides each one, because plugin tiers can change between releases.

How does the Kong 3.9 sunset date affect planning?

Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, according to Kong's version support policy. That policy applies to Kong Gateway Enterprise, so if you run 3.9 Enterprise, plan your upgrade before the December 12, 2026 date. Kong's LTS releases 3.10 and 3.14 are supported until March 31, 2028 and April 7, 2029, and 3.16 is the latest version, released September 15, 2026. The open-source 3.9 line still ships releases, including 3.9.4 on October 12, 2026, but confirm with Kong how long its open-source line will receive fixes. A move to KrakenD is a separate decision with its own timeline, so do not treat the sunset date as the migration deadline.

How DeployOpen helps choose, implement or migrate 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 Kong vs KrakenD, we start from the topology and operating model your team needs, then scope the work in writing before anything is built.

How we scope

We confirm which Kong topology (traditional, DB-less or hybrid) fits your database and change-control model before design starts.
We map the upstream services, aggregation needs and plugin requirements that decide whether KrakenD's declarative model or Kong's plugin model fits.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
We list the Kong and KrakenD editions you would run, so licensing and support gaps are visible in the written scope.

How we build

We deploy the chosen gateway in your environment, with configuration kept in version control for review and rollback.
We integrate identity providers, rate limiting, telemetry and logging endpoints that your security team already operates.
We run security testing against the gateway and its exposed APIs before it carries production traffic.
We confirm, with the vendor, which plugins or features your chosen edition includes and which need a commercial license.

How we hand over

You receive architecture, deployment and runbook documentation covering the topology, upgrade path and failure modes.
We prepare configuration and evidence that your auditors or compliance assessors can review, without issuing any attestation ourselves.
Handover includes a walkthrough with your platform and security engineers so the team can operate the gateway independently.
Backup, restore and upgrade procedures are documented and tested against the environment you will actually run.

How we support

Ongoing support, upgrades and continuous testing are available as retainers once the gateway is in production.
We track vendor release and support windows so you can plan upgrades before a version leaves support.
If you later migrate between gateways, we scope that move in writing with the same documentation and testing standards.
Support scope, response expectations and review cadence are agreed in the retainer, so you can compare them with other options.

Kong vs KrakenD