Apache APISIX vs Kong licensing: which gateway is free to run for OIDC and newer releases
If your team needs an open-source gateway with OpenID Connect and a supported upgrade path, the licensing answer is different for each product. The APISIX plugins are all Apache-2.0 licensed, so the openid-connect plugin is available in the open-source project with no commercial tier. Kong's OpenID Connect plugin, by contrast, is marked as an Enterprise tier plugin in Kong's plugin documentation, so it is not part of the open-source gateway. Kong's open-source repository stays on the 3.9 line, while newer Kong Gateway releases ship as Kong Gateway Enterprise.
The support dates make this concrete. Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, per Kong's version support policy, which applies to Kong Gateway Enterprise. Kong's latest listed version is 3.16, released September 15, 2026, with 3.10 and 3.14 as LTS releases supported until March 31, 2028 and April 7, 2029. Before you commit, confirm with Kong which edition, and which support tier, covers your production gateway, and check the current window in the Kong Gateway version support policy.
The answer depends on three things: whether you need OIDC at the gateway, how much support risk your organization will accept on an open-source line, and whether you can run Kong Enterprise if you want current releases and the OIDC plugin. If OIDC is required and you want no commercial license, APISIX's open-source plugins fit that constraint, but you should confirm that the openid-connect flows you need (authorization code, client credentials, introspection or PKCE) work with your identity provider. If you already have Kong Enterprise budget and support processes, Kong's paid tier may be the simpler path. Ask both vendors to put the licensed components, supported versions and end-of-support dates in writing.
How licensing differs across the parts of each gateway
This table separates each gateway into its licensing parts, from the core code to the management plane, so you can see which pieces are free and which sit behind a paid tier. Read each row on its own, because a gateway can be open source in one part and commercial in another. The main takeaway is that APISIX's documented plugins are all under Apache-2.0, while Kong's OIDC plugin and newer Kong Gateway releases require Kong Gateway Enterprise.
| Part of the gateway | Apache APISIX | Kong Gateway |
|---|---|---|
| Core license | Apache-2.0, a top-level Apache Software Foundation project | Open source repository is Apache-2.0 licensed |
| Plugin license | All built-in plugins, including the openid-connect plugin, are part of the Apache-2.0 project (confirm each plugin's status in the docs) | Open source plugins are Apache-2.0; the OpenID Connect plugin is Enterprise tier only |
| OIDC availability | openid-connect plugin in the open source project, supporting Keycloak, Auth0, Microsoft Entra ID, Google and Okta | Enterprise tier only, so not part of the open source gateway |
| Latest release line | APISIX 3.19.0, released September 28, 2026 | Open source releases stay on the 3.9 line (3.9.4, October 12, 2026); Kong Gateway (Enterprise) 3.16, released September 15, 2026 |
| Support dates | The downloads page does not mark any release as long-term support (confirm current support windows with the project) | Kong Gateway 3.9 ended full support December 12, 2025 and reaches end of sunset support December 12, 2026; LTS 3.10 supported until March 31, 2028 and 3.14 until April 7, 2029 |
| Management UI and control plane | Admin API and file-driven configuration; no commercial control plane in the sources (confirm any dashboard options for your setup) | Kong Manager web interface and Kong Konnect cloud control plane; confirm which tier includes each |
| Self-managed topologies | Traditional, decoupled and standalone modes, with etcd in the first two and a file or API in standalone | Traditional (database), DB-less (in memory) and hybrid (separate control and data planes) topologies documented |
What is free in APISIX and what stays behind Kong's Enterprise line
Apache APISIX ships its full plugin catalog under Apache-2.0, and that includes the more than 100 built-in plugins covering authentication, security, traffic control, observability and AI gateway functions. The openid-connect plugin is part of that set. It works with identity providers such as Keycloak, Auth0, Microsoft Entra ID, Google and Okta, and supports authorization code, client credentials, token introspection and PKCE flows. For a team that needs OIDC at the gateway, the licensing question largely disappears: you can evaluate the plugin in the open source build, then decide on support and hosting separately. Confirm with your identity provider's documentation which grant types and claim mappings your applications depend on, and test them against the exact APISIX release you intend to run, since plugin behavior changes between versions.
Kong's open source repository is also Apache-2.0, but its releases stay on the 3.9 line. The most recent open source release named in the sources is 3.9.4, dated October 12, 2026. Newer Kong Gateway versions, including 3.16 (released September 15, 2026), are published as Kong Gateway Enterprise, and Kong's OpenID Connect plugin is marked as an Enterprise tier plugin, so it is not part of the open source gateway. Kong Konnect, the cloud control plane, and Kong Manager, the web interface, are tied to the product offering rather than the open source core. The support dates also matter: Kong Gateway 3.9 reaches end of sunset support on December 12, 2026, per Kong's version support policy. Ask Kong which edition and support window apply to your deployment before you standardize on 3.9.
Open source Kong is enough when JWT, basic auth, OAuth or ACL authentication covers your clients and you do not need OIDC at the gateway. The Kong/kong README also describes LLM and MCP gateway features, so an AI traffic use case does not by itself force an Enterprise license. The decision point is OIDC at the edge. If your standard is authorization code flows against a corporate identity provider, Kong's OIDC capability sits on the Enterprise side, while APISIX provides it in the Apache-2.0 plugin set. Before you choose, confirm the current edition matrix with Kong, confirm the APISIX plugin behavior with your own tests, and price the total support commitment for each path with a written quote covering who maintains patches, upgrades and hosting.
Which licensing factors change the decision in practice
Six factors decide whether the licensing difference matters for your team. Some are technical, such as where OIDC runs and where configuration is stored. Others are organizational, such as how long you can stay on one release line and whether budget is approved. Work through them before comparing features.
OIDC at the gateway
Kong's OpenID Connect plugin is an Enterprise tier plugin, so OIDC enforced at the Kong gateway requires a Kong Enterprise license. The APISIX openid-connect plugin ships under Apache-2.0 and works with Keycloak, Auth0, Microsoft Entra ID, Google and Okta, covering authorization code, client credentials, token introspection and PKCE flows. Confirm that your identity provider and flow are covered, then test token lifetimes and session handling in a non-production environment before you commit.
Tolerance for a release line
Kong's open source repository stays on the 3.9 line. Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026. Teams that need long-term support on Kong move to Enterprise LTS releases such as 3.10 or 3.14, supported until March 31, 2028 and April 7, 2029. APISIX 3.19.0 was released on September 28, 2026, and its downloads page marks no release as long-term support, so your team sets the upgrade schedule and owns the testing that goes with it.
Konnect and Kong Manager needs
Kong Konnect is Kong's cloud control plane for managing gateways across environments, and Kong Manager is the gateway's web interface. If operators need either, confirm whether a hosted control plane meets your data residency and change control rules, and whether Kong Manager is included in the edition you plan to buy. Teams that manage routes only through code and the Admin API should confirm that APISIX's Admin API and their existing tooling cover the same audit, review and rollback needs.
Enterprise budget approval
Kong's OIDC plugin and newer releases sit in Kong Gateway Enterprise, so a Kong estate that needs them carries a recurring subscription. No Kong Enterprise price is included in the facts behind this page, and DeployOpen does not publish a price list. Ask Kong for a written quote that names the products, support level, term and environments covered. Compare that with the internal effort of running APISIX, including etcd operations and plugin development. Budget approval should cover the subscription for every renewal term, not just the first.
Existing configuration store
APISIX keeps configuration in etcd in traditional and decoupled modes, and standalone mode reads conf/apisix.yaml or conf/apisix.json and hot-reloads when the file changes. Kong runs in traditional mode against a database, in DB-less mode with configuration held in memory, or in hybrid mode with separate control and data planes. Choose the store your team can already operate, such as an etcd cluster, a PostgreSQL service or a file-driven setup managed through GitOps. Confirm the high availability design for that store before you decide.
Existing Kong or APISIX estate
If your team already runs Kong or APISIX, the licensing question becomes a migration question. Plugin configuration, authentication policy, Admin API scripts and deployment topology all have to move, and the two gateways store configuration differently and model plugins differently. Inventory every route, consumer and plugin in use, and mark the ones that depend on Enterprise-only features such as OIDC. Confirm which plugins and plugin runner languages your APISIX setup depends on before you commit to a move.
What the Kong support dates mean for a 3.9 deployment
Kong 3.9 is already past full support, and its sunset window closes on December 12, 2026. Kong Gateway 3.9 reached end of full support on December 12, 2025, and according to Kong's version support policy it reaches end of sunset support on December 12, 2026. Once sunset support ends, the Enterprise line has no further window for that release. Treat the sunset date as the deadline for a migration plan, not as the date to start one. A move that involves database schema changes, plugin rework and retesting of authentication flows usually needs more time than the months left, so the first decision is whether your team commits to an upgrade path before the window closes.
The policy applies to Kong Gateway Enterprise. Kong's supported long-term support lines are 3.10 and 3.14, supported until March 31, 2028 and April 7, 2029, and the latest Enterprise release is 3.16, released September 15, 2026. If your deployment runs an Enterprise build, the upgrade target is one of these lines, and the choice between them depends on how long you need a fixed release to stay in support. Confirm with Kong which build your license covers before you pick a target, because the open source 3.9 repository on GitHub is governed separately and its support after December 12, 2026 is not stated in the policy this section relies on.
Ask Kong directly, in writing, what the open source 3.9 repository receives after December 12, 2026, including whether security fixes are published and for how long. Record the answer alongside your own risk register, because an open source line without a published support date is a different risk from an Enterprise line with one. If the answer is unclear, plan for the open source 3.9 build to be a temporary state, and price the move to a supported line into the same scope as your APISIX evaluation so the two options can be compared on equal terms.
How to confirm the licensing position before you commit
This sequence turns the open-source versus Enterprise question into a checked list of plugins, identity flows, release dates and quoted costs, so the decision rests on documented facts for your own routes rather than on the headline license alone.
Inventory every plugin your routes need
The platform or API team lists each route design requirement as a concrete plugin need: authentication, rate limiting, request transformation, observability, and any AI or MCP gateway behavior. Write each need against the route or service it serves, so every requirement can be traced later. The step is done when the list is signed off by the team that owns the routes and the security owner, and nothing is left as a general phrase such as "we need SSO."
Check each plugin's tier in the documentation
For each item on the inventory, check the vendor's plugin documentation for its tier. For Apache APISIX, confirm the plugin is in the Apache-2.0 project's built-in set in the APISIX plugin documentation. For Kong, check whether the plugin is marked as Enterprise tier in Kong's plugin documentation, which is where the OpenID Connect plugin is listed. Record the plugin name, the source page and the tier. The step is done when every row has a tier and a source, and any plugin without a clear answer is flagged for a vendor question.
Confirm OIDC flows with your identity provider
Identity and security engineers test the flows your applications actually use, such as authorization code with PKCE, client credentials, or token introspection, against your identity provider. The APISIX openid-connect plugin documentation names providers such as Keycloak, Auth0, Microsoft Entra ID, Google and Okta, but your provider version and configuration must be tested in a non-production environment. Confirm with each vendor which OIDC capabilities are included in the edition you would run. The step is done when a written test result exists for each required flow and each vendor confirmation is on file.
Pick the release line and its support dates
The platform owner selects the release line that will run in production and records its support dates from the vendor's own pages. For Kong, compare the open-source 3.9 line against the Enterprise version support policy, including the end of full support and end of sunset support dates for 3.9 and the LTS dates for the newer lines. For APISIX, confirm which releases the project's downloads page marks as long-term support and what it commits to for patch releases. The step is done when a dated support table exists for each candidate, with the source link beside each date.
Get a written Enterprise quote against your scope
Procurement requests a written quote from Kong for the Enterprise features and support tier that the plugin inventory and OIDC tests require, using the same scope document for every option. Ask what is one-time, such as licensing set-up or implementation work, and what recurs, such as subscription renewals and support. Ask what changes the price, including node counts, environments, data plane instances and support level, and whether a control plane service such as Kong Konnect is included or billed separately. Compare the quote with the internal cost of operating the open-source option at the same scope. The step is done when the quote and the internal estimate sit side by side with the same assumptions written down.
Record the decision and its evidence
The decision owner writes a short record that names the chosen gateway, the release line, the plugin tier results, the OIDC test evidence, the support dates and the quote reference. Store it with the architecture or change records so an auditor or internal reviewer can trace why each license position was accepted. Set a review trigger for when the release line nears its support end date or when the plugin inventory changes. The step is done when the record is approved and linked from the design documentation for the gateway.
Questions buyers ask about Apache APISIX and Kong licensing
Is Apache APISIX fully free to run in production?
Yes, the APISIX gateway is licensed under Apache-2.0, and that license covers the built-in plugins listed in the project documentation, which describes more than 100 of them across authentication, security, traffic control, observability and AI gateway functions. Your costs come from the infrastructure you run it on, the etcd cluster it depends on in traditional and decoupled modes, the people who operate it, and any commercial support or vendor product you choose to buy. The APISIX downloads page does not mark any release as long-term support, so ask your own engineers to confirm the upgrade cadence they will follow and budget time for it. Confirm the plugins you need against the repository before assuming they are all present.
Does Kong's open source 3.9 line still get new releases?
The open-source Kong/kong repository is Apache-2.0 licensed, and its releases stay on the 3.9 line, with 3.9.3 released on June 17, 2026 and 3.9.4 released on October 12, 2026 according to the Kong/kong GitHub releases. Kong's version support policy applies to Kong Gateway Enterprise, where 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026. Newer Enterprise releases, including 3.16 listed as the latest version on September 15, 2026, are where the policy's LTS releases 3.10 and 3.14 sit. Check the support policy and your own contract before planning around any date.
What does Kong Enterprise add that drives licensing cost?
Kong's OpenID Connect plugin is marked as an Enterprise tier plugin in Kong's plugin documentation, so it is not part of the open source gateway. The Enterprise line also carries the version support policy described above, including LTS releases and the sunset periods that follow end of full support. Kong Konnect, the cloud control plane, and Kong Manager, the web interface, are part of the broader product story, so confirm with Kong which of these features your environment needs and whether they are included in your edition. Each of these items usually drives the quote, so ask Kong to map every feature you rely on to a specific edition.
How long might migrating from Kong 3.9 take, and what drives that effort?
No supplied fact gives a migration duration, so treat any timeline as something to scope, not assume. The main drivers are the number of routes and plugins in use, whether you depend on Enterprise-only features such as OpenID Connect, the configuration storage model (PostgreSQL for traditional mode, in-memory for DB-less, or a hybrid control and data plane split), and how many services and clients point at the gateway. Replacing an identity integration, rebuilding policies in a different plugin model, and testing traffic behavior under load often take more time than the route migration itself. Ask any implementation partner for a written scope with a named list of routes, plugins, identity flows and environments before agreeing a schedule.
Can our team do the licensing review internally?
Yes, many teams can review the licenses and edition boundaries themselves, because the relevant facts are published by the projects and vendors. Start with an inventory of every plugin, feature and component you intend to run, then mark each one as open source, Enterprise, or unclear. Legal and procurement should confirm the license terms and support obligations in writing, since a technical reading does not replace a contract review. The internal review is cheaper when your architects already understand both gateways, and it gets harder when identity, audit and compliance requirements depend on features that sit behind a paid edition.
What should we ask for in a quote for this comparison?
Ask for a written scope that lists the gateways, versions, deployment topology, plugins, identity providers and environments covered, along with the deliverables and acceptance criteria. Request a breakdown of one-time work, such as the licensing review, architecture, migration and testing, separately from recurring work, such as upgrades, patching, backups and support. Ask how each item is priced and what would change the price, including new routes, extra environments or an unplanned change to the edition. DeployOpen plans and implements most work as fixed-scope engagements, with ongoing support and upgrades available as retainers, and quotes follow from the written scope rather than a published price list.
Which Kong or APISIX version should we plan around today?
Plan around the versions your vendor and project currently publish, and confirm the dates before committing. For APISIX, the downloads page lists 3.19.0 as released on September 28, 2026. For Kong, the open source line is 3.9 with 3.9.4 released on October 12, 2026, while the Enterprise policy lists 3.16 as latest and 3.10 and 3.14 as LTS. Note that 3.9 reaches end of sunset support on December 12, 2026 for Enterprise, so any move off it should start well before that date. Verify the current release tables on the day you decide, because the version landscape changes.
Does DeployOpen handle licensing decisions for us?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares systems and evidence for compliance assessments. It does not provide legal advice on license terms, and it does not issue audit reports or certifications. Your legal and procurement teams remain responsible for interpreting the contracts and licenses you sign. An engagement can cover the technical side of the comparison, the migration plan and the implementation, once the licensing position is agreed.
How DeployOpen helps evaluate and implement the gateway choice
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For the APISIX or Kong decision, we start from your written requirements for licensing, identity integration and deployment, then carry the chosen gateway through to a documented, supported environment.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which gateway features your team needs and which edition or license each one requires.
- We confirm current release lines and support end dates with the vendor before any licensing recommendation is finalized.
How we build
- We deploy the chosen gateway in your infrastructure using the topology your team selects after review.
- Identity integration, such as OIDC with your existing provider, is built and tested against your real access policies.
- We run security testing against the gateway and its admin interfaces before it carries production traffic.
How we hand over
- Handover includes configuration, deployment and operating documentation written for your own engineers.
- We prepare the systems, controls and evidence your compliance assessors will ask for, without issuing audit reports.
- Your team receives a written record of licensing decisions, edition assumptions and the upgrade path you chose.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover tracking of vendor support windows so your team plans upgrades before a release line ends support.
- Backup, patching and upgrade work is scoped separately so you know what each retainer includes.
