Kong Konnect alternative for air-gapped networks

Kong Konnect alternative for air-gapped networks: the short answer

If your API gateway has to run on a network with no route to the internet, Konnect is not an option, because its control plane is hosted by Kong. The path that works is an open-source gateway run without any control plane connection, so the gateway reads its configuration locally and never calls out. Two options fit this pattern well: Kong Gateway OSS in DB-less mode and Apache APISIX in standalone mode. In DB-less mode, Kong reads declarative files and exposes a read-only Admin API, with no database to maintain. In standalone mode, APISIX reads conf/apisix.yaml or conf/apisix.json and hot-reloads changes without a restart, with no etcd cluster involved.

DeployOpen plans and implements either option inside your own network, whether that is a private cloud, a data center or an isolated enclave. The work covers the gateway build, the configuration pipeline that moves files across your approved transfer path, the plugin set for authentication and rate limiting, and the runbooks for updates. DeployOpen does not issue certifications or audit reports. Independent assessors and certification bodies decide whether your environment meets a given standard, and DeployOpen prepares the systems and evidence they will review.

Before you choose, confirm three things with your security team and your gateway vendor. First, which plugins you need, because in DB-less mode database-dependent plugins such as cluster-strategy rate limiting and OAuth2 are not available, so check the Kong deployment topologies documentation for the current list. Second, how your transfer process will carry configuration changes into the enclave. Third, who approves and tests each update, since you will manage every patch yourself. Those answers will decide whether Kong or APISIX fits your enclave more cleanly.

What an air-gapped gateway must do without an outside connection

An air-gapped gateway has to keep serving traffic and accepting changes with no path to a vendor cloud. The four requirements below connect the control plane, configuration, installation and identity or logging, and each one needs a check in your own environment before the design is signed off.

No vendor-hosted control plane

Konnect keeps its control plane in Kong's SaaS, so a disconnected gateway cannot be managed through it at all. The open-source Kong Gateway runs without that dependency, because you choose where its configuration lives and who can change it. Confirm that every component you plan to run, including the portal, dashboards and any licensing check, works with egress blocked. Any feature that phones home is a blocker, so test it on an isolated segment before go-live.

Configuration loaded from local files

In DB-less mode Kong Gateway needs no database and reads its configuration from declarative files, so the whole routing and policy state sits on disk inside your network. Keep those files in an internal Git repository and deploy them through your own change process. Confirm who signs off on a change, how a bad file is rolled back, and that the gateway refuses to load a file that fails validation.

Read-only Admin API for runtime state

In DB-less mode the Admin API is read-only, so runtime changes cannot be made by hand on a live node. Operators can still query the state to confirm what is loaded, which helps during audits and incident response. Plan how changes reach each node and how you verify that every node matches the Git version. Test that monitoring tools can read the endpoint without needing write access.

Offline installation media

Kong's open-source releases install through Docker, Kubernetes or packages for Ubuntu, RHEL, Debian and Amazon Linux, so the installer must be copied into the enclave before work starts. Mirror the container images, Helm charts and OS packages with their checksums, then rebuild them through your own approved pipeline. Ask who maintains the mirror, how new patch releases are imported, and how the Kubernetes ingress controller is kept in step with the gateway.

Local authentication and logging

Consumer authentication, such as JWT, basic auth, OAuth or ACL plugins, must check credentials against sources inside the enclave, not a hosted identity service. Access logs and gateway events should go to a local collector, with retention set by your own policy. Check which plugins need a database in traditional mode, since DB-less mode does not support cluster-strategy rate limiting or OAuth2, and plan rate limits accordingly.

Where Konnect meets the air-gapped constraint and where it does not

This model keeps the gateway nodes inside your network while the control plane stays with Kong. Konnect is a SaaS platform with a Kong-managed control plane, and self-hosted data plane nodes connect to it. Those nodes therefore depend on a live path to Kong's hosted control plane for configuration, so the model does not satisfy a strict air-gap requirement.

Outbound dependency: Data plane nodes must reach the Kong-managed control plane, so a disconnected enclave cannot receive configuration updates.
Control plane location: The control plane, its management UI and its account data are operated by Kong, not inside your network.
Traffic versus management: Client requests can stay local, but changes to routes, plugins and consumers depend on the connection.
Authentication and billing: Konnect access runs through Kong's accounts and metering, which is a separate question from request traffic.
Upgrade path: Keeping nodes current still follows Kong's release line, which the connection must support.

