Kong Gateway deployment modes: which one fits your team
If you must run a self-managed Kong Gateway in production, the topology decision depends on one question first: do you depend on plugins that need a database? If yes, traditional mode is the only option Kong's deployment topologies documentation supports for those plugins. Every node connects to the same database and acts as both control plane and data plane, which keeps the configuration model simple but means a compromised node can expose the whole gateway configuration. Choose it only if your team already runs shared-database operations well, can secure the database and Admin API tightly, and accepts that node-level exposure. Confirm which plugins you need, such as rate limiting in cluster mode, against the Kong Gateway deployment topologies documentation before you commit.
If your team manages gateway configuration through Git and pipelines, DB-less mode fits well. There is no database to operate, configuration is always in a known state, and the topology suits CI/CD workflows. The trade-off is that the Admin API is read-only, and plugins that store data in the database do not fully function. Ask your platform owners whether any change must happen at runtime outside a deployment, and whether the plugins on your list keep working without a database. If they do not, DB-less is the wrong choice regardless of how appealing the GitOps model looks.
Hybrid mode is the choice for multi-location deployments. Only control plane nodes connect to the database, and data planes can run in different locations without a local database. In Kong's documentation, data planes keep running if a control plane goes offline, which is the resilience property most teams are really buying. Plan for the control plane database as the critical dependency, since configuration changes stop while it is down. Hybrid also works with Konnect, Kong's hosted control plane, which is a separate option you can evaluate instead of running your own control plane. Before you choose, confirm with Kong whether your edition, whether open-source 3.9 or Kong Gateway Enterprise, supports each topology and plugin on your list, because support can differ between them.
Kong Gateway deployment modes side by side
This table compares traditional, DB-less and hybrid Kong Gateway modes across storage, database needs, failure behavior, node exposure, CI/CD fit and Konnect support. Read each row as a constraint to test against your own plugins and failure tolerance, and confirm any cell tied to edition or version before you commit.
| Factor | Traditional mode | DB-less mode | Hybrid mode |
|---|---|---|---|
| Where configuration is stored | In the shared database that every node connects to | In memory on each node, loaded from a declarative file | In the database on control plane nodes only; data planes receive it from the control plane |
| Database required | Yes | No | Yes, on control plane nodes only |
| Plugins that need a database | Supported, and this is the only topology that supports them | Not fully functional, such as rate limiting in cluster mode | Supported on the control plane side, confirm per plugin for data plane behavior |
| Behavior when the database fails | Nodes depend on the database for configuration, so confirm recovery steps with your deployment | Not applicable, since no database is used | Data planes keep running if a control plane goes offline, so traffic continues while the control plane is restored |
| Security exposure per node | Each node acts as both control plane and data plane, so a compromised node can expose the whole gateway configuration | Admin API is read-only, which limits what a compromised node can change | Data plane nodes hold no database, and control plane nodes are the only ones connected to it |
| CI/CD fit | Workable, but configuration changes go through the shared database and need more coordination | Strong fit, since configuration is always in a known state and suits pipeline-driven deployment | Good fit for central changes pushed to many locations, confirm rollout tooling with your pipeline |
| Works with Konnect | No, self-managed only | No, self-managed only | Yes, works with both Konnect and self-managed Kong Gateway |
| Edition or version dependencies | Confirm Kong Manager throughput impact on Enterprise traditional nodes | Confirm which plugins your edition and version support in DB-less mode | Confirm supported version pairing and Kong Manager placement for your Enterprise release |
How each Kong Gateway deployment mode is built
Kong Gateway self-managed deployments fall into three topologies: traditional, DB-less and hybrid. What separates them is where configuration lives, which nodes touch the database and where the Admin API and Kong Manager sit. Read each card against the node layout you plan to run, because the same plugin or pipeline can behave differently across these shapes.
Traditional mode nodes
Every traditional node connects to the database and acts as both control plane and data plane. Each node serves proxy traffic and also holds the Admin API and Kong Manager that change configuration. The consequence is a compromised node can expose the whole gateway configuration, so check which network segments can reach the Admin API on every node. Traditional mode is also the only topology that supports plugins requiring a database, so confirm your plugin list before you choose it.
DB-less mode data planes
In DB-less mode there is no database to manage, and each node holds its configuration in memory. The Admin API is read-only, so changes come from declarative configuration applied through your pipeline rather than live edits on the node. Configuration is always in a known state, which suits CI/CD workflows. Plugins that store data in the database, such as rate limiting in cluster mode, do not fully function, so test each plugin against this mode before committing.
Hybrid control plane nodes
In hybrid mode, control plane nodes are the only nodes that connect to the database. They hold the Admin API and Kong Manager, so administrators and automation interact with them. Keeping the database connection on this smaller set of nodes narrows the database attack surface. Confirm which control plane nodes your operators can reach, and plan how you will protect the database credentials they hold.
Hybrid data plane nodes
Hybrid data plane nodes run without a local database and receive configuration from a control plane. They can be deployed in different locations, which helps when proxy traffic must stay close to applications. Data planes keep running if a control plane goes offline, so check how long each site must serve traffic without control plane access, and confirm how new configuration reaches data planes after an outage ends.
What happens to traffic when a control plane or database fails
In hybrid mode, a control plane outage does not stop traffic. Kong's deployment topologies documentation states that data planes keep running if a control plane goes offline, and only the control plane nodes connect to the database. That shrinks the database's blast radius: a database fault stops configuration changes on the control plane, while data planes that already hold their configuration keep proxying requests. In traditional mode, the picture is different. Every node reads and writes the shared database, so a database failure affects the whole gateway, and every node also acts as both control plane and data plane. Confirm with your own load tests how long each data plane retains its last known configuration in your environment, and document that window for your change and incident runbooks. Note that hybrid mode is available only with Konnect or self-managed Kong Gateway, and traditional mode is self-managed only.
Hybrid mode moves the database risk to a different place rather than removing it. The control plane database still needs a highly available design, and the platform team must provide that layer. PostgreSQL does not detect a primary failure or notify a standby on its own, and its documentation states that automatic failover needs external tools. Decide which HA tooling will detect failure, fence the old primary and promote a standby, and test that promotion against a live control plane. Also decide how connections are pooled, since PgBouncer is one option to evaluate, and confirm its behavior with the Kong control plane version you will run. Treat these as design decisions to confirm, not defaults.
For the database tier, plan around PostgreSQL 14, which is listed as supported until November 12, 2026 according to the PostgreSQL versioning policy. If your control plane database is on 14, that date is a planning input: a major upgrade needs a rehearsed path, and logical replication can shorten the downtime window for that upgrade. Ask your Kong account team or your deployment partner to confirm which PostgreSQL versions your target Kong Gateway release supports before you choose a version.
Which topology fits each team situation
Some teams depend on plugins that store state in the database, with rate limiting in cluster mode as the common example. Kong's deployment topologies documentation says traditional mode is the only topology that supports plugins requiring a database. DB-less mode does not fully support these plugins, so a team that needs them should not choose DB-less for that reason alone. Hybrid mode keeps a database behind the control plane, but confirm with Kong whether a specific database-backed plugin behaves as you expect on hybrid data planes before you rely on it.
- Traditional mode fits best: every node reads and writes the shared database, so database-backed plugins have the full model they were designed for.
- Hybrid mode is the alternative: only control plane nodes connect to the database, which reduces database exposure, but plugin behavior on data planes must be verified for your version.
- Operating effort rises with the database: you own PostgreSQL availability, backups, upgrades and failover, and PostgreSQL does not detect primary failure or fail over on its own.
- Security exposure is wider in traditional mode: each node acts as both control plane and data plane, so a compromised node can expose the whole gateway configuration.
- Confirm before committing: the exact plugins you need, their behavior in the topology you choose, and the Kong version your support contract covers.
Before committing, test each database-backed plugin in a staging copy of your chosen topology under your expected traffic.
Teams that manage gateway configuration as code often want the running state to match what is in version control. Kong's documentation says DB-less mode has no database to manage, keeps configuration in a known state and suits CI/CD workflows. The trade-off is that the Admin API is read-only in DB-less mode, so every change must flow through the declarative configuration and the pipeline that applies it.
- DB-less mode fits this model: configuration is loaded from declarative files, so a pipeline can review, test and promote changes like any other artifact.
- Operational effort is lower: no database to back up, patch or fail over for the gateway itself, though the pipeline and its secrets become critical.
- Hot changes need a process: because the Admin API is read-only, emergency edits must go through the repository and the deployment path, so agree that process before go-live.
- Database-backed plugins are excluded: if your pipeline depends on cluster-wide rate limiting or similar state, DB-less mode will not cover it.
- Confirm before committing: how your pipeline reloads configuration, how rollbacks work and who can approve changes to production gateways.
Write down the rollback path for a bad configuration commit and test it before you rely on DB-less mode in production.
Organizations with several data centers, cloud accounts or edge sites need data planes close to their workloads without placing a database in every location. Kong's documentation says hybrid mode lets data planes run in different locations without a local database, and that data planes keep running if a control plane goes offline. This makes hybrid mode the usual fit for distributed footprints, with the control plane kept in a central, well-protected location.
- Hybrid mode fits distributed footprints: only control plane nodes connect to the database, so edge data planes carry no database dependency.
- Local survival matters: data planes continue serving traffic during a control plane outage, but they cannot receive new configuration until it returns.
- Operating effort is concentrated: the control plane, its database and the certificates that link them need careful lifecycle management across sites.
- Network design needs attention: plan how data planes reach control plane nodes across each boundary, and how that path is secured and monitored.
- Confirm before committing: your Kong version and its support window, how certificates are rotated across sites and which plugins run on remote data planes.
If an edge site must run database-backed plugins, validate that case separately, since that is outside what the standard hybrid pattern covers.
Some teams prefer to have Kong operate the control plane and keep only data planes in their own infrastructure. Kong's documentation lists Konnect as a topology alongside hybrid, traditional and DB-less, and says hybrid mode works with both Konnect and self-managed Kong Gateway. Traditional and DB-less modes are self-managed only. Kong Konnect is Kong's cloud control plane for managing gateways across environments.
- Konnect removes control plane operations: you do not run the control plane database or its upgrades yourself, which lowers day-to-day effort.
- Data planes stay in your network: traffic is still processed where you deploy the gateway, so confirm which data plane components leave your boundary.
- Data residency and access need review: confirm where control plane metadata is stored and who in Kong can reach your tenancy.
- Self-managed traditional and DB-less are not options here: hosted control plane use points to hybrid mode.
- Confirm before committing: Konnect pricing and terms in writing, the regions available, the audit logs you receive and how Konnect fits your change control.
Ask Kong for its current data handling documentation and reconcile it with your own policies before you sign.
Upgrades, backups and monitoring for each topology
This table compares the day-two work of each self-managed Kong Gateway topology: upgrades, what must be backed up, where monitoring attaches and which skills each mode needs. Read it as a checklist of what your team will own after go-live, then confirm the PostgreSQL and Kong-specific details in your own test environment.
| Operating area | Traditional mode | DB-less mode | Hybrid mode |
|---|---|---|---|
| Upgrade sequencing | Every node shares one database, so upgrade order and schema migration must be planned for the whole cluster before any node moves. | No database to migrate. Replace stateless nodes in a rolling sequence and reload the declarative file, which keeps each node's state known. | Upgrade control plane nodes against the database, then data planes. Confirm the supported version pairing in Kong's documentation before sequencing. |
| What must be backed up | The PostgreSQL database holds the full gateway configuration, so database backups and point-in-time recovery are the core control. | The declarative configuration file in version control is the source of truth. Backing up the file and its CI/CD pipeline covers the configuration. | The PostgreSQL database behind the control plane nodes. Data planes hold no local database, so their recovery depends on redeploying from the control plane. |
| Backup method to confirm | PostgreSQL continuous archiving and point-in-time recovery, with restore tests run on a schedule. Confirm retention and recovery targets with your own team. | Source control history and artifact retention for the declarative file, plus the pipeline that applies it. | PostgreSQL continuous archiving and point-in-time recovery on the control plane database. Confirm how data plane redeployment is rehearsed. |
| Kong Manager placement | Running Kong Manager on Enterprise traditional nodes can reduce their throughput, so placing it on separate nodes should be tested before production. | Kong Manager reads from the in-memory configuration and read-only Admin API. Confirm which admin functions your workflow still needs. | Keep Kong Manager on control plane nodes where possible, so data plane throughput is not shared with the admin interface. Confirm this against Kong's guidance. |
| PostgreSQL database upkeep | Minor updates replace executables and restart the server. Major upgrades need a dump and restore, pg_upgrade, or logical replication path, each with its own rehearsal. | Not applicable to gateway nodes. Teams with no database have no PostgreSQL patch cycle for this topology. | Minor updates and major upgrades apply to the control plane database. Logical replication allows major upgrades with only seconds of downtime, per PostgreSQL's upgrading documentation, but this needs testing. |
| Monitoring points | Database health, replication lag if standbys exist, node health, and admin API responses from each node. | Data plane request health, configuration load status from the file, and whether the rollout matches the committed version. | Control plane database health, control plane to data plane connectivity, and data plane health even when a control plane goes offline. |
| Plugin limits that affect operations | Database-backed plugins such as rate limiting in cluster mode depend on the database being available and performing well. | Plugins that store data in the database do not fully function, so operational counters need a different design. | Database-backed plugins run against the control plane database. Confirm which plugins are in scope and how they behave when the control plane is unreachable. |
| Skills each mode needs | Kong administration plus PostgreSQL administration, including backup, restore, replication and upgrades. | Kong configuration, CI/CD and version control discipline. No database administration is required for the gateway itself. | Kong administration, PostgreSQL administration for the control plane, and network design for data plane reach. |
How to choose a topology and plan a move between modes
This sequence turns the topology choice into a written, testable decision, so the team knows which mode fits its plugins, change process and failure tolerance before any production cutover.
Inventory plugins and authentication methods
The platform or security lead lists every plugin and authentication method the gateway must run, including rate limiting, OpenID Connect, JWT, basic auth, OAuth and ACL. For each one, check the Kong plugin documentation for whether it stores data in the database and whether it is an Enterprise-tier plugin. Traditional mode is the only topology that supports plugins that require a database, while DB-less mode does not fully support cluster-mode rate limiting. This step is done when every required plugin is marked database-dependent or not, with the edition it needs written beside it.
Decide how configuration changes are made
The team decides whether routes and services will change through the Admin API or through a declarative file stored in version control and applied by the pipeline. DB-less mode keeps configuration in a known state and fits CI/CD, but its Admin API is read-only, so every change must pass through the file. Hybrid and traditional modes accept runtime changes through the Admin API. Record who approves a change, where the file lives and how a bad change is reverted. This step is done when the change path is documented and the pipeline owner has signed it off.
Map failure domains and locations
The architect draws each location where gateway nodes will run, such as separate cloud regions, data centers or air-gapped segments, and marks which nodes depend on a database. In hybrid mode, only control plane nodes connect to the database, and data planes keep serving traffic if a control plane goes offline. In traditional mode, each node is both control and data plane, so a compromised node can expose the full configuration. This step is done when a diagram shows each failure domain, the database dependency and the blast radius of one compromised node.
Confirm edition and release line
The platform owner confirms whether the team runs the open-source Kong Gateway line or Kong Gateway Enterprise, and which release or LTS line it will pin. Check Kong's version support policy for the current latest release, LTS windows and end-of-support dates, and confirm with Kong which features each edition includes for the chosen topology, including Konnect as the hosted control plane option. Hybrid mode works with both Konnect and self-managed Kong Gateway, while traditional and DB-less are self-managed only. This step is done when the edition, release line and support end date are written into the plan and the vendor has confirmed the feature set in writing.
Size the PostgreSQL tier and its high availability tooling
The database owner sizes the PostgreSQL instance for the control plane or traditional nodes, and chooses a major version that is still in support for the planned life of the deployment. PostgreSQL supports hot standbys, synchronous and asynchronous replication, but it does not detect a primary failure or promote a standby by itself, so the team must pick and test external failover tooling. Decide whether a connection pooler such as PgBouncer is needed and who patches the database on which schedule. This step is done when the database topology, failover tool, backup method and patch owner are documented and a failover has been rehearsed in a lab.
Run a non-production pilot
The team builds the chosen topology in a non-production environment that mirrors production plugins, routes and failure domains. It runs real traffic patterns through the gateway, applies configuration changes through the intended path, and simulates a control plane outage, a node loss and a database failover. Results are compared against the requirements from the first four steps. This step is done when each test has a recorded result, any gaps have an owner and a fix, and the pilot team agrees the topology meets the written requirements.
Plan a test cutover and rollback path
Moving between modes changes where configuration lives, so the team writes a cutover runbook that exports the current configuration, loads it into the target mode, switches traffic in stages and keeps the previous topology available until the new one is verified. The rollback path names the trigger, the owner and the steps to restore the prior configuration and routing. The team rehearses the cutover and rollback in staging before production. This step is done when a rehearsed rollback has restored the previous state and the runbook is approved by operations and security.
Contract the work as a fixed-scope written plan
Once the topology, pilot results and cutover runbook are agreed, the buyer asks any implementation partner for a fixed-scope written plan that lists scope, deliverables, acceptance tests and the handover documentation. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and ongoing support or upgrades can be added as a retainer. Ask for the same written detail from any other provider. This step is done when the signed scope matches the tested design and the acceptance criteria are measurable.
Security exposure and plugin limits to check before you commit
Four risks in Kong Gateway's topologies should shape the decision before any node is provisioned. Each one follows from where configuration lives, who can change it, and which plugins depend on a database. Check each item against your own threat model and the edition you plan to license.
Compromised node exposes the whole configuration
In traditional mode, every node acts as both control plane and data plane. The Kong deployment topologies documentation notes that a compromised node can expose the whole gateway configuration. Ask your team how node credentials, Admin API access and database credentials are isolated, which network paths reach the Admin API, and how a node is rebuilt after suspected compromise. If that exposure is unacceptable, hybrid mode separates the database-connected control plane from data planes that do not hold one.
Read-only Admin API in DB-less mode
In DB-less mode the Admin API is read-only, so changes must come from the declarative configuration you deploy. This suits a pipeline that treats configuration as code, but it removes the option of making an emergency change through the API on a running node. Confirm with your operations team how a routing or key rotation fix reaches production, who approves it, and how the rollback path is tested before an incident forces its use.
Database-backed plugins degrade without a database
Plugins that store state in the database, such as rate limiting in cluster mode, do not fully function in DB-less mode. A limit that counts requests per node rather than across the cluster can behave very differently from the policy your API contracts describe. Ask the vendor and your own test environment to confirm which plugins in your design depend on shared state, then decide whether to use traditional mode, hybrid mode or a different limiting approach for those routes.
OpenID Connect requires an Enterprise license
Kong's OpenID Connect plugin is an Enterprise-tier plugin and is not part of the open-source gateway. If your authentication design depends on OIDC at the gateway, the open-source 3.9 line cannot meet that requirement alone. Ask for the Enterprise edition terms in writing, confirm which Kong Gateway release line your edition supports, and check the support windows in Kong's version support policy before you choose a topology that assumes this plugin.
Kong Gateway deployment modes: what it costs and who runs it
What actually drives the cost of each Kong Gateway deployment mode?
The main cost drivers are node count, the number of locations, the database tier and the plugin set. Traditional mode costs most in database operations, because every gateway node depends on the shared database for configuration and for database-backed plugins. DB-less mode removes the database to manage, but adds cost in your CI/CD pipeline and in managing configuration as files. Hybrid mode adds a control plane and its database, plus the work of certificates and connectivity between control and data planes. Ask any quote to break out the database tier, the number of data plane locations, the plugins in use, and the CI/CD integration as separate line items. Figures for Kong licensing depend on your edition, so confirm current terms with Kong directly.
Can an internal team run Kong hybrid mode without outside help?
A capable platform team can run hybrid mode, provided it already operates PostgreSQL, TLS certificates and Kubernetes or VM fleets. Kong's topology documentation shows that only control plane nodes connect to the database, and data planes keep serving traffic if a control plane goes offline, which reduces the blast radius of database trouble. The hard parts are certificate lifecycle between control and data planes, upgrade ordering across nodes, and runbooks for database failover, since PostgreSQL does not detect a failed primary or notify a standby on its own and needs external tooling. If your team has no one who owns those pieces, plan for that gap before you commit to a topology.
How long does it take to move a Kong Gateway between deployment modes?
The duration depends on the number of routes, plugins, consumers and credentials that must be exported and re-validated, and on how many environments must change in sequence. Moving from traditional mode to DB-less or hybrid mode means exporting configuration, reviewing which plugins depended on the database, and rehearsing the cutover in staging. Moving into DB-less mode also changes how the Admin API behaves, because it is read-only, so operational scripts must be rewritten. No supplied source gives a standard duration, so ask for a written migration plan that lists each environment, the rehearsal window and the rollback path before agreeing to any timeline.
What skills does a self-managed Kong topology require from our staff?
Staff need working knowledge of the Kong Admin API, declarative configuration, TLS and certificate management, and the specific database engine Kong uses. For hybrid mode, add control plane and data plane connectivity, and for DB-less mode, add version control and CI/CD pipelines that render and validate declarative files. Engineers also need to understand the plugin model, including Lua, Go and JavaScript plugins, and which plugins need a database. Security staff should review the traditional mode exposure, where each node acts as both control plane and data plane, so that a compromised node can expose the whole gateway configuration. Use these areas to build a skills matrix against your own team before choosing a mode.
When is DB-less mode a poor fit for Kong Gateway?
DB-less mode is a poor fit when your design depends on database-backed plugins or on runtime changes through the Admin API. Kong's documentation says the Admin API is read-only in DB-less mode, and plugins that store data in the database, such as rate limiting in cluster mode, do not fully function. It is also a weaker match when your change process cannot tolerate rendering configuration from files, or when your teams expect to edit routes live during incidents. Teams that need a central control point for many gateways may find hybrid mode a better match. Confirm plugin behavior against the Kong documentation for the exact version you plan to run.
Does Kong Konnect remove the database work from a self-managed deployment?
Konnect is Kong's hosted control plane, so using it moves control plane operation to Kong, while the data planes still run in your infrastructure. Kong's topology documentation notes that hybrid mode works with both Konnect and self-managed Kong Gateway, so Konnect does not remove the need to plan data plane placement, network paths and certificates. It also does not change which plugins depend on a database, so review plugin requirements before assuming the hosted control plane covers them. Confirm with Kong which data residency, network and support terms apply to your environment, because those affect whether Konnect fits a regulated or air-gapped design.
What does a DeployOpen fixed-scope engagement cover for Kong Gateway?
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. For a Kong topology decision, a fixed-scope engagement typically covers the topology choice against your requirements, the deployment in your environment, the CI/CD integration for declarative configuration, the hardening and backup plan, and the runbooks your team will use. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ongoing support and upgrades are available as retainers.
How DeployOpen scopes, deploys and supports Kong Gateway topologies
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Kong Gateway, that starts with choosing the topology that fits your resilience, security and CI/CD requirements, then building and handing over exactly that setup.
How we scope
- Written scope fixes which topology applies to each environment, with the reasons recorded before work starts.
- Scope lists any plugins that need a database, so traditional or hybrid mode is decided against real requirements.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and a quote follows from that scope.
How we build
- Deployment covers the chosen topology, whether traditional, DB-less or hybrid, on your infrastructure with the control and data plane layout written down.
- Declarative configuration for DB-less or CI/CD-driven setups is built and version controlled so each deployment has a known state.
- Hybrid deployments include control plane database connectivity and data plane placement, with tests of behavior when a control plane goes offline.
How we hand over
- Handover documents the topology, node roles, the Admin API and Kong Manager access paths, and the plugins in use.
- Runbooks cover backup and restore for the database where one exists, plus upgrade steps for the Kong Gateway release line you run.
- Security exposure notes explain which nodes hold full gateway configuration and what access controls protect them.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrade planning checks the Kong Gateway support windows for your release line before each change is scheduled.
- Ask in any quote which Kong Gateway edition, topology and Konnect or self-managed control plane the support covers.
