Why Apigee Edge for Private Cloud customers must decide on a replacement before June 30, 2027
If your on-premises Apigee Edge for Private Cloud estate runs 4.53.01, you have three paths: upgrade to 4.54.00, move to Apigee hybrid with a Google-hosted management plane, or run a fully on-premises open-source gateway. Apigee documentation sets the end-of-life date for 4.53.01 at June 30, 2027. After that date Apigee stops providing bug fixes, security updates, hotfixes or patches for that version line, so an unpatched gateway in production becomes a risk your security team has to carry. Continuous support also requires running a version inside its 18-month full support window, so the decision is about when the estate moves, not only whether it does.
The constraint that usually settles the choice is one of three things: data residency, air-gapped operation or licensing. An upgrade to 4.54.00 keeps the estate closest to today's operating model, but it does not remove the dependency on Apigee's support lifecycle. Apigee hybrid keeps the runtime in your Kubernetes cluster while Google hosts the management plane, so you must confirm with Google whether your management plane data, telemetry and control traffic can leave your boundary under your residency rules. A fully on-premises open-source gateway removes the external control plane entirely, but it moves the cost into your own staff, support contracts and build work.
Before you choose, write down the constraint that applies to you and ask each vendor to confirm it in writing. Ask Apigee which support window applies to 4.54.00, whether hybrid's management plane can run in a region and network you specify, and what happens to your estate if the hybrid service changes. Count the proxies, shared flows, custom policies and developer portal dependencies you run today, because those counts drive the effort of every path. A planning window that starts now leaves room to compare the options properly, whichever path you pick.
What an on-premises constraint requires from the replacement
Edge for Private Cloud customers usually need to stay inside their own network, keep a supported version line, and control their own keys and portal. The cards below are the checks that connect those needs to the open-source options on this page.
A supported version line
Apigee stops bug fixes, security updates and patches for 4.53.01 after its end of life, so the replacement has to come with a maintained release line of its own. For APISIX, the downloads page does not mark any release as long-term support, so ask who backs the branch you adopt and how long each minor version receives fixes. Write that window into the migration plan before choosing a version.
Control plane inside your network
A gateway that depends on a vendor-hosted management plane fails the on-premises requirement. APISIX runs in traditional mode with data and control planes together, in decoupled mode with a shared etcd cluster, or in standalone mode with no etcd at all. Standalone mode reads conf/apisix.yaml or conf/apisix.json and hot-reloads on change, which suits air-gapped change control. Confirm which mode your network policy allows.
No mandatory vendor dependency
Check every component for an outbound call to a vendor service. Tyk's dashboard, control plane and developer portal ship under a commercial license, and Gravitee's Enterprise features require a license. WSO2 API Manager runs on premises from extracted packages, but its subscription adds support and updates. Map each feature you use to an open-source component or a license decision before procurement starts.
Developer portal and key management
Edge's portal and app keys must move with the APIs. Gravitee ships a Console UI and a Portal UI, and WSO2 API Manager includes a Developer Portal and Publisher. Apache APISIX provides the gateway and key-related plugins but no bundled portal, so teams usually add one. Test app registration, key issuance, approval flows and key rotation against your real developer workflow.
Identity integration for consumers
Edge deployments often authenticate partners and internal apps through an existing identity provider. The APISIX openid-connect plugin supports authorization code, client credentials, token introspection and PKCE flows, and works with providers such as Keycloak, Microsoft Entra ID and Okta. Confirm that your identity provider supports the flow each API client needs before cutover.
A licensing model you can keep
Open-source core licenses differ. APISIX and WSO2 API Manager are Apache-2.0, Gravitee's core is Apache-2.0 with Enterprise features under a separate license, and Tyk Gateway is MPL-2.0 except its commercial ee folder. Ask each vendor which features your current Edge policies depend on, then decide whether the gap is closed by open code, a paid subscription or custom work. Record the answer in the procurement file.
Upgrade, Apigee hybrid or open source: where each path meets the constraint
Upgrading to 4.54.00 keeps your existing proxies, environments, management tooling and operating model in place, so it is the smallest change to the platform. It does not remove the deadline. Apigee's release process documentation states that 4.53.01, first released on August 26, 2025, reaches end of life on June 30, 2027, and that continuous support requires running a version within its 18-month full support window. A newer release starts its own support clock, so the upgrade buys time for the next decision rather than settling it.
- Lowest change to the model: Proxies, shared flows, product configuration and operator skills carry over, which narrows the testing scope compared with a gateway migration.
- New support clock: Confirm the release date and full support window of 4.54.00 with Google in writing before assuming it outlasts the 4.53.01 deadline.
- Regression testing still applies: Each upgrade changes the platform you run on your own infrastructure, so test every proxy and custom policy against the new version.
- Decision is deferred: Set a checkpoint date, well ahead of the support window end, to choose between hybrid and an open-source gateway.
- Edge costs continue: Licensing, infrastructure and staff time for the Edge stack continue for as long as you run it, so model them alongside the other two paths.
Before you approve an upgrade plan, get the support end date, the upgrade path from your current build and the license terms confirmed in writing.
In Apigee hybrid, you run the runtime plane on your own Kubernetes clusters while Google keeps the management plane. The split matters most for two questions: where data is stored and processed, and what keeps serving traffic when the link to the management plane is impaired. Those answers depend on the exact product version and architecture you adopt, so they need to be confirmed before you commit.
- Residency: Ask exactly which data the runtime keeps locally and which metadata, configuration or analytics reach the Google-hosted management plane, and where that data is stored.
- Outages: Ask how already-deployed proxies behave if the management plane or its connectivity is unavailable, and how configuration changes are queued or delayed during that period.
- Operations: You still run the clusters, ingress, certificates, upgrades and capacity for the runtime, so Kubernetes and platform skills remain a requirement.
- Lock-in: Proxies and policies stay in Apigee's model, so leaving later still means exporting and rewriting them for another gateway.
- Version line: Hybrid is a separate product line from Edge for Private Cloud. Confirm its release line, support window and migration path from Edge with Google.
Get the data flow diagram, the outage behavior and the Kubernetes footprint in writing before you compare hybrid with the other two paths.
A self-run open-source gateway moves the whole API stack onto infrastructure you control, so the right choice depends on which components your team must run itself. Gateway, control plane, developer portal, analytics and identity can each be a separate decision. Apache APISIX is Apache-2.0 licensed and built on NGINX and etcd, with traditional, decoupled and standalone deployment modes. Gravitee API Management and WSO2 API Manager are also Apache-2.0 licensed and bundle a management interface and developer portal, so they cover more of the stack in one product.
- Gateway only: APISIX covers routing, plugins and OpenID Connect with providers such as Keycloak and Okta. Its standalone mode reads configuration from a YAML or JSON file without etcd, which suits teams that manage configuration as code.
- Full API management: Gravitee and WSO2 API Manager include publisher or console, developer portal and lifecycle features. Check which features sit behind enterprise or commercial licenses, such as Gravitee Enterprise features or WSO2 subscriptions.
- Operational components: etcd in traditional or decoupled APISIX, databases for Gravitee, and monitoring and log pipelines are yours to run, back up and patch.
- Support model: Open-source licensing does not include vendor support. Decide whether to buy a commercial subscription, engage a partner or staff support internally.
- Gaps to verify: Analytics, monetization and business reporting may need extra build work, so test each requirement against the candidate's documented capabilities.
List the five components you would operate (gateway, control plane, portal, analytics and identity), then score each candidate against that list and your residency and support requirements.
Which open-source gateways fit an on-premises Edge replacement
This table compares five open-source gateways on license, on-premises deployment, whether a control plane and developer portal ship in the open-source edition, and which features need a commercial license. Read each row as a question to confirm with the vendor before you shortlist a gateway, since the licensing edges of these products change between releases.
| Capability | Apache APISIX | Gravitee APIM | WSO2 API Manager | Kong Gateway OSS | Tyk Gateway |
|---|---|---|---|---|---|
| License | Apache-2.0 (Apache-2.0 for the gateway and ingress controller) | Apache-2.0 for Community Edition, Enterprise Edition requires a license | Apache-2.0 for the open-source product, commercial subscription for support and updates | Apache-2.0 for the OSS edition, newer features ship in Kong Gateway Enterprise | MPL-2.0 for the gateway, code in the ee folder is commercial |
| On-premises deployment | Traditional, decoupled or standalone modes, with etcd for dynamic configuration | Docker Compose with MongoDB or a Helm chart for Kubernetes, self-hosted | On-prem packages from extracted distributions, Kubernetes via a separate API Platform | Docker, Kubernetes or Linux packages for Ubuntu, RHEL, Debian and Amazon Linux | Runs self-managed as a gateway, with control plane components under a commercial license |
| Control plane in open-source edition | Admin API and etcd-backed configuration, no bundled management UI for the gateway | Management API backend and Console UI ship in the Community Edition | Publisher, control plane and traffic manager ship in the open-source product | Declarative configuration via open-source tooling, no bundled management console | Dashboard and management control plane require a Tyk license |
| Developer portal in open-source edition | Not included, a portal must be built or added separately | Portal UI with API catalog and documentation ships in the open-source product | Developer Portal ships in the open-source product | Not included in the OSS edition | Developer Portal requires a Tyk license |
| JDK or runtime prerequisite | No JVM requirement stated in supplied sources, confirm with the vendor for your build | Confirm the required runtime for your chosen install method | Building the release requires JDK 21, confirm the matching runtime for your packages | Confirm package requirements for your OS version with Kong | Confirm supported runtime and packaging with Tyk for your environment |
| Commercial features to confirm | Confirm which advanced plugins, support terms and AI gateway functions your version includes | Event endpoints, audit trails, data masking, GeoIP filtering and the policy pack need an Enterprise license | Commercial subscription adds expert support, continuous updates and vulnerability monitoring | Enterprise features such as advanced plugins and newer releases sit in Kong Gateway Enterprise | Dashboard, Developer Portal and Operator need a Tyk license, confirm scope before you plan |
| Support window for the open-source line | Confirm the support policy for each release line with the project and your distribution | Confirm current release support with Gravitee before you commit to a version | Confirm support windows and update cadence in the commercial subscription terms | Open-source repository stays on the 3.9 line, confirm any support window with Kong | Confirm supported versions and upgrade paths with Tyk |
How to deploy and operate an on-premises open-source gateway under the constraint
This sequence moves Edge for Private Cloud proxies, policies and developer access onto a self-run open-source gateway in ordered, checkable stages, so the team can retire Edge without a gap in traffic or access control.
Inventory Edge proxies, shared flows and developer data
The platform team, with the API owners, lists every proxy, shared flow, target server, product, app, developer and key that Edge holds for each environment. Export proxy bundles and product and app configuration through the Edge management API before any change is made, and store the exports in a controlled location on premises. Note which policies carry custom JavaScript, Java callouts or Message Logging, because these need a rewrite rather than a direct mapping. Done means each API has an owner, a bundle, a traffic profile and a list of consumers, reviewed by the security team.
Choose the deployment mode for the gateway
The architecture team selects how Apache APISIX will run. Traditional mode keeps the data plane and control plane together with one etcd store. Decoupled mode separates the data plane from the control plane while both share one etcd cluster. Standalone mode drops etcd and loads configuration from a YAML or JSON file or the Admin API, which suits teams that prefer configuration as code in Git. Each option changes where etcd runs, how many clusters are operated and how configuration is promoted, so confirm the choice against the existing change-management process. Done means a written decision record covering each environment.
Stand up the gateway and configuration store on premises
The infrastructure team installs APISIX and, where the chosen mode requires it, an etcd cluster inside the organization's own data center or private cloud, using the install method its security policy approves. In traditional mode, APISIX serves client traffic on port 9080 and the Admin API on port 9180. The team sets its own firewall and network rules so that only approved clients reach the Admin API, and that port is never exposed to the public internet. In standalone mode, the team checks conf/apisix.yaml or conf/apisix.json, which APISIX reloads when it changes. Done means a test route answers through the gateway and the Admin API rejects requests from outside the approved network.
Wire the identity provider and access policies
The security and identity team connects the gateway to the organization's identity provider using the openid-connect plugin, which supports providers such as Keycloak, Microsoft Entra ID, Okta and Google, with the authorization code, client credentials, token introspection and PKCE flows. Map each Edge security policy, such as OAuth or API key checks, to an equivalent plugin configuration and test it against each consumer type. Confirm with the identity provider's vendor how client credentials are issued and rotated, since the gateway depends on them. Done means each API passes positive and negative token tests recorded in the test log.
Build the portal and key workflows
The developer experience team rebuilds the parts of the Edge developer portal that partners and internal teams use: API documentation, app registration, key issuance, approval and revocation. Choose a self-hosted portal or catalog that fits the organization, and confirm which approval steps must remain manual for compliance. Migrate developer accounts and apps with an agreed plan for resetting credentials, because keys do not carry over automatically. Done means a test developer can register an app, receive a key, call a test API and have the key revoked, with each action logged.
Run parallel traffic and compare results
The operations team sends a copy or a controlled share of production-like traffic through the new gateway while Edge continues to serve live callers. It compares status codes, latency, throttling outcomes and authentication decisions between the two systems, and logs each difference for triage. Metrics and logs are fed into the team's own monitoring stack, so the comparison does not depend on Edge analytics. Done means every difference is either fixed or accepted in writing by the API owner, and the rollback steps have been rehearsed.
Cut over environment by environment
The release team moves traffic one environment at a time, starting with non-production and then moving to production, with each API switched only after its parallel run is signed off. DNS, load balancer or client configuration changes are applied in a documented change window, and the rollback path is kept ready until the cutover is verified. Done means each environment shows stable traffic on APISIX, no open defects from the parallel run and an updated runbook that operations has accepted.
Retire Edge after the cutover is verified
Once all environments run on the new gateway, the team archives the final Edge exports, revokes Edge credentials and removes Edge-facing network routes, then decommissions the Edge components and their storage according to the organization's retention policy. Confirm retention obligations with the compliance team before deleting any audit or traffic data. Done means Edge no longer receives traffic, its access has been removed and the decommissioning record is filed with the change board.
Evidence an auditor or regulator will ask for after the switch
Whichever path you choose, the switch from Edge for Private Cloud leaves a trail that auditors and regulators will want to see. The cards below cover the records that connect the old platform, the new gateway and the cutover decision, so each claim can be traced to a dated artifact. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any audit report or certification.
Inventory of exposed APIs
Start with a complete list of every proxy, base path, environment and hostname that Edge for Private Cloud exposes today, including internal-only and deprecated APIs. For each entry, record the owner, the data classification and whether it is reachable from outside your network. Compare this inventory against the routes in the new gateway after cutover. Any route that appears in one list but not the other needs an explanation in writing.
Chosen version and patch process
Record the platform version you run, the date it was chosen and the reason. Edge for Private Cloud 4.53.01 reaches end of life on June 30, 2027, after which Apigee stops providing bug fixes, security updates and hotfixes for that line. For an open-source gateway, document who watches upstream security advisories, how patches are tested, and how long a critical fix may take to reach production. Confirm the support window of any release you adopt with its maintainers.
Configuration in version control
Keep gateway routes, plugins, policies and upstream definitions in a Git repository with reviewed merges and protected branches. Auditors typically ask who changed a route, when, and who approved it, so commit history and pull request records are the evidence. Declarative formats such as a standalone configuration file let you show that production matches the approved state. Export your Apigee proxy bundles before decommissioning so the historical configuration remains available.
Access and key-management records
Document every consumer application, API key, OAuth client and administrator account that existed in Edge, and show how each one was migrated, rotated or retired. Record which identity provider authenticates administrators and how role assignments are reviewed. Confirm that keys issued during the migration were rotated and that revoked credentials can no longer call the gateway. Ask your team to produce these records as exports, not as memory.
Gateway traffic logs
Define what the gateway logs, where those logs are stored and how long they are retained. Retention periods should come from your own regulatory obligations, not from a platform default. Confirm that logs capture caller identity, route, status and timestamp without storing request bodies that contain personal or payment data. Test that logs from the old and new gateways can be searched side by side during the overlap period.
Signed cutover record
Produce a dated record for each environment that lists the scope moved, the rollback plan, the test results, the people who approved the change and the time traffic moved. Sign-off should come from the API owner, the security function and the platform team. Keep the record alongside the inventory and version evidence so an assessor can follow one change from request to production. DeployOpen can prepare this record as part of a fixed-scope engagement, but the approvals must come from your organization.
What teams ask before moving off Apigee Edge for Private Cloud
Does upgrading to Apigee Edge 4.54.00 buy enough time to plan a move?
Upgrading to 4.54.00 keeps you on a supported line, but it only postpones the decision. The supplied Apigee documentation states that 4.53.01, first released on August 26, 2025, reaches end of life on June 30, 2027, and that continuous support requires running a version within its 18-month full support window. Confirm the 4.54.00 support dates directly with Apigee before you commit budget, and count the upgrade itself as work: proxies, custom Java callouts, environments and the Edge management components all need regression testing. Many teams use the upgrade window to export proxy bundles and run a parallel gateway in test, so the migration is not rushed against the end-of-life date.
Is Apigee hybrid enough if our data must stay in our own data center?
It depends on what the residency rule covers. In Apigee hybrid, the runtime plane runs on your Kubernetes, so API traffic is processed in your environment, but Google hosts the management plane. Check with your compliance lead whether configuration, analytics, logs or developer data held in that management plane fall under the rule. If the requirement covers all data at rest and in transit, a fully self-hosted gateway such as Apache APISIX, which runs in traditional, decoupled or standalone mode, or Kong Gateway OSS keeps every component under your control. Ask Google to put the data flows in writing before you decide.
What drives the cost of moving off Edge for Private Cloud?
Cost has three layers: licensing, implementation and running the platform. The open-source gateways listed here, including Apache APISIX (Apache-2.0), Apache Gravitee and WSO2 API Manager (Apache-2.0), carry no license fee for the core product, but some features, such as Gravitee Enterprise Edition features or the WSO2 commercial subscription, do. The main drivers are:
- Number of proxies, shared flows and custom policies that need rewriting
- Developer portal scope, since a portal may need to be built or chosen separately
- Environments, high availability and monitoring infrastructure
- Support and the staff who run the platform after go-live
Ask any provider for a written quote that separates one-time work from recurring support and infrastructure.
How long does a migration from Edge for Private Cloud take?
No duration in our sources applies to every estate, so treat any number as a planning input, not a commitment. Duration depends on how many proxies and environments you run, how many Apigee policies need custom plugins, whether a developer portal must be replaced, and how many consumers must re-register keys. Traffic cutover is usually staged environment by environment, which adds time but reduces risk. Ask for a timeline that lists each phase, the dependencies and the testing criteria for cutover.
What must our team supply before a migration starts?
The team must provide access and knowledge that only your organization holds. Expect to supply:
- Named engineers who know the current proxies, custom policies and backend services
- Staging and production environments with network paths to backends and identity providers
- Exports of proxy revisions as bundle zip files, along with product, app and key configuration
- Decision makers for the portal, analytics and monetization requirements
The export step is documented in the Apigee export guidance, which requires an IAM role that permits reading the entities. Confirm the exact permissions with your Apigee administrator before work begins.
Can our own engineers migrate without outside help?
Yes, many teams can, provided they have experienced API gateway engineers and the time to learn the target product. Apache APISIX has a Getting Started guide and documented deployment modes, and Kong Gateway OSS is installable through Docker, Kubernetes or Linux packages. The harder work is not installation but mapping Apigee policies, testing behavior parity and running the platform after go-live. External help is most useful for the policy mapping, the security review of the new gateway, and the handover runbooks. Decide internally which of these your team can own.
What does a fixed-scope engagement with DeployOpen cover?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure. For this migration, a fixed-scope engagement would normally cover the target architecture, the gateway deployment, proxy and policy migration, integration with your identity provider, security testing, and documentation for operators. Scope, deliverables and timelines are agreed in writing before work starts, and ongoing support or upgrades can be added as a retainer. DeployOpen does not publish a price list. Request a written scope that names each deliverable, the environments covered and the acceptance tests.
When upgrading to 4.54.00 is enough and when it is not
Upgrading to 4.54.00 is enough when your priority is to stay on a supported Edge release while you plan the next move, and when your APIs, policies and portal are stable enough to carry through an in-place upgrade. An upgrade keeps the Edge operating model: organizations, environments, API proxies, shared flows, products, developers and apps stay where they are, and the Edge management UI, management API and existing deployment scripts keep working. Before you commit, confirm with Google the end-of-life date for 4.54.00 and the full support window that applies to it, and check whether the upgrade path from 4.53.01 is supported for your exact topology. Continuous support depends on running a version inside its 18-month full support window, so the date you confirm sets your next deadline.
An upgrade does not remove the deadline, it moves it. Edge 4.53.01 reaches end of life on June 30, 2027, and 4.54.00 will eventually face its own end-of-life date, so every upgrade cycle buys time and adds a project. Carrying the platform costs money in several places: vendor support and licensing for the Edge stack, the infrastructure for a multi-component installation, the staff hours for each upgrade rehearsal and test cycle, and the production risk of each change window. A replacement moves those costs into a one-time implementation and then a recurring run cost for the new gateway. Ask any implementation partner for a quote that states the scope in writing, including the upgrades, patching and support it covers after go-live.
The team you have decides which path is realistic. An upgrade keeps your current Edge administrators productive and preserves the policy knowledge they already hold. A replacement needs people who can run a configuration store such as etcd, operate the gateway through its Admin API, manage declarative configuration in version control, and write or maintain plugins in the languages the gateway supports. Developer portal ownership also needs an explicit decision, because Edge's portal does not carry over automatically. Inventory the Edge skills and on-call coverage you have, identify who will own each layer after cutover, and use that inventory to decide whether an upgrade buys enough time for your team to build those skills.
How DeployOpen plans and deploys a replacement inside your network
DeployOpen plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Edge for Private Cloud replacement, we start from your 4.53.01 estate and its end of life on June 30, 2027, then build and hand over the gateway you choose in your environment.
How we scope
- Inventory every Edge organization, environment, proxy, shared flow, product and portal your teams depend on before choosing a target.
- Agree the gateway option in writing, whether that is an upgrade to 4.54.00, Apigee hybrid, or an on-premises open-source gateway such as Apache APISIX or WSO2 API Manager.
- Engagements are fixed-scope, so deliverables, environments and timelines are written down before any work starts, with the quote following from that scope.
How we build
- Stand up the chosen gateway and control plane in your infrastructure, including etcd or database tiers, TLS, identity integration and logging sinks.
- Rebuild proxies and policies as routes, plugins or mediation flows, documenting each Apigee policy that needs a custom plugin or an enterprise feature.
- Test routing, authentication, rate limiting and failover in a non-production environment that mirrors your network before any cutover is scheduled.
How we hand over
- Deliver architecture records, runbooks, configuration in version control and evidence of each test run for your security and compliance reviewers.
- Walk your platform and API teams through daily operation, upgrades, certificate rotation and backup and restore of the gateway configuration.
- Cut traffic over environment by environment with a documented rollback path, and confirm with your auditors which controls the evidence supports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped separately from the original project.
- Plan version upgrades against each open-source project's published release line, so you are not running an unsupported gateway after cutover.
- Confirm with your chosen vendor or project which support tier, security advisory channel and long-term support terms apply to your version.