Before committing, ask Kong in writing whether any Konnect configuration can be applied to a data plane without a live connection, and document the answer for your security team.

Which open-source gateways fit a disconnected network

This table compares Kong Gateway OSS in DB-less and traditional modes with Apache APISIX in standalone and decoupled modes, looking at how each meets an air-gapped constraint, what it depends on, and which features drop out. Read the database and etcd column first, because it decides whether the gateway can run with no external store, and then check the plugin and trade-off rows against the policies your gateway must enforce.

Option	How it meets the air-gapped constraint	Database or etcd dependency	Database-dependent plugins lost	Licensing and trade-offs
Kong Gateway OSS, DB-less	Reads declarative files kept locally or in an internal Git server, with no outside connection needed	No database; configuration comes from files	Cluster-strategy rate limiting and OAuth2 are unavailable	Apache-2.0; Admin API is read-only; open-source edition stays on the 3.9 release line
Kong Gateway OSS, traditional	Runs entirely inside the disconnected network with a local database and Admin API	Requires a database that you install, patch and back up yourself	None of the listed database-dependent plugins are lost	Apache-2.0; you own database availability, upgrades and recovery
Apache APISIX, standalone	Loads routes and plugins from a local YAML or JSON file, hot-reloaded on change	No etcd; configuration is file-driven or set through the API	Confirm plugin behavior against your required set, since some plugins depend on shared state	Apache-2.0; Apache Software Foundation project with 3.19.0 as the latest release cited
Apache APISIX, decoupled	Separates data plane and control plane inside your network, so gateways keep serving traffic while the control plane is down	Requires a shared etcd cluster that you operate	Confirm plugin behavior in decoupled mode against your required set	Apache-2.0; more components to monitor, and the downloads page marks no release as long-term support
Support window	Not applicable to the open-source Kong edition or APISIX as a fixed term	Not applicable	Not applicable	Kong's version support policy covers only Kong Gateway Enterprise; ask both projects for their security patch commitments in writing

How to deploy a DB-less gateway with no outside connection

This sequence takes an open-source gateway from an offline software bundle to a tested, documented configuration that runs inside a disconnected network and can be updated through the same controlled transfer.

Build the offline artifact set
Your platform team assembles the software that the air-gapped network needs: Kong Gateway open-source container images or packages for your operating system, decK, and the Kong Ingress Controller if you run Kubernetes. Pull each item from an approved source outside the network, record its exact version and checksum, and stage everything in a transfer bundle. Review the bundle against your change process before it crosses the boundary. The output is a versioned manifest that lists every artifact and its checksum, so you can confirm later that the copy inside the network matches what you approved.
Transfer and mirror artifacts internally
Move the approved bundle across the boundary using your existing media or diode process, then load the images or packages into an internal registry or package mirror. Verify each checksum against the manifest from the previous step before anything is installed. Confirm that the cluster or hosts can pull only from internal sources. The check that closes this step is a test install on an isolated host that succeeds with no outbound network access, which confirms that no hidden dependency reaches out to the internet.
Create the internal Git repository for declarative files
Set up an internal Git repository that holds the gateway's declarative configuration: services, routes, consumers and plugins written in the YAML that Kong Gateway reads in DB-less mode. Protect the main branch with reviews, so every change to routing or authentication is approved by a second person. Store environment-specific values such as upstream addresses separately from the shared definitions. The output is a repository with a first committed configuration file that validates locally.
Load configuration with decK and the declarative file
Run decK against the local gateway to validate and sync the declarative file, which the gateway loads at startup in DB-less mode. Because the gateway needs no database, it reads its configuration from that file and exposes a read-only Admin API, so changes are made by editing the file and reapplying it. Use the same commit that the team reviewed. The check is a successful sync followed by a request through the gateway to a test upstream, with the response confirmed against the expected route. Note that database-dependent plugins such as cluster-strategy rate limiting are not available in this mode, so confirm your required plugins before choosing it.
Restrict the Admin API to management networks
Bind the Admin API to an internal management interface and limit access with firewall rules so that only the platform team's management hosts can reach it. Client traffic should use a separate listener on the data plane network. Confirm that the Admin API cannot be reached from application networks by running a connection test from a client subnet. Record the listener settings and firewall rules in the configuration repository so the restriction is reviewable and repeatable.
Run health checks and the APISIX alternative test
Verify the running gateway with health checks on each node and on the upstream services it routes to, then confirm that a failed upstream is removed from rotation. If you evaluate Apache APISIX in standalone mode, the equivalent file is conf/apisix.yaml or conf/apisix.json, which APISIX checks for changes every second and hot-reloads without a restart. Test that a change to the file takes effect within that interval. The output is a test report showing passing health checks, route tests and, where relevant, the hot-reload result, which becomes your acceptance evidence.
Document and rehearse the offline update path
Write a runbook that describes how a new gateway version, plugin change or configuration update moves through the same offline transfer: build the artifact set, verify checksums, load the internal mirror, commit the configuration, sync with decK and run the health checks again. Keep the runbook with the repository and assign an owner for each step. Rehearse one update on a non-production copy of the network. The check that closes this step is a signed-off runbook and a rehearsal record that show the update can be applied without any outside connection.

