Kong Gateway open source vs Enterprise: when the free edition is enough
Choose the Apache-2.0 Kong Gateway 3.9 line when your team needs core routing, load balancing, health checking, JWT, basic auth or ACL authentication, and can own its upgrades. Choose Kong Gateway Enterprise when you need the OpenID Connect plugin, support terms set by a vendor, or a self-managed control plane and data plane, since Kong's pricing page places fully self-hosted control and data planes in the commercial offering and Kong Gateway 3.10 removed the unlicensed free mode. Before you commit, get Kong to confirm in writing whether your planned hybrid deployment is covered by the free edition, because the open-source README lists hybrid control plane and data plane separation while the pricing page places the self-managed version in Enterprise.
Topology decides which plugins you can keep. In DB-less mode Kong Gateway needs no database, reads declarative files that can live in Git, and exposes a read-only Admin API, which suits a GitOps pipeline with a small operational surface. Only traditional mode supports database-dependent plugins such as cluster-strategy rate limiting and OAuth2, so a team that depends on either must run a database and patch that extra layer. Map every plugin in your current configuration to a topology before you choose the free edition. Teams that stay on the open-source line can still manage configuration with decK, which is Apache-2.0 and syncs declarative files to open-source and Enterprise gateways, so the config workflow does not force an upgrade.
The support contract is where the free edition differs most. Kong's version support policy applies only to Enterprise, so it publishes no support window for the open-source edition, and you should ask Kong in writing what it will support on 3.9. For Enterprise, the version support policy lists 3.16 as the latest release from September 15, 2026, with 3.10 and 3.14 as LTS lines supported until March 31, 2028 and April 7, 2029. The 3.9 Enterprise line reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, so an Enterprise team still on 3.9 has a near deadline. Open-source teams own the patch cadence instead: track each 3.9 release, such as 3.9.4 from October 12, 2026, and schedule an internal test window for every one.
Which Kong Gateway capabilities sit in each edition
This table maps the main Kong Gateway capabilities to the open-source 3.9 line and to Kong Gateway Enterprise. Read each row as the documented starting point, and confirm edition boundaries in Kong's current documentation before you commit to a topology or licence. The main takeaway is that the open-source line covers core routing, authentication and configuration tooling, while the OpenID Connect plugin and fully self-hosted local control planes sit in Enterprise.
| Capability | Open source (3.9 line) | Kong Gateway Enterprise |
|---|---|---|
| Routing, load balancing and health checking | Listed in the open-source README for the 3.9 line. | Available. Confirm any edition differences in Kong's current documentation. |
| JWT, basic auth, OAuth and ACL | Listed in the README. OAuth2 depends on a database, so it needs traditional mode. | Available. Confirm which authentication plugins your Enterprise tier includes. |
| OpenID Connect plugin | No | Yes |
| Rate limiting and transformation | Listed in the README. Cluster-strategy rate limiting needs traditional mode with a database. | Available. Confirm the rate limiting strategies offered on your Enterprise version. |
| DB-less and hybrid deployment | Listed in the README and documented as topologies. Confirm hybrid support against your 3.9.x docs. | Documented topologies. Kong's pricing places fully self-hosted local control and data planes in Enterprise, so confirm terms with Kong. |
| decK configuration sync | Apache-2.0 tool that dumps and syncs declarative files to open-source gateways. | Same tool syncs declarative files to Enterprise gateways and Konnect. |
| Kong Manager web interface | Available on port 8002 in the open-source quick start. Confirm which views need Enterprise. | Gateway web interface. Confirm the feature set against your edition. |
| Konnect cloud control plane | Not part of the open-source gateway described in the sources. Confirm with Kong. | Kong's cloud control plane for managing gateways across environments. Confirm plan terms with Kong. |
| Kubernetes ingress controller | Apache-2.0 Kong Ingress Controller, release v3.5.13 published August 7, 2026. | Confirm whether your Enterprise subscription includes or changes ingress controller support. |
What the 3.9 open-source line and the Enterprise release train mean for support windows
The open-source Kong/kong repository stays on the 3.9 line, and its most recent release in the supplied record is 3.9.4, published October 12, 2026. Kong Gateway Enterprise follows a different path. It reached 3.16 on September 15, 2026 and has moved to quarterly releases since March 2025. The two editions therefore do not share a version cadence, and a version number on the open-source side does not tell you how far behind Enterprise you are in features or fixes. Before you commit, pull the current tags from the Kong releases page on GitHub and confirm which open-source patch your team would actually run.
Under Kong's version support policy, which applies to Kong Gateway Enterprise, 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026. The policy publishes no support window for the open-source edition, so an open-source team has no vendor-stated end date to plan around. Ask Kong in writing whether any security backport commitment exists for the open-source 3.9 line, and what that commitment covers. If the answer is none, the operating risk of staying on 3.9 is yours to carry, and your change calendar should assume it.
Kong's LTS lines give Enterprise customers a longer runway. The supported LTS releases 3.10 and 3.14 run until March 31, 2028 and April 7, 2029, respectively. For a self-hosted team, the practical decision is whether to stay on open source and accept an unpublished support horizon, or to move to an LTS line under a commercial agreement. Plan an upgrade test that covers your DB-less or hybrid configuration, your plugin set and your Admin API automation, and confirm the upgrade path and its effort with Kong before you set a date.
How the edition choice changes by team situation
Teams running DB-less gateways keep routes, services and plugins in declarative files, usually in Git, and deploy them through a pipeline. The open-source line fits this model well. The README lists DB-less declarative deployment, and no database is required. The limits are narrower but still matter for design: database-dependent plugins need traditional mode, and OpenID Connect is an Enterprise-tier plugin.
- Config as code: Declarative files can live in Git, and decK exports and syncs them to both open-source and Enterprise gateways, so the workflow carries across editions.
- Read-only Admin API: In DB-less mode the Admin API is read-only, so changes must go through the pipeline instead of live edits.
- Database-dependent plugins: Cluster-strategy rate limiting and OAuth2 only run in traditional mode, so a DB-less design needs stateless alternatives for those controls.
- Enterprise-tier plugins: OpenID Connect is not part of the open-source gateway, so teams that need it must plan for Enterprise licensing.
Confirm which plugins in your planned configuration run on the 3.9 line in DB-less mode, and test your pipeline against the exact version you intend to run. The Kong Gateway deployment topologies documentation is the natural next read for this check.
Teams that need single sign-on at the gateway usually want OpenID Connect validation. Kong's OpenID Connect plugin is marked as an Enterprise-tier plugin, so it is not part of the open-source gateway. Teams that can meet their token requirements with the authentication plugins on the open-source line, such as JWT, basic auth, OAuth and ACL, may find that enough. Those teams still need to check what each plugin verifies against their identity provider's tokens.
- OIDC validation: The Enterprise plugin is the documented route for OpenID Connect at the gateway, while the open-source line offers JWT and OAuth authentication.
- Custom plugins: Plugins can be written in Lua, Go or JavaScript for the open-source gateway, which can cover some gaps, but the team then owns the testing, maintenance and upgrades.
- Recurring licensing: Enterprise plugins come with Kong Gateway Enterprise licensing, so that cost recurs with the subscription term. Ask Kong for the exact terms in writing.
- Management features: Any Konnect or Enterprise management features in your design should be named in the quote, since they are separate from the gateway plugins.
Map each identity requirement to a named plugin on both editions, and ask Kong to confirm in writing which plugins your configuration needs before you choose the edition.
Regulated teams often need a dated support window for every component in scope. Kong's version support policy applies to Kong Gateway Enterprise. It lists 3.16 as the latest version, released September 15, 2026, with 3.10 and 3.14 as LTS releases supported until March 31, 2028 and April 7, 2029. For Enterprise 3.9, full support ended December 12, 2025, and sunset support ends December 12, 2026. The policy gives no published support window for the open-source edition.
- Enterprise LTS dates: The 3.10 and 3.14 LTS dates give a fixed end point for planning and change records.
- Open-source gap: The 3.9 open-source line has no published support window in that policy, so there is no vendor-stated end date to record for it.
- Enterprise 3.9 timing: Enterprise 3.9 reaches end of sunset support on December 12, 2026, which matters for any team still on that line.
- Evidence ownership: DeployOpen prepares controls and evidence for assessments, but independent auditors decide what is sufficient, so a written statement from Kong belongs in the file.
Ask Kong in writing for the support statement that covers your exact release, and file it with your change and risk records before the assessment begins.
Platform teams running hybrid mode separate control plane nodes, which hold configuration, from data plane nodes that serve traffic. The README lists hybrid control plane and data plane separation for the open-source gateway. Kong's pricing page, however, states that fully self-hosted gateways with a local control plane and data plane are part of Kong Gateway Enterprise. Those two statements must be reconciled for your exact layout before design begins.
- Topology choice: Kong documents three self-managed topologies, traditional, DB-less and hybrid, and the choice changes how the team sizes and secures each node type.
- Pricing boundary: Confirm whether your target layout, with local control and data planes, is covered by the open-source line or requires Enterprise licensing.
- Konnect option: Kong Konnect is Kong's cloud control plane, which changes who operates the control plane and where its configuration is stored, so it needs a data residency review.
- Upgrade sequencing: Multi-node clusters need a tested upgrade order across control and data planes, planned against the exact release you run.
Get Kong's written answer on whether your hybrid layout runs on the open-source 3.9 line and which edition covers each node type before you size the cluster.
What the removal of unlicensed free mode in 3.10 changes
Kong Gateway 3.10 removed the unlicensed free mode from Enterprise, and Kong's pricing page places fully self-hosted gateways with a local control plane and data plane in the commercial Enterprise offering. The cards below set out what that means for teams that previously ran that free mode, and what to settle with Kong before the next upgrade.
The free mode is gone from 3.10
Kong Gateway 3.10 removed the unlicensed free mode from Enterprise, so a build that used to run without a license on the Enterprise line has no equivalent path there. Teams that upgraded past 3.9 on the Enterprise line should confirm which license terms apply to each running node. The open-source 3.9 line remains under Apache-2.0, but it is a separate product with its own support window.
Self-hosted control and data planes
Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane are part of Kong Gateway Enterprise. Teams that ran a local control plane with no license should treat that topology as a commercial question, not a technical one. Ask Kong in writing which license covers each control plane and data plane you operate in your own infrastructure.
Traditional mode and database plugins
In traditional mode, every node connects to a shared database, and database-dependent plugins such as cluster-strategy rate limiting and OAuth2 depend on that database. If your open-source setup relied on those plugins, confirm with Kong whether the same plugin behavior is available under your edition and topology. Map each plugin in your configuration to its edition before planning an upgrade.
DB-less and declarative configuration
DB-less mode holds configuration in memory and reads declarative files that can be kept in Git. Teams that adopted DB-less deployments on the open-source line should check whether their pipelines, decK syncs and Admin API use depend on Enterprise features. Confirm the license position of each environment before promoting configuration to production.
Support window on the 3.9 line
The Kong/kong repository's releases stay on the 3.9 line, with 3.9.4 released on October 12, 2026. Kong's version support policy applies to Enterprise only, so it gives no published support window for the open-source edition. Ask Kong which fixes and security updates you can expect on 3.9 and how long they will be provided before you commit to that line.
Questions to put to Kong
Before changing versions, ask Kong to confirm in writing which license covers your topology, whether a hybrid or traditional deployment on your own infrastructure needs an Enterprise subscription, and which plugins you use fall under that license. Ask what the quote includes, what recurs each year, and how renewal and version upgrades are priced. Keep the answers with your architecture records for your compliance team.
Why the OpenID Connect plugin is the common reason to pay
The OpenID Connect plugin is marked as an Enterprise tier plugin in Kong's plugin documentation, so the open-source Kong Gateway does not include it. Teams on the open-source 3.9 line can still authenticate consumers with the plugins that ship in the gateway: JWT, basic auth, OAuth and ACL. The gap matters when your identity provider issues tokens through an OIDC flow and you want the gateway to validate sign-ins, discover endpoints and handle token introspection directly, rather than building that logic into each upstream service or into a separate proxy in front of Kong.
Paying for the Enterprise edition for OIDC tends to make sense when several conditions hold together: you need browser-based or user-facing sign-in at the gateway, your corporate identity provider is the system of record for access, and maintaining custom token validation in every service would cost more than the license. It is harder to justify when your clients are machine-to-machine, when JWT validation with keys published by your identity provider already meets your policy, or when the gateway only fronts internal services that sit behind an identity-aware layer you already run. In those cases, the open-source plugins may cover the requirement without a commercial license.
Before you decide, confirm plugin availability for the exact release you plan to run, because Kong's support windows and edition contents are tied to specific versions and lines. Check the OIDC plugin page and the Kong Gateway changelog, verify with Kong how the plugin behaves in your chosen topology, and ask for written confirmation of the Enterprise license terms and the support window for the release you select. Then test your actual token flow against the open-source JWT plugin in a staging environment, so the paid-edition decision rests on a gap you have measured rather than one you have assumed.
What each edition costs to run and who pays for what
This table separates what you pay a vendor from what you pay your own staff and infrastructure, for the open-source 3.9 line and Kong Gateway Enterprise. Read each row as a cost component, who receives the payment, whether it is one-time or recurring, and what moves it up or down. No Kong price list was available, so confirm licence figures through the Kong pricing page and a written quote.
| Cost component | Who is paid, and for what | One-time or recurring, and what drives it |
|---|---|---|
| Enterprise licence fees | Kong, for Kong Gateway Enterprise and the features it includes, such as the OpenID Connect plugin. Open-source 3.9 carries no licence fee. Kong publishes no price list in the supplied facts, so request figures from Kong pricing and a written quote. | Recurring. Driven by the edition, deployment scope and support terms named in the quote. |
| Upgrades on the open-source 3.9 line | Your own platform or SRE team, plus any partner you retain. Open-source 3.9.4 was released October 12, 2026, and the 3.9 line has no published support window beyond the Enterprise policy. | Recurring effort. Driven by how often you patch, how many clusters run, and how much testing your change process requires. |
| Staff effort for Enterprise upgrades | Your team, under a quarterly Enterprise release cadence with LTS lines such as 3.10 and 3.14 (supported until March 31, 2028 and April 7, 2029). | Recurring. Lower when you stay on an LTS line and automate config tests; higher when you track every quarterly release. |
| PostgreSQL infrastructure in traditional mode | Your cloud or data center team, plus your database operator. Traditional mode requires a database that every node connects to, and it is the only mode that supports database-dependent plugins such as cluster-strategy rate limiting and OAuth2. | Recurring hosting and backup cost, plus one-time setup. Driven by database availability design, backups and node count. |
| DB-less or hybrid topology effort | Your platform team for declarative configuration in Git (DB-less) or control plane and data plane separation (hybrid). Neither requires the same database operation, but DB-less cannot run database-dependent plugins. | One-time design and pipeline build, then recurring change management. Driven by CI/CD maturity and how many gateways you manage. |
| Konnect or other managed control plane | Kong, if you use its hosted control plane. Confirm whether this sits inside your Enterprise agreement or is billed separately. | Recurring. Ask for the billing unit and whether self-hosted data planes are covered. |
| DeployOpen scoping and implementation | DeployOpen, under a fixed-scope written agreement covering scope, deliverables and timelines. DeployOpen does not publish prices, and each quote follows from the written scope. | One-time for planning, deployment, hardening and documentation. Optional recurring retainers for support, upgrades and testing. Driven by topology, plugin count and integration breadth. |
Moving from the open-source 3.9 line to Enterprise, or back
This sequence moves a team between the open-source 3.9 line and Kong Gateway Enterprise with configuration and plugin behavior checked at each stage. Every step ends with a record you can audit, and the rollback path is a tested export taken before any cutover.
Inventory plugins, topology and consumers
The platform team lists every route, plugin, consumer and certificate in the running gateway, then records which self-managed topology is in use: traditional, DB-less or hybrid. Flag Enterprise-tier plugins such as OpenID Connect, and flag database-dependent plugins such as cluster-strategy rate limiting and OAuth2, which Kong's topology documentation ties to traditional mode. Store the inventory in version control. This step is complete when every plugin has a named owner and an edition decision.
Confirm the Enterprise license scope
The gateway owner confirms with Kong, in writing, which Enterprise deployment is licensed, including nodes, environments and support. Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane belong to Kong Gateway Enterprise, so confirm that your topology falls inside that scope. Also note that Kong's version support policy ends sunset support for 3.9 on December 12, 2026. Ask for a written quote that follows from the agreed scope. This step is complete when the license terms match your planned topology.
Export configuration with decK
An engineer runs
deck gateway dumpagainst the running 3.9 gateway and writes the declarative file to a Git repository. decK is Apache-2.0 licensed and syncs declarative files to open-source Kong Gateway, Kong Gateway Enterprise and Konnect, which makes it the common path for this move. Confirm which entity types your version of decK covers, and check separately how secrets and certificates are handled. This step is complete when the dump is committed, tagged and checked against the inventory from step one.Validate the export in staging
The team loads the exported configuration into a staging Kong Gateway Enterprise instance with decK, then replays representative traffic. Test authentication paths, including any OpenID Connect routes, rate limiting, transformations and health checks against the production baseline. In DB-less mode the Admin API is read-only, so confirm that changes flow through files rather than API calls. This step is complete when the test suite passes and error rates and latency are within the agreed tolerance for your service.
Migrate control and data planes
The platform team cuts over in stages. In hybrid mode, the control plane moves first and then the data planes follow, while in traditional mode nodes are replaced in a rolling order against the database. Confirm the exact upgrade path for your source and target versions in Kong's changelog and deployment documentation before starting. The on-call engineer watches error budgets during each stage. This step is complete when every node reports the target version and production traffic is served by Enterprise nodes.
Update admin access and automation
The team repoints scripts, CI jobs and monitoring from the old Admin API and Kong Manager endpoints to the new ones. The open-source quick start exposes the Admin API on port 8001 and Kong Manager on port 8002, so check whether your Enterprise deployment keeps those endpoints and how it applies role-based access to them. Confirm any Konnect connection separately. This step is complete when deployments run through decK against the new endpoints and access reviews show only approved administrators.
Rehearse the rollback from a tested export
The team restores the pre-cutover export onto a scratch 3.9 instance and runs the same traffic tests used in staging. Moving back to open source is only reversible with a tested export, because Enterprise-only plugins such as OpenID Connect have no open-source equivalent and those routes must be removed or replaced. Confirm the support position of 3.9 after December 12, 2026 before choosing this path. This step is complete when the rollback drill passes, and the runbook names the owner who can trigger it.
Questions buyers ask before choosing Kong Gateway editions
Does the open-source Kong Gateway 3.9 line still receive releases?
Yes. The open-source Kong/kong repository still ships releases on the 3.9 line, most recently 3.9.4 on October 12, 2026, after 3.9.3 on June 17, 2026. The open-source edition has no published support window, because Kong's version support policy applies only to Kong Gateway Enterprise. Kong Gateway 3.9 in Enterprise reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026. Your team should check the version support policy and the release notes before each upgrade decision, and plan who applies patches to the 3.9 line once Enterprise sunset dates pass.
What does Kong Gateway Enterprise cost, and why is no price shown?
The sources supplied for this page do not include an Enterprise price, so no figure appears here. Kong sets Enterprise pricing through its own sales process, and its pricing page states that fully self-hosted gateways with a local control plane and data plane belong to the commercial Enterprise offering. Your total cost has several parts: the Kong subscription (recurring), any DeployOpen implementation work under a fixed scope agreed in writing (one-time), infrastructure in your own cloud or data center (recurring), and internal staff time. Costs rise with the number of gateway nodes, the topology you choose and the support level you need. Ask Kong for a written quote that names the deployment model, node count and support tier.
How long does a migration from open-source Kong to Enterprise take?
No migration duration is supplied for this comparison, so treat any number you hear with caution and ask for the basis. The main drivers are your topology, the plugins in use, the size of your configuration and the number of environments. Traditional mode with a database, DB-less mode and hybrid mode each carry different migration steps. Configuration can move with decK, which is Apache-2.0 licensed and syncs declarative files to both open-source and Enterprise Kong Gateway. Plugins that depend on Enterprise features, such as OpenID Connect, need their own testing. DeployOpen plans fixed-scope engagements, and timelines are agreed in writing before work starts, so ask for the inventory and test plan first.
Can an in-house team run open-source Kong Gateway on its own?
A capable in-house team can run the open-source gateway alone for core traffic management. The Kong Gateway README lists routing, load balancing, health checking, JWT, basic auth, OAuth and ACL authentication, rate limiting and transformation plugins, DB-less declarative deployment and hybrid control and data plane separation. Three limits need planning. OpenID Connect is an Enterprise-tier plugin, so you would build or source that integration yourself. Database-dependent plugins such as cluster-strategy rate limiting and OAuth2 need traditional mode. And because no support window is published for the open-source edition, your team owns security patching, upgrade testing and incident response on 3.9. Confirm those ownership lines before you commit.
What does a DeployOpen engagement need from our team?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins, and ongoing support, upgrades and testing are available as retainers. In practice, your team should provide access to the target environments, a decision on the edition and topology, an inventory of APIs and plugins in use, named owners for change approval, and maintenance windows. Clear ownership on both sides keeps scope and quotes accurate. DeployOpen does not publish a price list, so a quote follows from the written scope.
Is the Kong Enterprise support window enough for an audit?
A vendor support window is a lifecycle fact, not audit evidence, so it cannot settle an audit on its own. Kong's version support policy lists 3.16 as the latest Enterprise version, released September 15, 2026, and lists 3.10 and 3.14 as LTS releases supported until March 31, 2028 and April 7, 2029. Those dates help you show that a supported version is running, but auditors also look at change control, access, logging and patch records. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors and certification bodies make those determinations. Ask your auditor which evidence they need before you pick an edition.
How DeployOpen scopes Kong Gateway work for either edition
Whichever edition you choose, the scoping question is the same: who plans, builds, hardens, backs up, upgrades and documents the gateway inside your own infrastructure, and what is written down before work starts. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted Kong Gateway in the client's own cloud accounts, data centers or air-gapped networks. That work applies to the open-source line and to Kong Gateway Enterprise alike, so the edition decision and the services decision can be made separately. Before you commit to either, confirm with Kong which edition your required plugins, such as OpenID Connect, actually need, because that determines the licensing scope your quote must reflect.
Most DeployOpen engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, so the written scope should name the Kong topology you intend to run (traditional, DB-less or hybrid), the plugins in use, the upgrade path off the 3.9 line if you are on it, and the evidence your assessors will ask for. Ask for each deliverable to be listed separately, including configuration exported with deck gateway dump where you use decK, and the documentation handed over at the end. Ongoing support, upgrades and continuous testing are available as retainers, which fit teams that expect to move between Kong release lines over time.
DeployOpen does not publish a price list. A quote follows from the written scope, so the effort it reflects depends on the components in scope, the number of environments, the integrations with your identity provider and logging stack, and how much of the upgrade and backup work you want to own internally. Ask for the quote to state which items are one-time (design, hardening, initial migration) and which recur (retainer support, upgrades, testing), and ask how the scope changes if you later move from the open-source edition to Kong Gateway Enterprise. DeployOpen does not claim vendor partner status or certification from Kong, so confirm any vendor-specific support terms directly with Kong.
