Why Konnect's multi-region control plane conflicts with a strict data residency rule
A strict residency rule that requires every component to stay in one country or data center is not met by Konnect as deployed, because the Konnect control plane runs in six regions and shares authentication, billing and usage data across them. A self-hosted Kong Gateway OSS or Apache APISIX control plane can keep every component in-country, since both run entirely on infrastructure you choose. Konnect does let you run data plane nodes yourself, but configuration, identities and metering records still pass through Kong's SaaS control plane, so self-hosting the data plane alone does not close the gap. Before you rule Konnect in or out, ask Kong which region hosts your control plane, which identity and usage records leave it, and whether any support access happens from outside your jurisdiction.
The short answer on options is that Kong Gateway OSS (Apache-2.0) keeps routing, authentication, rate limiting and transformation plugins, runs in DB-less mode from declarative files that can live in Git, and accepts configuration exported with decK. Apache APISIX (Apache-2.0) runs in traditional, decoupled or standalone modes, and standalone mode reads conf/apisix.yaml and reloads it without a restart. The honest gap is that neither open-source edition includes Konnect's developer portal or its analytics, so you will need separate tools for those functions and a clear owner for building and running them. Kong's pricing page places fully self-hosted control planes in the commercial Kong Gateway Enterprise offering, so confirm which features you need before committing to the open-source 3.9 line.
Treat the move as a residency decision for your privacy and legal team, alongside the engineering work. Under GDPR Article 44, the EDPB's guidance treats remote access from a third country and storage outside the EEA as transfers, so support access to a Konnect tenant from outside your jurisdiction deserves the same scrutiny as storage. Ask Kong for its data processing terms and its list of processing locations, and map which Konnect fields contain personal data, such as operator names or consumer identifiers. Then decide between a fully self-hosted path and a Kong-managed option, and record the decision along with the evidence behind it. DeployOpen can plan and implement the self-hosted control plane, but the residency conclusion belongs to your legal and compliance owners and any independent assessor.
What a GDPR transfer rule requires from your API management stack
A gateway that routes personal data is part of the transfer analysis, not just the network diagram. The cards below set out which GDPR and EU rules reach the components of a Konnect-style control plane and what a self-hosted replacement must be checked against.
Remote access and storage count as transfers
The EDPB's guidance on the interplay between Article 3 and Chapter V treats remote access from a third country as a transfer, even when data is only displayed on a screen for support or administration. Storage in a cloud outside the EEA is also a transfer. For a SaaS control plane, ask where support staff can view gateway logs and where metadata is stored, then map each location against your own transfer register.
Chapter V follows onward transfers
Article 44 requires every transfer of personal data to a third country, including onward transfers, to meet the conditions of Chapter V. A vendor's sub-processors and their hosting regions therefore sit inside your transfer chain. Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c), so ask your gateway vendor for its full sub-processor list and the regions for each.
Third-country access requests
The CLOUD Act provision at 18 U.S.C. 2713 requires US-linked providers to preserve or disclose data in their possession, custody or control, wherever it is stored. EDPB Recommendations 01/2020 say no effective technical measure can be envisioned when a provider must access data in the clear and foreign powers exceed what is necessary. A self-hosted control plane inside your own data center removes the vendor as an intermediary, so confirm who holds administrative keys and backups.
Schrems II and Data Privacy Framework uncertainty
The Court of Justice invalidated the Privacy Shield in Case C-311/18 while keeping standard contractual clauses valid. The Data Privacy Framework adequacy decision, Implementing Decision (EU) 2023/1795, covers only US organizations on the DPF List, and an appeal in Case C-703/25 P is pending. Do not treat a vendor's DPF listing as settled. Record which legal basis your transfer relies on and review it when the appeal is decided.
Data Act duty for non-personal data
Article 32 of the EU Data Act requires providers of data processing services to take technical, organisational and legal measures to prevent third-country governmental access to non-personal data held in the Union where that access would conflict with EU or national law. Gateway configuration, logs and usage data often fall into this non-personal category. Ask your vendor how it meets Article 32 and whether your switching rights under Articles 25 and 29 apply to a move to on-premises infrastructure.
Which self-hosted gateway keeps the control plane in your jurisdiction
This table compares where each Kong and APISIX control plane runs, how it is licensed, and what you give up when you leave Konnect's portal and analytics. Read it by asking one question first: can the component that holds configuration, identity and usage data stay inside the country or data center you must use. Only the self-run options keep that answer in your hands.
| Option | Control plane location | Licensing and cost model | Portal and analytics | Trade-offs for residency |
|---|---|---|---|---|
| Kong Konnect (SaaS control plane) | Kong-hosted control plane across six regions; data planes self-hosted, serverless or Dedicated Cloud Gateways on AWS, Azure or GCP | Commercial SaaS; metered billing for gateway services, requests, portals and published APIs | Konnect developer portal and analytics included in the hosted service | Configuration, authentication and usage data are shared across Konnect regions, so the control plane sits outside your chosen jurisdiction |
| Self-hosted Kong Gateway OSS, DB-less mode | Your infrastructure only; no database and a read-only Admin API | Apache-2.0; no license fee, you pay for infrastructure and operations | None included; use external portal and monitoring tools | Configuration lives in declarative files you can keep in your own Git; no outside connection is required |
| Self-hosted Kong Gateway OSS, traditional mode | Your database and control plane nodes in your jurisdiction | Apache-2.0; you run the database and cluster strategy yourself | None included; database-dependent plugins such as cluster-strategy rate limiting and OAuth2 are available here | Needs your own database operations, backups and upgrades; OSS line stays on 3.9 |
| Kong Gateway Enterprise, fully self-hosted | Your infrastructure, with a local control plane and data plane | Commercial Kong Gateway Enterprise subscription | Available under the commercial offering; confirm scope with Kong | Residency terms for the Enterprise control plane must be confirmed in writing with Kong before you rely on them |
| Apache APISIX, traditional mode | Control plane and data plane together in your infrastructure, with etcd as configuration store | Apache-2.0; no license fee, you run etcd and gateway nodes | Dashboard is open source; developer portal is not included, so plan a separate portal | Client traffic on port 9080 and Admin API on port 9180 need network isolation within your jurisdiction |
| Apache APISIX, decoupled mode | Data plane and control plane in your infrastructure sharing one etcd cluster | Apache-2.0; more components to size and monitor | Same as traditional mode; confirm portal options | Separating data planes from the control plane helps locate each component in a specific data center |
| Apache APISIX, standalone mode | No etcd; configuration in a YAML or JSON file or through the API on each node | Apache-2.0; lowest number of stateful components | Not included; confirm options with your team | Hot-reloads conf/apisix.yaml or conf/apisix.json every second, but there is no central control plane to audit |
| Apache APISIX 3.19.0 release status | Not applicable; release status applies to any deployment mode | Released September 28, 2026 per the APISIX downloads page; no long-term support mark | Not applicable | Confirm your own support and patching commitment, since the downloads page marks no release as long-term support |
Where Konnect meets and misses residency expectations
Konnect meets part of a residency requirement. Its documentation supports self-hosted data plane nodes, serverless gateways, and Dedicated Cloud Gateways that Kong manages on AWS, Azure or GCP. If you run data plane nodes in your own data center or cloud account, the request traffic and any payloads it carries can stay inside the environment you choose. Confirm with Kong exactly which traffic, if any, still passes through Kong-managed components in your topology, because a self-hosted data plane still reports to a remote control plane.
The gap is the control plane. Konnect's control plane is managed by Kong, and the topic facts for this page describe authentication, billing and usage data as shared across six regions. A residency review should therefore not assume that choosing a region for your gateways also places your management data in one country. Under GDPR Article 44, every transfer of personal data to a third country must meet Chapter V conditions, and the EDPB's Guidelines 05/2021 treat remote access from a third country as a transfer, even when the data is only displayed on a screen for support. Administrator and support access paths therefore matter as much as where the data is stored.
Before you sign, ask Kong in writing which region hosts your tenant's control plane, which regions receive your authentication, billing and usage data, which sub-processors handle it and where they operate, and from which countries Kong staff can reach your tenant. Ask how Kong responds to a third-country authority request. Then check your switching rights under the EU Data Act. The Data Act has applied since 12 September 2025 and gives customers a right to move to another provider or to on-premises infrastructure, with a maximum two-month notice period, a 30-day transition, and a ban on switching charges from 12 January 2027. Those rights shape your exit plan if the answers are unsatisfactory.
Choosing a control plane pattern for each residency scope
When every component, the data, the operators and the administrative tooling must stay in one country, the simplest fit is a self-run Kong Gateway in a local data center or national cloud region with a control plane you host there. Kong's DB-less mode suits teams that want configuration in version control, while traditional mode suits teams that need database-dependent plugins such as cluster-strategy rate limiting or OAuth2. On the APISIX side, traditional mode keeps the control plane and data plane together, and decoupled mode separates them while sharing one etcd cluster in the same location.
- Kong DB-less: configuration lives in declarative files kept in Git, and the read-only Admin API runs inside your network.
- Kong traditional: a database and control plane sit in-country, and plugins that need the database become available.
- APISIX traditional: the Admin API listens on port 9180 and client traffic on port 9080, both inside your own perimeter.
- APISIX decoupled: data plane nodes in one site connect to an etcd cluster in the same country.
- Logs: access and error logs should be routed to a local log platform so no operational record leaves the country.
Confirm with your counsel whether support staff or backup locations abroad count as access under your own residency rules.
When data stays in the EEA but an operations or support team sits outside it, the risk is less about where the gateway runs and more about who can see data from abroad. EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer. The control plane design should therefore limit what a non-EU operator can reach, so that the Admin API, logs and configuration are either not exposed to them or are viewed only through EEA-hosted access paths.
- Kong DB-less: operators from outside the EEA can propose changes through Git pull requests, with merges and deployments run by EEA staff.
- Kong traditional: restrict Admin API access to EEA bastions, since a read-only Admin API still reveals configuration.
- APISIX traditional or decoupled: keep etcd and the Admin API inside the EEA and grant remote support through audited, EEA-hosted sessions.
- Logs: mask personal data before any log view reaches a non-EU team.
- Access records: log every remote session so you can show what was viewed and by whom.
Ask your legal team whether screen-level viewing by the non-EU team qualifies as a transfer under your own transfer assessment before you choose the access model.
For disconnected networks, Konnect is not an option because its control plane is Kong-hosted and depends on a connection to Kong's platform. A self-run gateway can work without any outside connection, but the design must be built for that from the start: no SaaS telemetry, no remote licensing check and no external package pulls at runtime. Kong DB-less mode is the simplest to run offline because it needs no database and reads its configuration from local files. APISIX standalone mode similarly reads a local YAML or JSON file, which avoids etcd altogether.
- Kong DB-less: the declarative file is delivered by a signed, offline transfer and loaded locally, with the Admin API kept read-only.
- Kong traditional: a local PostgreSQL instance must be installed, patched and backed up without internet access.
- APISIX standalone: the file is checked every second and hot-reloaded, which removes etcd from the offline footprint.
- APISIX traditional or decoupled: a local etcd cluster and an offline update path for each component become your responsibility.
- Logs and Admin API: both stay on the isolated network, and any export to a security tool must cross an approved one-way channel.
Confirm with each vendor which packages and plugins you can mirror offline, since some features may depend on online services.
How to deploy a self-hosted control plane in your own data center
This sequence moves Kong Konnect configuration into a gateway that you run inside your own data center or accounts, with the legal scope settled first and Konnect retired only after a verified cutover. It produces a self-hosted gateway tier whose configuration, logs and backups stay within the residency boundary.
Confirm residency scope and legal basis
Before any technical work, the data protection lead and counsel define which data, administrators, support staff and logs must stay in the country or facility, and which transfers are still possible. Confirm with counsel how GDPR Chapter V, the EDPB guidance on remote access from third countries, and any sector rules apply, including how a SaaS control plane outside the boundary is treated. Done when the scope, the list of in-boundary components and the legal basis are signed off in writing.
Choose Kong Gateway OSS DB-less or APISIX
The platform team selects the target gateway based on the existing Konnect feature use. Kong Gateway OSS in DB-less mode keeps configuration as declarative files that can be stored in Git and needs no database, but database-dependent plugins such as cluster-strategy rate limiting and OAuth2 need traditional mode. Apache APISIX offers traditional, decoupled and standalone modes. Confirm that every plugin you rely on is available in the chosen edition and mode before you move on. Done when a plugin-by-plugin mapping is recorded.
Export Konnect configuration with decK
An operator with access to the Konnect control plane runs decK to export the gateway configuration with deck gateway dump, producing a declarative YAML or JSON file. Review the file for services, routes, consumers, plugins and secrets, and remove or rotate any credentials before storing it in the in-boundary repository. Done when the export is committed to a restricted Git repository and a reviewer confirms that every route and plugin on the inventory appears in it.
Stand up the gateway inside your accounts
The platform team installs the gateway in your own cloud accounts, data center or private network using Docker, Kubernetes or Linux packages for Ubuntu, RHEL, Debian or Amazon Linux, as supported by the chosen edition. For APISIX, plan the etcd cluster in traditional or decoupled mode, or use standalone mode with a YAML or JSON file. Apply the exported configuration with decK or the file, then confirm that the client listener on port 9080 for APISIX, or the Kong proxy listener, routes test traffic correctly. Done when a staging environment passes the agreed functional test set inside the boundary.
Restrict the Admin API to internal networks
Bind the management interface to an internal address and restrict it with network policy and authentication. For Kong in DB-less mode, the Admin API is read-only, so changes flow through the Git repository and the deployment pipeline. For APISIX, the Admin API listens on port 9180 in traditional mode, so limit access to it and keep it separate from client traffic on port 9080. Done when a scan from outside the management network cannot reach the Admin API and the change path is documented.
Set up logging, monitoring and backups in boundary
Send access logs, error logs and metrics to log and monitoring stores hosted inside the same boundary, and confirm that no telemetry is exported to a third-country service without an assessed basis. Back up the declarative files or etcd data and the TLS material to encrypted storage in the same jurisdiction, and test a restore into a clean environment. Done when a restore test completes and log retention settings match the legal scope from the first step.
Cut over DNS and retire Konnect
Lower DNS time to live in advance, move traffic to the self-hosted gateway in stages, and watch error rates and latency during each stage. Keep Konnect running in read-only mode until the rollback window closes, then revoke its keys and delete the data plane connections. Record the final configuration version and the decision in the change log. Done when all production traffic flows through the in-boundary gateway, Konnect access is revoked and the residency evidence file is updated.
Evidence regulators and auditors ask for under this rule
A residency decision for an API gateway is only as strong as the paperwork behind it. The cards below cover the records that show where personal data and gateway configuration sit, who can reach them, and how you would leave. DeployOpen prepares this evidence, but supervisory authorities, courts and independent auditors make the determinations.
Records of processing and transfer mapping
Your Article 30 records should list every system that touches API traffic, including request logs, consumer credentials and analytics. For each one, record the country where data is stored and every country from which staff or vendors can view it. Under the EDPB guidelines, remote viewing from a third country counts as a transfer, so support access must appear in the map. Confirm that the Kong control plane, its telemetry and any Konnect-side identity services are either absent or listed as transfers.
Transfer impact assessment
Where any transfer remains, the exporter must assess whether the destination's laws let public authorities reach the data. The EDPB Recommendations 01/2020 say that when a provider needs data in the clear and foreign powers exceed what is necessary and proportionate, no effective technical supplement is likely. Document which party holds keys, whether the provider can read gateway payloads, and which third-country laws apply, such as the US CLOUD Act for US-headquartered vendors. Have counsel review the conclusions.
Data flow diagrams for config and logs
Draw where gateway configuration, plugin secrets, access logs and metrics are created, stored and replicated. For a self-hosted Kong Gateway in DB-less mode, configuration lives in declarative files in your Git system, while for traditional mode it lives in your database. For Apache APISIX, etcd holds routes and plugin settings. Mark every boundary a log crosses, including log shipping to third-party SaaS observability tools, since each one can create a transfer.
Vendor and sub-processor terms
Collect the data processing agreement, the sub-processor list and the location commitments for each vendor that supports the gateway, including any hosting, support tooling or managed service. Confirm whether the contract covers support staff in other countries and how the vendor notifies you of new sub-processors. Note that Kong's version support policy and commercial licensing apply to Kong Gateway Enterprise, so confirm in writing which terms cover the open-source edition you run.
Admin API access logs
The Admin API controls routes, consumers and plugin settings, so its access is an audit point. Keep logs showing which identity called it, from which network, and what changed. In Kong DB-less mode the Admin API is read-only, which narrows the change path to your Git and deployment pipeline. For APISIX, the Admin API listens on port 9180 in traditional mode, so restrict that port and retain its logs. Confirm log retention with your auditor before you set it.
Exit plan under the Data Act
The EU Data Act gives customers of data processing services the right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. Your exit plan should name the export format for gateway configuration, the target platform and the owner of each step. Keep a tested decK export of your Konnect configuration as the baseline for that plan.
How much does a self-hosted Kong or APISIX residency move cost and take?
What are the main cost components of moving off Konnect for data residency?
The cost is split between recurring infrastructure and one-time work, and Konnect's subscription fee is only one line in the comparison. Konnect bills on metered items such as gateway services, requests, portals and published APIs, and Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane belong to the commercial Kong Gateway Enterprise offering. For an open-source move, you pay for:
- Compute and storage for the control plane, data plane nodes, database or etcd, and high availability in your own data center or cloud region.
- Implementation work: exporting configuration, building the deployment, and wiring identity, logging and monitoring.
- Ongoing operations: patching, upgrades, backups and on-call coverage, which is staff time you carry in-house or buy as a retainer.
Confirm each line with your own infrastructure team before comparing totals to your current Konnect invoice.
How long does a self-hosted Kong or APISIX residency move take?
The duration depends on the size and complexity of your gateway estate, and no fixed timeline applies to every organization. The main drivers are the number of routes, services and consumers, how many plugins you use and whether each one exists in the target edition, whether a developer portal must be replaced, and how many environments and regions must be validated. Kong's decK tool can export declarative configuration from Konnect, which shortens the inventory step, but translating plugins and testing traffic behavior takes longer. Ask any provider for a timeline built from a written inventory of your routes, plugins and portal dependencies, and confirm the cutover plan with your change advisory board.
Can an in-house platform team run a self-hosted Kong or APISIX control plane?
A capable platform team can run either option, but the work moves from Kong's console to your own operations. Kong Gateway OSS can run in DB-less mode with declarative files kept in Git, which reduces the database burden, while traditional mode needs a database and supports database-dependent plugins such as cluster-strategy rate limiting. APISIX runs in traditional, decoupled or standalone modes and depends on etcd in the first two. Your team must own high availability, certificate rotation, upgrades and incident response. Before deciding, check whether you have staff who already run Kubernetes, etcd or PostgreSQL in production and who can cover on-call hours.
Which Konnect and Kong Enterprise features do you lose when self-hosting?
You lose the Kong-hosted control plane, its management UI, the Konnect developer portal and analytics, and any Enterprise-only plugins. Kong's documentation describes Konnect as a Kong-managed control plane, and Kong's version support policy applies only to Kong Gateway Enterprise, so the open-source edition has no published support window. Kong's open-source repository stays on the 3.9 release line while Enterprise moves ahead. For APISIX, the Apache-2.0 project has no commercial console, and the dashboard and governance features must be assessed against your needs. List every Konnect feature your teams use today and mark whether each one has an open-source replacement, a gap, or a dependency on a paid product.
Is Kong's Enterprise self-hosted option required for data residency?
No, a self-hosted open-source gateway can keep control plane and data plane traffic in your own country or data center, but this is a question for your legal and architecture teams to confirm. Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane are part of Kong Gateway Enterprise, so that specific deployment model carries a commercial license. An open-source Kong Gateway or Apache APISIX deployment avoids that license, though you must still check that no vendor-hosted component, telemetry or license check sends data outside your boundary. Ask Kong directly which components, if any, remain outside your environment in each option.
What should a written quote for a residency move include?
A written quote should follow a fixed scope that names every deliverable, environment and exclusion before work starts. Ask for the following items:
- A route, service, consumer and plugin inventory, with the assumptions behind it.
- Infrastructure sizing for each environment and region, and who pays the cloud or data center bills.
- The migration approach, cutover plan, rollback steps and acceptance criteria.
- Hardening, backup and restore testing, and the documentation handed over.
- Support terms after go-live, including upgrade responsibility and any retainer.
- What is excluded, such as portal rebuilds, custom plugin development or third-party integrations.
DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables and timelines in writing.
What makes a residency migration cost more or less?
Cost moves with the number of gateway components, the amount of custom logic and the number of compliance evidence requirements. Fewer routes and standard plugins reduce translation work, while custom plugins, many regions, a required developer portal and strict audit evidence increase it. Choosing between Kong Gateway OSS and APISIX also changes effort, since each uses different configuration formats and plugin sets. Reduce cost by standardizing configuration in Git, cleaning up unused routes before export, and agreeing acceptance tests early. Ask each provider to show which of these factors it has priced and which it has excluded.
What you lose and keep when leaving Konnect's control plane
Leaving Konnect removes the Kong-hosted control plane, and with it the portal, analytics, Dedicated Cloud Gateways and the metered features that Konnect bills separately. Konnect's developer portal, analytics dashboards and fully managed Dedicated Cloud Gateways on AWS, Azure or GCP have no equivalent inside the open-source edition. Before you decommission anything, export a complete inventory of which of these you actually use, who depends on them, and what replaces each one. Developer onboarding, usage reporting and any internal chargeback built on Konnect analytics will need a new home, such as the portal in Gravitee or WSO2 API Manager, or Grafana-based dashboards fed by your own logs and metrics.
Your routes, services, consumers and open-source plugins carry over through decK. Export the configuration with decK's deck gateway dump command, then load the resulting declarative file into a self-hosted Kong Gateway. Store that file in Git so the gateway runs in DB-less mode with no database and a read-only Admin API, or run traditional mode if you need the database. Be aware that DB-less mode does not support database-dependent plugins such as cluster-strategy rate limiting and OAuth2. Audit every plugin in the export against this limit, confirm which ones your APIs depend on, and decide before cutover whether you need traditional mode or a replacement plugin for each one.
Confirm your plugin list and Enterprise dependencies before you design the target topology. Some plugins in your export may belong to Kong Gateway Enterprise, which the Konnect subscription covers and which the Kong pricing page describes as the commercial offering for fully self-hosted gateways. Ask Kong which plugins in your export are Enterprise-only, and ask your team which plugins are load-bearing for security or quota enforcement. Where an open-source plugin is missing, the options are a different plugin, a gateway-side change or a move to Apache APISIX, which provides more than 100 built-in plugins according to its documentation. Verify each equivalent with a test request before changing production traffic.
How DeployOpen deploys API gateways under a residency requirement
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Konnect residency concern, that means a gateway control plane and data plane placed where your data-protection rules require, with the configuration and evidence to show it.
How we scope
- Written scope names which gateway, Kong Gateway open source or Apache APISIX, and which deployment mode fits your network.
- Scope lists every component location, including control plane, data plane, databases, logs and backups, by country or facility.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- Gateway configuration is exported from Konnect with decK and rebuilt as declarative files kept under version control.
- Deployment runs in your chosen environment, with authentication wired to your identity provider and access restricted to your networks.
- Security testing of the gateway and its admin endpoints is run before cutover, and findings are tracked to closure.
How we hand over
- You receive runbooks for upgrades, backups, restores and configuration changes, plus a record of where each component runs.
- Compliance readiness material documents residency controls and data flows, prepared for your independent auditors to assess.
- Handover includes a walkthrough with your platform and security teams, so your staff can operate the gateway without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope covers tracking open-source releases and planning upgrades against your change windows.
- Confirm response expectations and upgrade responsibilities in the written retainer before go-live.