Why DB-less mode and APISIX standalone mode remove the control plane

Both open-source gateways can run with no database, no etcd and no link to a remote control plane, which is what makes them workable on disconnected networks. In Kong Gateway, DB-less mode reads its entire configuration from declarative files, which can be kept in Git and copied into the enclosed network through your own approved transfer process. The node exposes a read-only Admin API, so operators can inspect the running configuration but cannot change routes or plugins through it. Changes happen by editing the declarative file and reloading the node. In APISIX, standalone mode works the same way in principle: there is no etcd cluster, and the gateway loads routes and plugins from conf/apisix.yaml or conf/apisix.json. It checks those files every second and hot-reloads them without a restart.

The traditional APISIX deployment, by contrast, depends on etcd and is the mode that exposes the Admin API on port 9180 alongside client traffic on port 9080. Confirm in your own build which listeners are bound and restrict port 9180 to the operators who need it, or disable it in standalone mode if your change process does not use it. The main trade-off is plugin support. In Kong, cluster-strategy rate limiting and OAuth2 depend on a database, so they require traditional mode and cannot run in DB-less mode. If your API design depends on either, plan for a database-backed node inside the enclosed network, or replace those controls with alternatives that the chosen mode supports. Test each plugin your APIs use in the exact mode you intend to deploy before committing to it.

Evidence an assessor will ask for from an offline gateway

An assessor reviewing an air-gapped gateway will want to see how configuration was produced, what crossed the air gap, who could change the gateway, and which version is running. The cards below cover the material to prepare for each of these questions. DeployOpen prepares this evidence for your review, but independent auditors and certification bodies issue any audit report.

Declarative configuration under version control

In DB-less mode, the gateway's entire behavior is defined by declarative files, so those files are the primary evidence of what the gateway enforces. Keep them in an internal Git repository with a complete commit history, reviewed merge requests, and a named approver for each change. Check that the running configuration matches the last approved commit, and that decK exports taken from the live gateway reconcile with the repository.

Inventory of artifacts transferred in

Every package, container image, plugin, and configuration file that enters the disconnected network is a change to the trusted base. Record each item with its source, version, and SHA-256 checksum, and keep the transfer approval beside the record. Verify checksums again inside the enclave before installation. Repeating the check on a sample of artifacts after installation strengthens the chain of custody.

Admin API access controls

The Admin API is the most sensitive management surface on the gateway, even in DB-less mode where it is read-only. Document which accounts and network segments can reach it, how access is granted and removed, and how that is enforced by network policy and host firewall rules. Assessors typically ask for a list of permitted identities and the review date for that list, so keep both current.

Internally retained gateway logs

Access logs, error logs, and administrative actions must stay inside the network and be retained for the period your policy sets. Confirm which log destinations you configure, who can read them, and whether they are forwarded to an internal SIEM. Test that a sample request can be traced from the client through the gateway to the upstream service, because that trace is often the first thing an assessor asks to see.

Record of deployed versions

Keep a dated register of which Kong Gateway or APISIX version runs in each environment, which plugins are installed, and which patches were applied. Tie each entry to the artifact checksum and the change ticket that introduced it. Open-source release lines have their own support horizon, so record the version status you confirmed with the project rather than assuming it.

Change and approval records

Assessors look for evidence that gateway changes follow a controlled process: who requested them, who approved them, and whether they were tested before reaching production. Link each configuration commit to a change ticket and a test result. Note any emergency changes and their after-the-fact review. Remember that DeployOpen can prepare this process and its records, but an independent auditor decides whether the controls meet the applicable framework.

