Kong Konnect vs Kong Gateway open source: which fits your renewal
If your Konnect renewal or pricing change has you asking whether to keep paying, the real question is whether you keep Kong's SaaS control plane or run Apache-2.0 Kong Gateway OSS yourself. Konnect fits teams that want Kong to operate the control plane, the portal and the analytics, and that depend on Enterprise-only plugins or Kong-managed Dedicated Cloud Gateways. Self-run open-source Kong fits teams that already manage their own infrastructure, can keep routes and plugins in declarative files, and need only the gateway's core features such as routing, load balancing, JWT, OAuth, ACL and rate limiting. Air-gapped or residency-bound networks lean toward the self-run path, because Konnect's control plane is hosted by Kong.
The decision turns on five things. First, list which Konnect features your teams actually use: the Dev Portal, analytics, Enterprise plugins, or Dedicated Cloud Gateways. Each one you use has to be replaced or dropped. Second, decide whether you need a management UI, since open-source Kong has no equivalent console and relies on the Admin API and files managed through decK. Third, assess in-house operating skill for upgrades, backups, TLS and high availability. Fourth, check the release line: the open-source repository's newest series is 3.9, with 3.9.4 released on October 12, 2026, while Kong Gateway Enterprise has moved to quarterly releases. Kong's version support policy covers only Enterprise, so ask Kong what, if anything, it commits to for OSS security fixes before you commit to a long run on 3.9. Before you decide, export your current configuration with decK and confirm the export loads into a test OSS node. Then ask Kong in writing which Enterprise plugins your routes depend on and whether they have OSS equivalents.
Which option fits which buyer situation
This table matches common buyer situations for Kong Konnect against self-run Kong Gateway open source to the option that usually fits better. Read each row against the condition that drives the decision, then confirm the details that depend on your own environment and contract.
| Buyer situation | Better fit | Condition that drives it |
|---|---|---|
| Small platform team with GitOps habits | Kong Gateway OSS in DB-less mode | Configuration lives in declarative files in Git, and decK syncs them to the gateway, so the team needs no database and no console. |
| Team that depends on the Konnect developer portal | Keep Konnect, or plan a portal replacement first | Portal publishing, application credentials and API catalog views are Konnect-side features, so the open-source edition does not provide them out of the box. |
| Team needing Enterprise-only plugins | Kong Gateway Enterprise or another gateway | Plugins outside the open-source set, and any feature the pricing page places in the commercial offering, need a commercial license. Confirm each plugin against the current Kong documentation. |
| Team facing a renewal or price change | Run a cost comparison before deciding | Compare Konnect fees and metered usage with infrastructure, implementation, support and engineering time for the open-source edition. Request a written quote for each path. |
| Team that needs database-dependent plugins such as cluster-strategy rate limiting | Traditional mode with a database, or Kong Gateway Enterprise | Only traditional mode supports database-dependent plugins, so the database and its operations become part of the self-run scope. |
| Team with air-gapped or data residency requirements | Self-run Kong Gateway OSS in DB-less mode | No outside connection is needed for DB-less operation, while Konnect's Kong-hosted control plane cannot run on disconnected networks. Confirm the exact data flows with Kong. |
| Team that needs long vendor support windows | Confirm support terms before choosing open source | Kong's version support policy covers Enterprise only, and the open-source edition has no published support window in the supplied materials. Ask Kong and your internal security team what they will accept. |
Where configuration, traffic and identity live under each option
Moving from Konnect to self-run Kong Gateway open source changes where your gateway configuration, traffic and access records sit. Each card below covers one component you will either stop depending on, keep, or have to run yourself, along with the check to make before you decide.
Konnect's Kong-managed control plane
With Konnect, the control plane that stores your services, routes, consumers and plugin settings is operated by Kong. Metadata about your gateways, such as node registrations, configuration versions and usage counts, leaves your network and is held in Kong's cloud. Ask Kong which metadata is sent, where it is stored and how long it is retained, and map that answer against your data classification rules before deciding.
Self-hosted data planes
The data plane is the set of Kong Gateway nodes that receive and forward API traffic. Open-source nodes run in your own Docker, Kubernetes or Linux hosts, so request payloads stay inside your network path. You own patching, scaling, TLS certificate rotation and node health checks. Confirm which of these your platform team already runs for other services.
DB-less mode keeps configuration in Git
In DB-less mode Kong reads declarative files and needs no database, so the source of truth becomes a Git repository that your change process reviews. The Admin API is read-only, which means changes go through pull requests rather than live edits. Plugins that depend on a database, such as cluster-strategy rate limiting and OAuth2, are not available in this mode, so check your policy list first.
Traditional mode and the database to back up
Traditional mode stores configuration in a database, which is required for database-dependent plugins and for runtime changes through the Admin API. That database becomes a production system with its own backup schedule, restore test, failover design and upgrade path. Document recovery time and recovery point objectives with your database team, because a lost database means lost gateway configuration unless you have exported it.
Dedicated Cloud Gateway hosting choice
Konnect offers Dedicated Cloud Gateways that Kong fully manages on AWS, Azure or GCP, which is a middle option between self-hosting and Konnect's control plane. If you keep Konnect for this, the hosting location and the metadata questions above still apply. If you leave Konnect, you take on the same hosting work yourself, so compare the cloud accounts, network paths and operating staff each option needs.
Compliance evidence you produce yourself
Open-source Kong Gateway gives you no vendor-supplied support window or managed audit trail, so access logs, change records, backup test results and patch dates must be collected by your team. Auditors and certification bodies issue any reports or attestations, and DeployOpen prepares the systems and evidence for them. Agree with your assessor which control owner produces each artifact before go-live.
What the 3.9 open-source line means for upgrades and security patches
The newest release line of the open-source Kong Gateway repository is 3.9, so a self-run deployment of Kong Gateway OSS is pinned to that series. Kong's GitHub releases show 3.9.0 on December 13, 2024, 3.9.1 on June 4, 2025 and 3.9.4 on October 12, 2026. Kong Gateway Enterprise reached 3.16 on September 15, 2026 and has shipped quarterly releases since March 2025. The two editions now run on different release tracks, and the gap will keep widening. Features and fixes that land in Enterprise will not appear in OSS unless Kong ships them there.
Kong's version support policy covers only Kong Gateway Enterprise, so it gives no published support window for the open-source edition. Nothing in that policy tells you how long 3.9 will receive security fixes, whether fixes will be backported, or how quickly a vulnerability in a 3.9 component will be patched. Before you run OSS in production, ask Kong in writing for its position on 3.9 security fixes, the expected lifetime of the line and where advisories are published. Read the version support policy to see the Enterprise terms you would be comparing against.
Because no vendor window is published, the patch process falls to your team. Watch the Kong Gateway GitHub releases page, record the exact version and image tag of every data plane node, and map each advisory to the components you run, including the Kong Ingress Controller if you use it on Kubernetes. Set an internal target for applying security patches and test each one in staging. Run deck gateway dump before and after each upgrade and diff the output to catch configuration drift. Decide now whether your own engineers or a support retainer will carry this work, because that decision sets your recurring cost.
How a move from Konnect to self-run Kong Gateway OSS unfolds
The move keeps your existing routes, services and open-source plugins by exporting them from Konnect and loading them into a gateway you run yourself. The result is a tested, cut-over gateway in your own infrastructure and a Konnect tenant that can be shut down.
Inventory Konnect features in use
Your team lists every Konnect feature the APIs depend on: the gateway services and routes, consumers and credentials, plugins, the developer portal, analytics dashboards, and any Enterprise-only plugins or Dedicated Cloud Gateways. Each item is marked as portable to open-source Kong Gateway, needing a replacement, or being dropped. The output is a signed-off inventory that shows which Konnect capabilities you will lose and who owns the replacement for each.
Export configuration with decK
An engineer runs decK's gateway dump against the Konnect control plane to produce a declarative file of services, routes, consumers and plugins. The file is reviewed in Git, and plugins that rely on Enterprise features or Konnect-specific settings are flagged for rework. Done means the exported file validates and every flagged item has an owner. The companion how-to page covers the export steps in detail.
Choose DB-less or traditional mode
The platform team selects the deployment mode based on the plugin list. DB-less mode reads declarative files, which can be kept in Git, and has no database, but it does not support database-dependent plugins such as cluster-strategy rate limiting and OAuth2. Traditional mode with a database supports those plugins at the cost of running and backing up PostgreSQL. The decision is recorded in the architecture notes with the reasons, and any plugin that forces the choice is named.
Deploy the gateway in your environment
Engineers install the open-source Kong Gateway with Docker, Docker Compose, Kubernetes or the Linux packages for Ubuntu, RHEL, Debian or Amazon Linux, depending on your standards. They load the exported configuration, set TLS certificates, logging and health checks, and apply hardening and access controls to the Admin API. Confirm the exact open-source release line you will run and its support status before installation, since the open-source edition stays on the 3.9 line. Done means a gateway starts, reports healthy and serves a test route.
Test in parallel with production traffic
The new gateway runs alongside Konnect while test traffic and selected production calls are sent to both. Teams compare response codes, latency, authentication outcomes, rate-limit behavior and transformed payloads against the baseline. Each difference is either fixed in the configuration or accepted in writing by the API owner. Done means the parity checklist is complete and the rollback path has been rehearsed.
Cut traffic over to the new gateway
The team moves client traffic to the self-run gateway in agreed batches, using DNS, a load balancer or an ingress change. Monitoring dashboards and alerts are checked after each batch, and consumers are notified of any change to hostnames or credentials. Done means all in-scope APIs answer through the new gateway and the cutover log records each batch and its outcome. The cutover plan, including timing and rollback criteria, should be agreed in writing before work begins.
Decommission Konnect and archive records
After a stability period agreed with the business owners, Konnect control plane access is revoked and data-plane nodes that were connected to Konnect are removed. Konnect-hosted analytics, portal content and audit logs are exported where your retention rules require. The final configuration is stored in Git as the source of truth. Done means no traffic or administrative access depends on Konnect and the retention record is signed off.
How cost splits between a Konnect subscription and a self-run gateway
The recurring Konnect line is Kong's plan fee plus metered usage for the items Konnect bills, such as services, requests, developer portals and published APIs. Confirm the current plan structure and metering units with Kong before you build a comparison, because those terms change and this page does not quote them. The self-run side replaces that line with costs you pay to other parties: compute and storage for the Kong Gateway nodes and any database, load balancing and TLS in front of them, and the engineers who run the platform. If you keep Konnect's data planes but drop its control plane, you still pay for the data plane hosting, so model that case separately.
Some costs are one-time. These include the migration itself: exporting configuration with decK, translating plugins that exist only in Konnect or Enterprise, building the declarative files in Git, testing traffic in a parallel environment and cutting over. They also include writing runbooks for upgrades, certificate rotation, rollback and incident response, and setting up dashboards and alerts in your own monitoring stack. Costs that recur are hosting, OS and container patching, Kong version upgrades, security hardening reviews, on-call coverage and the time to answer support questions that Konnect's vendor support used to handle. The open-source edition has no published support window in the researched material, so the upgrade cadence and any paid support contract should be written into your own operating model.
Ask for a quote built from a written scope that lists the gateway topology (DB-less or traditional mode, number of nodes, regions), the plugins in use, the monitoring and logging targets, the upgrade policy and the hours of support expected. Ask the implementer to separate one-time build effort from the retainer for ongoing operations, so you can compare it with the Konnect invoice line by line. Your own engineers' time is the cost most often left out, so estimate it from the runbooks and on-call rota you already have, and confirm the Konnect side against your current invoice and Kong's pricing page.
Questions buyers ask before choosing Kong Gateway OSS over Konnect
How much does moving from Konnect to self-run Kong Gateway OSS cost?
The cost depends on what you remove and what you add. Konnect's subscription fee and usage metering end, while infrastructure, implementation, testing, monitoring, backups and ongoing staff time become your responsibility. The main drivers are the number of gateways and environments, how many routes and plugins you must translate, whether you need a developer portal replacement, and whether your team already runs Kubernetes or VM-based infrastructure. Ask any implementation partner for a written quote based on a defined scope, and ask your own finance team to model infrastructure and staff time against your current Konnect invoice. Konnect pricing is set by Kong and should be confirmed on Kong's pricing page before you compare.
How long does a migration from Konnect to Kong Gateway OSS take?
Timing is set by the size of your configuration and the number of teams that depend on it, not by a fixed duration. The steps that usually take the most time are exporting and reviewing services, routes and plugins with decK, deciding how the Konnect control plane, portal and analytics will be replaced, testing each traffic path, and planning the cutover window. Plugins that need traditional mode add design work because they need a database. No duration is promised here; confirm the timeline in writing with the implementation partner once the scope and environments are agreed.
Can our in-house team run Kong Gateway OSS without outside help?
Many platform teams can run it, provided they already operate Linux, containers or Kubernetes, a database if needed, and a deployment pipeline. The harder parts are operational: upgrades, certificate management, observability, high availability, backup of the database in traditional mode, and building the admin workflow that Konnect currently provides. Assess your team against those skills before deciding. You can run the work entirely in-house, or bring in outside help for planning, hardening, documentation or retainer support. Confirm with your own staff which responsibilities they can take on from day one.
Does open-source Kong support DB-less mode, and which plugins need traditional mode?
Yes. In DB-less mode, Kong Gateway needs no database, reads declarative configuration files that can be kept in Git, and exposes a read-only Admin API. Only traditional mode supports database-dependent plugins, such as cluster-strategy rate limiting and OAuth2. If you rely on those plugins, plan for a database and its backup and failover design. Check the plugin list for each route before you choose a mode, and confirm the behavior against the Kong deployment topologies documentation for the exact version you deploy.
Is the 3.9 line safe for production, and how do patches arrive?
The open-source repository's newest release line is 3.9, and its releases are published on GitHub and announced on Kong's forum. The latest 3.9 release listed in the supplied sources is 3.9.4. Kong's version support policy applies only to Kong Gateway Enterprise, so it does not publish a support window for the open-source edition. Ask Kong directly what patch and security commitments apply to 3.9, and decide your own upgrade policy and monitoring for new advisories. Enterprise features and newer lines are not available in the open-source edition.
What does the migration need from our staff?
You will need named owners for API inventory, consumer and credential handling, gateway operations and security review. Your API owners must confirm which routes, consumers and plugin settings are still in use, since some Konnect settings do not carry over automatically. Your security team should review authentication, TLS and admin access, and your operations team should agree on monitoring, alerting and on-call for the gateways. Expect each group to spend time in testing and sign-off. Ask any partner to list these roles in the written scope so the commitments are clear before work starts.
Does DeployOpen issue audit reports for a Kong Gateway deployment?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. In practice, DeployOpen can help document configuration, access controls, change records and logging so your auditor has the evidence it needs. Confirm with your auditor which evidence they expect before the work starts.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Kong Konnect vs Kong Gateway open source, we start by mapping which Konnect features your teams actually use, then decide with you whether a self-run open-source gateway covers them.
How we scope
- We inventory the Konnect services, routes, plugins, consumers and portal features your teams depend on today.
- We confirm your deployment target, whether DB-less or traditional mode, and any requirement to keep traffic inside your network.
- Engagements are fixed-scope, with scope and deliverables agreed in writing before any work starts.
How we build
- We export gateway configuration with decK and review the declarative files for drift and unsupported entries.
- We stand up Kong Gateway open source in your environment, with Git-managed declarative configuration and a tested rollback path.
- We test routing, authentication and rate limiting against your current behavior, and document each plugin that no longer applies.
How we hand over
- You receive architecture notes, runbooks, configuration repositories and a written list of features that were removed or replaced.
- We walk your platform and security teams through upgrades, backups and the process for reviewing open-source release notes.
- Compliance evidence is prepared for your assessors, who decide what it proves. DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover tracking the 3.9 release line, planning any move to a later version, and applying security fixes in your environment.
- Ask us to confirm support windows and upgrade options in writing before you decide between Kong Gateway open source and Konnect.
