Apigee hybrid or a self-hosted gateway: which fits your data residency and outage rules
If your rules say API traffic, gateway configuration and access logs must stay inside a defined boundary, Apigee hybrid keeps only part of that boundary under your control. Apigee hybrid runs the runtime plane on your own Kubernetes, while Google hosts the management plane. The short answer is that hybrid splits the planes, whereas a fully self-hosted gateway removes the external control plane entirely. Apache APISIX and Kong Gateway OSS are the two main open-source options for the second model. This section and the ones that follow cover three questions: where data and configuration sit, what happens to traffic when the external plane is unreachable, and how the cost of each model is built up.
Start by mapping what leaves your network under each design. In hybrid, confirm with Google exactly which management-plane data is sent to its hosted services, such as proxy metadata, deployment state, analytics and any logs or traces routed out of your cluster, and whether that data can be restricted for your region. In a self-hosted design, the control plane is yours: APISIX can run in traditional mode with etcd inside your network, or in standalone mode driven by a YAML or JSON file with no etcd at all, and Kong Gateway OSS can run DB-less from declarative files kept in Git. Write down each data flow and the system that owns it before you compare options.
Next, test the outage case rather than assuming it. A hybrid runtime depends on the management plane for deployments and configuration changes, so ask Google what your runtime does when that link is down, and rehearse an outage in a non-production cluster. A self-hosted gateway has no external dependency for routing, so its risk moves to your own etcd cluster, your configuration pipeline and your on-call team. Each option needs a documented recovery procedure and a tested rollback path. Also note that Kong's DB-less mode does not support database-dependent plugins such as cluster-strategy rate limiting, so confirm that your traffic controls work in the mode you choose.
What a residency or outage rule requires from the gateway
A residency or outage rule turns into a handful of concrete gateway requirements. The cards below cover where configuration lives, what keeps serving when the control plane is down, who can change routes, and what evidence the gateway leaves behind. Check each one against your hybrid or self-hosted candidate before you commit.
Where configuration and management data live
In Apigee hybrid, Google hosts the management plane, so proxy definitions, analytics and portal data sit outside your runtime. A fully self-hosted gateway keeps routes and plugins in files you control. In APISIX standalone mode, configuration lives in conf/apisix.yaml or conf/apisix.json, and in Kong DB-less mode it lives in declarative files that can be kept in Git. Ask each vendor exactly which data leaves your boundary.
Data plane serving during control plane outages
Your residency rule may also require traffic to keep flowing when a control plane is unreachable. APISIX standalone mode reloads its file-based configuration without etcd, and Kong DB-less mode runs without a database. Test this by cutting the link to the management plane in a staging environment and confirming that existing routes, keys and plugins still serve requests. Confirm which features, such as cluster-strategy rate limiting in Kong, need a database and so fall outside DB-less operation.
Who can administer the gateway
Ask who holds administrative rights over routes, plugins and certificates, and where those rights are enforced. APISIX exposes its Admin API on port 9180 in traditional mode, so restricting that port and its credentials is a required control. Kong's DB-less mode exposes a read-only Admin API, which limits changes to the files and the pipeline that deploys them. Map each admin role to a named group in your identity provider before go-live.
Evidence the gateway produces
A residency or audit review asks what the gateway logged, where those logs went, and who can read them. Self-hosted gateways let you route access logs and metrics into your own stack, but this only holds if you configure it. Decide which events, such as configuration changes, authentication failures and rate-limit hits, must be retained, and confirm where each is stored. Confirm with the vendor which audit records, if any, the management plane keeps on its side.
Configuration change control
Declarative configuration lets routes and policies move through the same review path as application code. Kong's decK tool exports and syncs declarative files, and keeping those files in Git gives you history, approvals and rollback. Without this step, configuration drift between environments becomes hard to detect. Ask whether your gateway can apply a configuration from a file in a pipeline without a manual console step.
Supported versions and patch ownership
A residency rule also needs an owner for security fixes. Apigee Edge for Private Cloud reaches end of life on June 30, 2027, after which Apigee stops providing security updates for that line. Open-source gateways shift patching to your team or your implementation partner. Kong's version support policy covers only Kong Gateway Enterprise, so confirm the patch window for any open-source release you adopt, and record who applies each update.
What Apigee hybrid keeps in your cluster and what Google keeps
Apigee hybrid splits the platform into two planes. The runtime plane, which handles API traffic through the Apigee runtime components, runs on a Kubernetes cluster that your team operates. Google hosts the management plane, which holds the control functions for proxies, environments and configuration. That split keeps request traffic inside your network, but it does not answer every data residency question on its own. The facts available to us do not map each data flow between the two planes, including which management data leaves your environment, what metadata is sent with it, and in which regions it is stored. Ask Google for a written data flow diagram for your Apigee hybrid version and confirm where analytics, logs, configuration and audit records are stored before you approve the design.
The on-premises path has a fixed deadline. Apigee documentation states that Apigee Edge for Private Cloud 4.53.01 reaches end of life on June 30, 2027, after which Google stops providing bug fixes, security updates, hotfixes and patches for that line. Continuous support also requires running a version within its 18-month full support window, so a team still on Edge for Private Cloud should plan its move well before that date. If your data residency rules rule out a Google-hosted management plane, the decision is between an on-premises Apigee path and a fully self-hosted gateway. Put that decision in the migration plan now, with the Edge end of life as the fixed constraint.
A useful next step is a short written inventory with three columns: what runs in your cluster, what Google hosts, and what the platform team cannot verify yet. Include the Kubernetes namespaces, service accounts, certificates and secrets that the runtime uses, and ask Google to confirm which of them are ever sent to its management services. Then compare that inventory against a fully self-hosted gateway, where every component, including the control plane, sits in your infrastructure. The comparison will show whether hybrid meets your residency and outage requirements or whether a self-run gateway is the simpler answer.
Which self-hosted gateway meets which part of the constraint
This table maps the main residency, outage and licensing needs against Apache APISIX, Kong Gateway OSS, Kong Gateway Enterprise, WSO2 API Manager and Gravitee. Read each row as a question you must answer for your environment, then check the license and support cells before you shortlist a product.
| Requirement | Apache APISIX | Kong Gateway OSS and Enterprise | WSO2 API Manager and Gravitee |
|---|---|---|---|
| Keeps all traffic and config inside your network | Traditional, decoupled and standalone modes all run without a vendor SaaS control plane, per APISIX deployment documentation | OSS runs DB-less or traditional with no Kong-hosted control plane. Fully self-hosted control plane features sit in Kong Gateway Enterprise, per Kong pricing page | Gateway, publisher and control plane are open source under Apache-2.0, so they can run fully on your infrastructure |
| Survives loss of a central control plane | Standalone mode reads conf/apisix.yaml or conf/apisix.json and hot-reloads, so data plane nodes keep serving without etcd | DB-less mode takes declarative files that can be kept in Git, so nodes can run from stored config. Confirm behavior of Admin API changes during an outage | Confirm how gateway nodes behave when the management tier is unreachable in your chosen topology |
| Configuration as code for change control | Routes and plugins are stored in etcd or YAML/JSON files, with an Admin API for updates | decK exports and syncs declarative files to OSS and Enterprise Kong Gateway, which fits Git-based review | Configuration is managed through the publisher and APIs, so confirm export and promotion steps against your release process |
| Database-dependent plugins such as cluster rate limiting | Plugin set covers traffic control and security, confirm the specific rate limit backend you need | Only traditional mode supports database-dependent plugins such as cluster-strategy rate limiting and OAuth2, so plan a database and its availability | Throttling runs through the traffic manager, confirm the component and storage it requires |
| Open-source support window and release cadence | APISIX 3.19.0 is listed on the downloads page, which marks no release as long-term support, so set your own patch policy | Latest OSS line is 3.9, with no published support window. Enterprise releases follow Kong's version support policy and are on quarterly cadence | Apache-2.0 community releases are available, while WSO2 sells on-prem subscriptions with support and continuous updates |
| Licensing for commercial use and paid features | Apache-2.0 for the gateway and ingress controller, no feature tier stated in supplied facts | Apache-2.0 for the OSS repository. Fully self-hosted control plane features require a commercial Enterprise license | WSO2 offers a licensed distribution for commercial use. Gravitee needs an Enterprise License for some features |
| Full product beyond the gateway (portal, console, analytics) | Gateway and ingress focus, with a developer portal and analytics to be added through other tools | Gateway-centric, confirm which portal, analytics and management UI features you need in OSS versus Enterprise | Includes gateway, developer portal, publisher and control plane in one product |
| What to confirm before choosing | Your plugin needs against APISIX's 100+ built-in plugins, and the runner or Wasm path for custom Apigee policies | Which Enterprise features your topology needs, and your support window for the 3.9 OSS line | Which edition features (Community or licensed) cover your portal, throttling and support needs |
Traditional, decoupled or standalone: choosing APISIX's deployment mode
Traditional mode runs the data plane and control plane together on the same nodes, with etcd holding the configuration. APISIX listens on port 9080 for client traffic and on port 9180 for the Admin API, so the gateway and its management interface share the same deployment unit. Changes made through the Admin API are written to etcd and picked up by the running gateway without a restart, which is the dynamic routing behavior described in the APISIX repository.
- Ports: Client traffic arrives on 9080 and the Admin API is exposed on 9180, so both need explicit network policy.
- Change path: Route and plugin edits go through the Admin API into etcd and apply without restarting the gateway.
- Outage tolerance: Gateway nodes depend on a reachable etcd cluster for configuration changes, so an etcd outage blocks updates.
- Blast radius: Admin API exposure and gateway traffic live in one deployment, so access controls must cover both.
- Operations: One deployment to size, patch and monitor, with etcd operated alongside it.
Confirm in your own environment what happens to live traffic when etcd or the Admin API is unavailable, and whether your gateway nodes keep serving with their last known configuration.
Decoupled mode separates the data plane from the control plane. Both sides share one etcd cluster, so the gateway nodes that serve traffic can sit in a different network zone or location from the nodes that accept administrative changes. This split suits teams that want to keep management endpoints away from public-facing gateways while still using dynamic configuration.
- Ports: The control plane keeps the Admin API on port 9180, while data plane nodes serve client traffic on port 9080.
- Change path: Administrators write configuration through the control plane, and etcd distributes it to the data plane nodes.
- Outage tolerance: The data plane depends on etcd for updates, so a shared etcd failure affects both planes at once.
- Network placement: Data plane nodes need a path to the shared etcd cluster, which can narrow where you place gateways for residency reasons.
- Operations: Two roles to deploy and monitor, plus an etcd cluster that becomes a critical shared dependency.
Test what each node does when it loses connectivity to etcd, including whether it keeps the last configuration it received, and document the result for your operations runbook.
Standalone mode removes etcd entirely. The gateway reads its configuration from conf/apisix.yaml or conf/apisix.json, or receives it through the API, and checks the file for changes every second. Because no etcd cluster is involved, the gateway can run without a database-style dependency, and the configuration file can be kept under version control and reviewed like other infrastructure code.
- Change path: Editing the file triggers a hot reload within about one second, with no restart of the gateway process.
- Configuration source: The YAML or JSON file is the source of truth, so changes are made by editing and deploying files rather than calling a live store.
- Outage tolerance: Without etcd there is no store to fail, but each node relies on its local file, so the deployment pipeline that writes files becomes the control point.
- Ports: Client traffic still arrives on the standard gateway port, and you should confirm the Admin API configuration for your chosen setup in the deployment documentation before exposing it.
- Fit: Suits air-gapped or tightly controlled environments where a central configuration store is not wanted, but it trades dynamic API-driven changes for file-driven workflows.
Confirm how your configuration pipeline behaves when files are partially updated or a node receives an invalid file, and rehearse rollback before going live.
How to deploy a self-run gateway inside your boundary
This sequence moves gateway traffic, configuration and telemetry into your own infrastructure, with each step ending in a check you can repeat. The result is a gateway you can rebuild from Git, observe with your own stack and fail over without a vendor control plane in the path.
Confirm the residency boundary and outage target
The security or architecture lead writes down which networks, regions and data classes the gateway may touch, including logs and request bodies, and which outage behavior the business accepts. Confirm with your compliance owner whether any regulator or contract names specific locations. Done means a signed boundary statement lists every data path, and each upstream API has a stated failure mode the team has agreed to.
Choose the deployment mode for the gateway
The platform team picks the topology that matches the boundary. For Kong Gateway, DB-less mode takes configuration from declarative files and exposes a read-only Admin API, but database-dependent plugins such as cluster-strategy rate limiting and OAuth2 need traditional mode. For APISIX, compare traditional, decoupled and standalone modes. Confirm plugin availability for each mode in the vendor documentation before you commit. Done means a written topology decision that names every plugin you depend on.
Store gateway configuration in Git
Engineers commit routes, services, plugins, upstreams and consumers as declarative files to a repository you control, with reviews required before merge. For Kong, decK exports the running state with a dump command and syncs files back to open-source Kong Gateway. Done means the live gateway matches the repository, and a diff between the two shows no drift after a sync.
Deploy gateway nodes in your cluster or on servers
The platform team runs the data plane on your Kubernetes cluster or on hosts in your data center or cloud account. For Kubernetes, install the Kong Ingress Controller or the APISIX Ingress Controller so that Kubernetes resources drive gateway configuration. Keep the control plane and any etcd or database components inside the same boundary. Done means every node reports healthy, and a test request traverses the gateway without leaving your network.
Route logs and metrics to your own stack
The operations team points access logs, metrics and traces at your collectors, such as OpenTelemetry pipelines feeding Prometheus, Grafana, Jaeger or a log store you run. Redact sensitive headers and bodies before data leaves the gateway. Confirm with your security team which fields are permitted in each store. Done means a test transaction appears in your dashboards and logs, and no telemetry endpoint points outside the boundary.
Test failover against the outage target
The team simulates loss of a gateway node, a zone and the configuration store, then measures whether traffic continues within the outage target set in step one. Run the test in a non-production environment that mirrors production topology. Record what failed, how long clients saw errors and whether alerts fired. Done means a written test report with the results and any gaps assigned to owners.
Rehearse a configuration rollback
Engineers merge a deliberately faulty route or plugin change, then revert it through the normal Git workflow and decK or the ingress controller sync. Confirm that the gateway returns to the last known good state and that the Admin API and file changes are audited. Done means a documented rollback runbook that another engineer has executed successfully from the repository alone.
Questions buyers ask before choosing a self-hosted gateway
Is a self-hosted gateway cheaper than Apigee hybrid?
It depends on which costs you count, and no fixed figure applies to every estate. Apigee hybrid bills Google for the management plane under a commercial subscription, while you pay for the Kubernetes capacity that runs the runtime. A self-hosted Apache APISIX or Kong Gateway OSS deployment removes the Google subscription line but adds infrastructure you run, a developer portal you select or build, support contracts if you want them, and staff time for operations and upgrades. Ask any vendor for a quote that lists each component separately: licenses or subscriptions, call or environment charges, compute and storage, implementation, portal, support, and recurring operations effort over the period you plan to use. Also ask what changes if your traffic volume grows, because that drives most of the variable cost.
How long does a gateway migration from Apigee take?
The duration depends mainly on the number of proxies, shared flows and custom policies, the number of environments, how many consumers must cut over, and how much of the developer portal must move. Proxies that use only standard policies map to routes, upstreams and plugins quickly, while Apigee policies that need custom code, such as complex JavaScript or Java callouts, take longer to rebuild and test. Traffic cutover is usually done environment by environment, so the plan needs parallel running, rollback steps and sign-off from each API owner. Ask for a written plan that breaks the work into discovery, mapping, build, test, cutover and decommissioning, with a fixed-scope estimate for each phase rather than one overall guess.
What does the client team need to provide during a migration?
The work needs people who know the APIs and the business owners who approve changes, plus access to the systems involved. In practice that means an exported inventory of Apigee proxies, products, apps and key configuration, a named owner for each API, staff who can run the Kubernetes or virtual machine platform the gateway will use, and identity provider details for token validation. Your security team should supply its requirements for TLS, logging, network paths and secrets handling, and your change management process must allow staged cutover windows. Confirm early who holds Apigee administrator rights and who can approve production changes, because those decisions often set the pace of the project.
Can our own team run a self-hosted API gateway without a partner?
Many teams can, provided they have engineers comfortable with Kubernetes or Linux, configuration as code and a clear incident process. Apache APISIX supports traditional, decoupled and standalone deployment modes, and Kong Gateway OSS supports DB-less declarative configuration that can be kept in Git with decK, which reduces the number of stateful components you operate. The harder work is ongoing: patching the gateway and its dependencies, monitoring, certificate rotation, capacity planning, and deciding which version line to run. Note that the Kong open-source repository stays on the 3.9 line with no published support window, so plan your upgrade path. Be honest with yourself about on-call coverage and skills before committing, and review the operating model with your team first.
What happens to API traffic during a control plane outage?
It depends on the deployment model, so check each one before you rely on it. In Apigee hybrid, the runtime plane runs on your Kubernetes, while Google hosts the management plane, so you should confirm with Google how runtime behavior continues during a management plane interruption and what cached configuration the runtime keeps. In a self-hosted gateway, the answer depends on your design: APISIX standalone mode loads routes from a YAML or JSON file and needs no etcd, while traditional and decoupled modes depend on etcd, and Kong's DB-less mode reads declarative files without a database. Ask each vendor to describe what keeps serving traffic, what stops, how configuration changes are blocked, and how you would test that behavior in your own environment before go-live.
When should we bring in a partner like DeployOpen for a gateway migration?
Bring in a partner when the internal team lacks capacity or experience for the migration, when regulatory evidence is needed, or when the estate is large enough that a fixed plan reduces risk. DeployOpen, a Chainscore Labs company, plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ongoing support, upgrades and testing are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, which remain the role of independent auditors.
Evidence auditors and regulators ask for from the gateway
Auditors and regulators rarely accept a gateway on its feature list alone. They ask who can change routes and policies, where traffic and logs go, and whether the software is still supported. The items below are the records that answer those questions, whichever gateway model you choose.
Trust boundary architecture diagrams
Diagrams should show where client traffic enters, where the data plane runs, which parts sit in Google's management plane in Apigee hybrid, and which sit only in your own cluster or servers in a self-run gateway. Mark every connection that crosses a boundary, including control traffic, telemetry and identity provider calls. For a self-hosted gateway, confirm that no control plane component depends on an external service you have not listed.
Admin API access control records
Record who can reach the Admin API, the management console and the configuration store, and how that access is granted and removed. For APISIX, the Admin API listens on port 9180 in traditional mode, so the network path to that port is a control you must document. Keep the role mapping, the identity source used for administrator logins and the review dates for those accounts.
Configuration in version control
Keep gateway routes, plugins and policies as files in Git, with every change tied to a reviewed merge request. Declarative setups such as Kong's DB-less mode or APISIX's file-driven standalone mode make this straightforward, because the running state comes from a file you can diff. Your change history then becomes evidence of who approved what and when, and it lets you rebuild a gateway from a known revision after an incident.
Log and metric retention records
Auditors will ask how long access logs, error logs and audit events are kept, where they are stored, and who can read them. Define retention periods in your own policy, then show the configuration that enforces them in your log store. Confirm that logs leaving the gateway carry no request bodies or credentials you are not permitted to hold, and that the metrics pipeline is protected like any other system of record.
Outage and failover test records
Hybrid and self-hosted designs fail differently. In hybrid, a loss of connectivity to Google's management plane is a dependency to test. In a self-run gateway, the risks are a failed etcd cluster, a broken load balancer or a bad configuration push. Record each test you run, the expected behavior, the observed result, the time to recover and the fixes that followed. Reviewers look for repeated tests, not a single demonstration.
Version and patch support records
Keep a current inventory of gateway, plugin and ingress controller versions, with the source of each support statement. Apigee's documentation says Edge for Private Cloud 4.53.01 reaches end of life on June 30, 2027. Kong's version support policy covers only Kong Gateway Enterprise, so the open-source line has no published window. Record which versions you run, who tracks advisories for each, and how you apply patches.
How to decide between hybrid and a fully self-hosted gateway
Choose hybrid when a Google-hosted management plane is acceptable under your data classification and legal review, and when Apigee's analytics, monetization and portal features matter more to your teams than control over the control plane. In that model, the runtime plane stays on your Kubernetes clusters, so request traffic and most payloads remain in your environment, while proxy definitions, environment configuration and management metadata sit in Google's management plane. Your operating burden is the runtime cluster, its upgrades and its capacity, and you keep Apigee's feature set without rebuilding it. Confirm with Google exactly which data categories cross into the management plane, where they are stored, and how a loss of connectivity to that plane affects new deployments and key management.
Choose a fully self-hosted gateway such as Apache APISIX or Kong Gateway when residency or outage rules prohibit any external control plane, or when a regulator or internal policy requires that configuration changes can be made during a provider outage. APISIX's standalone mode reads routes and plugins from a local YAML or JSON file and has no etcd dependency, while the traditional and decoupled modes keep configuration in your own etcd cluster. Kong's DB-less mode works from declarative files that can live in your Git system. Be aware of the trade-offs: you take on gateway upgrades, certificate handling, observability and any developer portal work, and some features may sit in commercial editions, for example Kong's fully self-hosted control plane offering or Tyk's dashboard. Verify each required feature against the vendor's current edition documentation before you commit.
Run this checklist with your data classification register and legal team before you pick an option. (1) List every API data category and mark whether any payload, token or personal data may leave your boundary, even as metadata. (2) Ask Google to confirm in writing the management-plane data flows and the hosting region for your Apigee organization. (3) Confirm the outage behavior you need: can existing traffic keep flowing, and can an operator change a route during a management-plane incident? (4) Inventory the Apigee policies and analytics you use today and mark which need custom plugins or commercial add-ons. (5) Estimate your staffing for gateway operations on your own clusters. (6) Get written quotes that separate subscription, support, infrastructure and implementation costs, and record which of them recur each year. If three or more answers point to an external control plane being unacceptable, plan for a self-hosted gateway.