Questions buyers ask before running an air-gapped gateway

What does an air-gapped gateway project cost and what drives that cost?

The cost comes from the written scope, so no figure is given here. The main components are the people who design and build the deployment, the infrastructure that hosts gateway nodes in your own data center or enclave, the testing and documentation effort, and the ongoing staff time to operate it. Costs rise with the number of routes and plugins to translate, the high availability design, the number of environments (for example development, test and production), and how many transfer cycles your change process requires. Most of the spend on a self-run gateway is one-time build work plus recurring operations, while the open-source software itself carries no license fee. Ask any provider for a quote that breaks out these components and states what is one-time and what recurs.

How long does it take to move a Konnect gateway into an air-gapped network?

The timeline depends on the written scope, and no duration is given here. Schedule drivers include how many services, routes and plugins must be reproduced, whether the team must build a DB-less configuration workflow from scratch, the number of environments, the high availability design, and how long your approval and media transfer processes take. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Ask for a phased plan with clear acceptance points for each environment rather than a single cutover date.

Can our own platform team run an air-gapped Kong gateway without outside help?

A capable team can, but it needs skills across several areas. Engineers must be comfortable with Kong's DB-less declarative model, exporting configuration with decK, Kubernetes or Docker operations, Linux package handling, TLS certificate management, and monitoring without SaaS dashboards. Someone must own the gateway configuration in Git, and the team needs a tested way to restore a node from files alone. Compare your staff's experience with these tasks against your timeline and on-call capacity before deciding. Many organizations split the work, keeping day-to-day operations in-house while buying design, hardening or upgrade support as a retainer.

How do software updates and security patches reach a disconnected network?

In an air-gapped network, nothing updates automatically, so your team must define a controlled transfer process. Packages, container images, and Kong Ingress Controller or decK binaries are downloaded on a connected staging system, checked against published checksums, scanned, and then moved across through your approved media or cross-domain process. Track release lines carefully: the open-source Kong Gateway repository's newest release line is 3.9, and Kong's version support policy applies only to Kong Gateway Enterprise, so confirm the support window for any edition you choose. Build a regular review cycle, test each update in a staging enclave, and keep a rollback plan.

Which Konnect features, such as the developer portal and analytics, can be replaced offline?

Some can be replaced, but the gateway itself is only one part of Konnect. Routing, authentication plugins such as JWT, OAuth and ACL, rate limiting and transformations can run in open-source Kong Gateway in DB-less mode, with configuration kept in Git. A Kong-hosted control plane, Konnect analytics dashboards and the Konnect developer portal do not run in a disconnected network, so you must choose substitutes such as log and metrics pipelines you already operate, a self-hosted portal, or an API catalog. Note that database-dependent plugins such as cluster-strategy rate limiting need traditional mode. List every Konnect feature your teams use today before scoping replacements.

Does a self-hosted control plane change our compliance evidence?

It can, because you become responsible for producing the evidence yourself. Running the control plane inside your boundary keeps configuration, logs and access records under your own controls, which can simplify data handling reviews. However, DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ask your assessor early which evidence they expect, such as configuration history in Git, access logs and change approvals.

Does a self-hosted gateway need Kong Gateway Enterprise for a fully self-hosted control plane?

Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane are part of the commercial Kong Gateway Enterprise offering. Open-source Kong Gateway in DB-less mode avoids a control plane altogether, because configuration is loaded from declarative files. Confirm with Kong which features you need, especially if you require a management interface, role-based access or enterprise plugins, since those may only be available in the commercial edition.

What moving off Konnect involves for an offline estate

The migration starts with a complete export of what Konnect holds for you, and for an offline estate that export has to happen while the current gateways are still reachable from a connected workstation. Use decK's deck gateway dump command to pull services, routes, consumers and plugins into a declarative file, then review that file by hand, since it captures only the gateway configuration and not the Konnect portal, analytics or any credentials held in Konnect's own control plane. Confirm with your Kong account team which Konnect-only items your estate actually uses, and record the consumer credentials you will need to reissue, because they will not travel in a dump.

The next decision is the target. A self-run DB-less Kong Gateway OSS deployment reads its configuration from declarative files and exposes only a read-only Admin API, so the file you exported becomes the system of record and can be transferred into the enclave on approved media. Plugins that depend on a database, such as cluster-strategy rate limiting and OAuth2, are not available in DB-less mode, so list them early and decide whether to redesign them or move to Apache APISIX, whose standalone mode also runs from a YAML or JSON file without etcd. Translate consumers and plugin settings into the target's format, validate each route against a test upstream inside the enclave, and keep the exported Konnect configuration under version control for audit.

The cutover plan has to keep the network disconnected at every step, so the old control plane must never be a dependency during the switch. Run the new gateway in parallel on a staging segment, replay representative traffic, then move production traffic by changing the upstream routing or DNS inside the enclave, with a documented rollback that points back to the existing gateway until the new one is confirmed. Agree with your security team how configuration changes will be approved, signed and transferred, and confirm the image or package source you will use, since no outbound pulls are possible. For the step-by-step sequence of each target, read the sibling migration pages on Kong Gateway OSS and the APISIX pages in this hub, and ask your implementation partner to put the transfer and rollback steps into the written scope.

Risks to plan for when a gateway runs disconnected

A gateway with no outside connection loses the conveniences of a SaaS control plane and takes on duties that the vendor otherwise handles. The cards below cover what goes missing, where DB-less mode limits functionality, how updates reach the network, and which release line you are committing to.

Losing the vendor console and analytics

Konnect supplies the management console, dashboards and usage analytics from Kong's cloud, and none of that reaches a disconnected network. In a self-run deployment you rely on the Admin API, exported configuration and your own logging and metrics stack. Confirm which dashboards, alerts and audit reports your operations and compliance teams need, then assign an owner for building or buying each one before cutover.

Plugin gaps between DB-less and traditional mode

DB-less mode reads declarative files and exposes a read-only Admin API, but database-dependent plugins such as cluster-strategy rate limiting and OAuth2 need traditional mode. Map every plugin your APIs use to a deployment mode before choosing a topology. If a rate limit or token flow must be enforced across nodes, plan for a database inside the enclave and test the failover behavior there.

Manual update media handling

Without an outside connection, patches and new packages arrive by approved media or an internal mirror, and each transfer needs hash verification and a change record. Agree on the intake process with your security team, including who scans the packages and where they are staged. Ask your team to confirm how long a patch takes to move from upstream release to tested production in your own change process.

Declarative configuration drift

In DB-less mode the Git repository holding declarative files is the source of truth, so a manual change made directly on a node disappears at the next sync or leaves nodes inconsistent. Keep deck files in an internal Git service, require reviewed merges, and check that every node reports the same configuration hash. Confirm how your team detects a node that has drifted from the approved files.

Open-source release line and support window

The open-source Kong Gateway repository's newest release line is 3.9, while Enterprise moves ahead on quarterly releases. Kong's version support policy applies only to Enterprise, so the open-source edition has no published support window. Before committing, confirm with Kong or your own support provider how security fixes reach the 3.9 line, and set a review date for whether to stay on it.

Staffing for self-run operations

Konnect's operations work, including upgrades, certificate rotation and capacity changes, moves to your team when the gateway is disconnected. Name the people who will hold on-call duty, run the update process and maintain the backup of configuration and keys. Ask for a written runbook covering each of those tasks, and rehearse a restore from backup inside the enclave before go-live.

How DeployOpen deploys open-source gateways on air-gapped networks

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source gateways inside the client's own infrastructure, including air-gapped networks. For a Konnect replacement on a disconnected network, the work centers on running the gateway in DB-less mode from declarative files that the client controls and can review.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
The written scope names the gateway edition, the deployment mode, the routes and plugins to carry over, and the target network zones
We confirm which Konnect features the client actually uses, such as portals, analytics and Enterprise plugins, so gaps are documented before cutover

How we build

We install the gateway from artifacts the client has approved and mirrored inside the disconnected environment, including container images and packages
We convert exported decK configuration into version-controlled declarative files, and test them in a staging environment with no outside connection
We harden the Admin API, restrict access to the read-only interface, and test authentication, rate limiting and logging against the written scope

How we hand over

The handover includes architecture notes, the configuration repository, runbooks for config changes and upgrades, and a list of known gaps
We document how the client pushes approved changes through its own offline review and promotion process
We walk the client's operations and security staff through deployment, rollback and evidence collection for their compliance readiness work

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope
Upgrade plans cover new open-source releases, mirrored offline, and tests of the configuration before each change is promoted
Independent auditors and certification bodies perform any formal assessment; DeployOpen prepares the systems, controls and evidence for it