Apigee or Apache APISIX: which fits your API program
Apigee fits teams that want Google-operated analytics, monetization and a developer portal, while APISIX fits teams that need the gateway running in their own infrastructure under the Apache-2.0 license. Most readers arrive with a concrete trigger: a renewal quote, the end-of-life date for Apigee Edge for Private Cloud, a data residency rule that limits where traffic and configuration may live, or a concern about being locked into one vendor's control plane. Any of these can justify a move, but none of them settles which platform fits. The right answer depends on the trigger's actual requirements, so start by writing those down before comparing features.
APISIX is a strong fit when the gateway itself must stay under your control. Its configuration lives in etcd and changes apply without restarts, its Admin API listens on port 9180 in traditional mode, and its standalone mode can load routes from a file such as conf/apisix.yaml that you version in Git. Ask who will own the etcd cluster, the TLS certificates and the upgrade calendar, because those costs recur and fall to your team. APISIX does not ship a monetization engine or a full developer portal out of the box, so confirm early whether those are requirements or nice-to-haves.
Apigee earns its place where API product management is a business function, not just a technical one. Its analytics, API product packaging, developer onboarding and monetization are the parts that take the most effort to rebuild. Before deciding, check three things: how much product management your business needs, where traffic and configuration may legally sit, and who will run the platform after go-live. Verify current Apigee deployment options and the Edge support dates directly with Google, and review the APISIX deployment modes documentation against your own network design.
Which team each platform suits
Teams whose main job is to package APIs as products, sell access through plans, and onboard external or partner developers usually get more from Apigee's built-in analytics, monetization and developer portal. Apache APISIX is a strong gateway, but it does not ship a monetization model or a developer portal. Those layers have to be added through another product or built in-house, and that work sits with your team.
- Fit holds when: developer onboarding, API product catalogs, quotas per plan and billing are core to the business and someone on the team owns them full time.
- Cost of getting it wrong: choosing APISIX without a portal plan can leave developers with keys, docs and approvals handled by email or spreadsheets, which slows partner onboarding.
- Portal options to evaluate: a self-hosted portal from another open-source API manager, or a catalog such as Backstage, each with its own scope and maintenance.
- Monetization is separate work: APISIX rate limiting and traffic controls are available, but usage billing needs a data pipeline and a billing system.
- Ask before deciding: which portal, billing and analytics features your product owners use today, and which of them would move to another system.
Confirm with your product owners which Apigee features they use weekly before you price the rebuild.
Platform teams that already run Kubernetes and GitOps tooling tend to find Apache APISIX a natural fit. APISIX runs as a Kubernetes ingress controller, can be managed from declarative configuration, and its traditional, decoupled and standalone deployment modes let the team choose how much state it operates. The condition is that the team is comfortable owning etcd, the Admin API and gateway upgrades.
- Fit holds when: the platform team already operates Kubernetes clusters, etcd or similar stateful services, and has an on-call rotation for infrastructure.
- Deployment choice: standalone mode reads a YAML or JSON file and hot-reloads it, which suits GitOps pipelines; decoupled mode suits larger fleets sharing one configuration store.
- Cost of getting it wrong: a team without Kubernetes depth can end up running an unpatched gateway or a configuration store with no backup plan.
- Ports to plan for: traditional mode uses port 9080 for client traffic and port 9180 for the Admin API, which affects network policy and exposure.
- Ask before deciding: whether your Kubernetes platform team will own gateway upgrades, plugin runners and the APISIX Ingress Controller release cycle.
Check the APISIX downloads page for the current release and the upgrade path your team will follow.
Banks, healthcare providers and public sector bodies often need API traffic, logs and credentials to stay inside their own cloud accounts, data centers or air-gapped networks. Apache APISIX is Apache-2.0 licensed and can run entirely within that boundary with no required external control plane. This fits teams whose main constraint is where data flows, not which features are included.
- Fit holds when: residency rules, outage tolerance or contractual limits require every gateway node and log destination to stay under your control.
- Licensing clarity: the Apache-2.0 license removes license-key gating from the gateway itself, which simplifies procurement review.
- Cost of getting it wrong: a regulated team that adopts a gateway without building audit logging, access reviews and change records may struggle at assessment time, since DeployOpen prepares evidence but auditors issue the reports.
- Identity integration: the openid-connect plugin works with Keycloak, Entra ID, Okta and similar providers, so keep identity in your own tenancy.
- Ask before deciding: which controls your assessor will test on the gateway, and whether your current Apigee deployment already meets them.
Confirm the residency requirements in writing with your compliance lead before you select a deployment mode.
Teams running Apigee hybrid already operate a customer-run runtime on Kubernetes while Google hosts the management plane. For them, the question is less about the runtime and more about whether to keep the Google-hosted control plane. Moving to APISIX removes that external dependency, but it also removes the management features that come with it, so the migration has to rebuild both the runtime and the management workflow.
- Fit holds when: the management plane itself is the constraint, such as a requirement that no management traffic leaves your network.
- Shared work: your Kubernetes operations, observability and certificate handling may transfer to APISIX with limited change.
- Cost of getting it wrong: a hasty cut-over can leave two gateways running in parallel for longer than planned, doubling operational load.
- Support path: Apigee hybrid support differs from running open-source software, so you will need your own support arrangement or a retainer.
- Ask before deciding: which hybrid components you would replace, and which Apigee policies depend on the Google-hosted plane.
Review the sibling page on Apigee hybrid versus a fully self-hosted gateway before you set a cut-over date.
Scenarios where each option is the better fit
This table sets common situations against the platform that usually fits them better, with the condition that would change the answer. Read it as a starting point for your own environment, not a verdict, since portal needs, data rules and staffing vary by organization. The main takeaway is that APISIX suits teams that want hosting control and a permissive license and can supply their own portal and analytics, while Apigee suits teams that want those pieces managed by the vendor.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Apigee Edge for Private Cloud approaching end of life | Apache APISIX (or a commercial upgrade path) | Edge for Private Cloud 4.53.01 reaches end of life on June 30, 2027, per Apigee documentation. APISIX fits if you want to leave the Edge stack entirely, but confirm the migration effort with your own proxy inventory first. |
| Strict on-premises rules for traffic and logs | Apache APISIX | APISIX runs fully inside your network in traditional, decoupled or standalone mode. Apigee hybrid still relies on Google for the management plane, so confirm with your regulator whether that split is acceptable. |
| Need for a managed developer portal and monetization out of the box | Apigee | Apigee bundles portal, analytics and monetization features. With APISIX you build or add a portal yourself, so choose Apigee if those features are central and you lack staff to build them. |
| High-volume internal east-west or service-to-service traffic | Apache APISIX | Self-hosted gateways avoid per-call charges that Apigee applies to its billing model. Confirm your call volume and the current Apigee pricing terms with Google before deciding. |
| Small team with no API product managers or portal staff | Apigee | Managed products reduce the operating burden on platform engineers. APISIX suits teams with platform or SRE capacity to run etcd, upgrades and plugins. |
| Need to avoid vendor license changes or lock-in | Apache APISIX | APISIX is licensed under Apache-2.0 and its routes and plugins can be exported as configuration. Check that your required plugins are open source, since some capabilities may sit in commercial add-ons. |
| Heavy reliance on existing Apigee policies and analytics dashboards | Apigee (short term) | Rebuilding policies and reporting takes effort. Stay on Apigee while you map policies to APISIX plugins, then move in stages. |
Where traffic, configuration and logs live
The four deployment questions that decide this comparison are where requests pass, where configuration is stored, who operates the control plane and where logs and personal data end up. Apigee splits these between Google and your team in different ways depending on the product, while APISIX keeps every component inside your own network if you choose.
Google-managed Apigee
In the Google-managed model, Google runs the runtime and management plane, so proxies, configuration and analytics sit in Google's environment. Your team gives up direct control over where that data is processed and how upgrades are scheduled. Before you choose it, ask Google in writing which regions host your organization's data, how logs are retained and what your audit rights are.
Apigee hybrid with a Google-hosted management plane
Apigee hybrid runs the runtime plane on your Kubernetes cluster, so request traffic can stay in your network, while Google hosts the management plane that holds proxy definitions and configuration. Traffic and management data therefore follow different paths. Confirm with Google exactly which configuration, analytics and logs leave your environment and which network connections your cluster must keep open.
APISIX traditional, decoupled and standalone modes
APISIX offers three deployment modes. Traditional runs the data plane and control plane together, decoupled separates them around one etcd cluster, and standalone reads routes from a YAML or JSON file with no etcd at all. Choose the mode before you build the platform, because it sets where configuration lives, how many components you operate and how changes reach each gateway node.
Admin API port and etcd operations
In traditional mode APISIX serves client traffic on port 9080 and the Admin API on port 9180, so the Admin API must be restricted to administrative networks and never exposed to clients. etcd holds all routes, plugins and consumers in that mode, which makes its backup, quorum and certificate management part of your runbook. Confirm these ports and settings against your version's documentation before you write firewall rules.
Data residency and log retention
Where logs, access records and personal data are stored often decides the migration more than gateway features do. With APISIX, you choose the log sinks, such as your own Prometheus, ClickHouse or SIEM, and set retention yourself. Map each log field, including consumer identifiers and tokens, to a documented location and retention period, and check whether any copy leaves your jurisdiction.
Identity and compliance evidence
APISIX's openid-connect plugin can federate with identity providers such as Keycloak, Microsoft Entra ID or Okta, so authentication decisions stay with your identity stack. DeployOpen can prepare configuration, access controls and evidence for a compliance assessment, but independent auditors issue any report or attestation. Ask your auditor early which control evidence they will request from the gateway, its logs and its change records.
Where Apigee's analytics, monetization and portal outdo a plain gateway
A gateway routes, authenticates and limits traffic, but it does not answer the business questions that an external API program raises. Apache APISIX is a gateway, not a product management suite. It does not provide a developer portal, API product packaging, developer app registration with issued keys, subscription or plan management, or invoicing. Apigee bundles these functions with its runtime, which is why teams running a public developer program often find that the gateway is the easy part of the move. APISIX's more than 100 built-in plugins cover authentication, traffic control and observability, but they operate on requests, not on customers, plans or revenue.
The condition that makes this gap matter is specific: an external developer program, a partner ecosystem, or internal chargeback where API consumers are billed or reported per team. If you need to show a partner its quota usage, sell tiers of access, or charge business units for calls, the reporting and billing logic must come from somewhere. With APISIX, that means choosing or building a developer portal, an analytics stack (for example, logs and metrics feeding Prometheus and Grafana or ClickHouse), and a billing or entitlement layer. Each is a separate product or project with its own license, hosting and support needs, and each adds integration work that the APISIX deployment does not include.
Before deciding, list every business function your API program uses in Apigee today, including analytics dashboards, quota plans, monetization rules and portal pages, and mark which ones are used by external consumers. Then ask each candidate vendor, including API7.ai for its enterprise offering described on its site, which of those functions it covers and which it leaves to you. Confirm the portal and billing options against your own requirements in a proof of concept. If your API program is internal and nobody is billed, the gap may be small. If it is external and monetized, budget for the portal and billing layer as separate work from the gateway migration.
What drives cost on each side over three years
This table sets Apigee's commercial charges against the components you own when running Apache APISIX, so you can see which costs are one-time and which recur. Use it to frame a quote request on both sides, not to predict a total, since Apigee pricing depends on your contract and no figures are shown here. The main takeaway is that APISIX removes license charges but moves portal, analytics, support and staffing costs onto your budget.
| Cost component | Who is paid | One-time or recurring, and what drives it |
|---|---|---|
| Apigee platform charges | Google (Apigee contract) | Recurring. Driven by contract tier, environments, API traffic volume and add-on subscriptions. Ask for every metered unit in writing. |
| Apigee analytics and portal | Google (Apigee contract) | Recurring if bundled or sold as add-ons. Confirm which analytics and developer portal features are included in your tier. |
| APISIX software license | No license fee (Apache-2.0) | None for the gateway itself. Commercial support from a third party, if chosen, is a separate recurring contract. |
| Infrastructure for gateway and etcd | Your cloud provider or data center | Recurring. Driven by request volume, number of nodes, etcd cluster size and high availability design. |
| Implementation and migration | DeployOpen or your internal team | One-time. Driven by number of proxies, shared flows, custom policies needing Lua or plugin runners, and cutover planning. |
| Developer portal and analytics stack | Your team, or a vendor you choose | One-time build plus recurring hosting. Driven by portal scope, metrics pipeline such as Prometheus and Grafana, and log retention. |
| People who run etcd, upgrades and plugins | Your staff or a retainer provider | Recurring. Driven by on-call expectations, APISIX release cadence and the number of custom plugins you maintain. |
What a move from Apigee to APISIX involves
The sequence turns Apigee proxies, shared flows and products into APISIX routes, upstreams and plugins, then proves the new gateway carries live traffic before each environment is cut over. Each step closes with a check the team can verify.
Inventory proxies, shared flows and products
The API owner and an Apigee administrator list every proxy, shared flow, API product, developer app, key and target server in each environment, and record which consumers call each one. Platform engineering marks which items carry traffic today and which are retired. The step is done when the inventory has an owner, an environment and a traffic status for every entry, and the team agrees the list of APIs in scope with the business owners who sign off on the cutover.
Export proxy bundles and configuration
An Apigee administrator downloads a bundle for each proxy revision that must move, using the Apigee management API or the apigeecli tool, and exports product and configuration data alongside them. The team stores the bundles in version control with the source environment noted. The step is done when every in-scope revision has a saved bundle that can be opened and read, and the team has confirmed which revision is deployed in production. The how-to page on exporting Apigee data covers the permissions and commands.
Map policies to routes, upstreams and plugins
An API engineer translates each proxy's flow, conditions and policies into APISIX routes, upstreams and plugins, keeping the configuration in files so changes can be reviewed. Rate limits, key checks, header transforms and caching are matched to the built-in plugins, and the team records each mapping in a table linking the Apigee policy to its APISIX equivalent. The step is done when every policy in the inventory has a mapped target or a flagged gap, and a reviewer has signed off the table.
Identify policies that need custom plugins
The engineering team marks the Apigee policies with no direct equivalent, such as JavaScript or Java callouts, custom message logic, or policies tied to Apigee-specific analytics. For each gap it chooses between a Lua plugin, a plugin runner in Java, Go or Python, a WebAssembly plugin, or moving the logic to the backend. The step is done when each gap has a written decision, an owner and a test case, and the team has confirmed that the chosen approach is supported by the APISIX version it will run.
Rebuild the developer portal and analytics
Because APISIX is a gateway rather than a full API management product, the team selects and deploys a developer portal and an analytics stack, and connects them to the gateway's logging and metrics output. Developers need API documentation, app registration, key issuance and approval workflows carried over from Apigee. The step is done when a test developer can register an app, receive a credential and see traffic reports for a sample API in the new stack, and the business reporting gaps are listed for later work.
Run parallel traffic and validate responses
The team deploys the APISIX routes in a non-production environment and sends copied or test traffic through both gateways, comparing status codes, response bodies, headers, latency and rate-limit behavior. Identity integration is tested against the same identity provider the Apigee proxies use, with the openid-connect plugin where it applies. The step is done when the differences are recorded, each one is either fixed or accepted by its owner, and the consumers that depend on specific behavior have confirmed their tests pass.
Cut over environment by environment
The team moves traffic one environment at a time, starting with the lowest-risk APIs, and keeps the Apigee proxy available as a fallback until the cutover is confirmed. Operations staff watch error rates, latency and consumer reports during each switch, and a rollback path is rehearsed before each change. The step is done when all in-scope APIs serve production traffic from APISIX, the fallback has been retired on a documented date, and the decommissioning record is filed. Sibling pages on migration and cost cover the detail for each stage.
Questions buyers ask before choosing APISIX over Apigee
What drives the cost of moving from Apigee to APISIX?
The cost depends on which Apigee charges go away and what replaces them. Apigee bills through its own licensing tiers and environment and subscription charges, while APISIX itself is Apache-2.0 licensed, so its software cost is zero. The remaining spend is infrastructure for etcd and the gateway nodes, implementation of routes and plugins, a developer portal you add yourself, support, and the staff who run the platform. Ask any quote to separate one-time work (migration, portal build, hardening) from recurring work (hosting, on-call, upgrades, support retainers). The biggest variable is how many Apigee policies need custom plugins, because that work is effort rather than licensing. For a line-by-line comparison, see Apigee cost vs self-hosted Apache APISIX and compare it against your own Apigee invoices.
How long does an Apigee to APISIX migration take?
The length depends on the number of proxies, the number of Apigee policies that have no direct APISIX plugin equivalent, and how many environments and consuming applications must cut over. No duration is fixed in the research for this topic, so ask for a timeline built from your own inventory rather than a generic estimate. Teams with many shared flows and custom JavaScript policies usually spend the most time, because those need custom plugins written in Lua, Java, Go, Python or WebAssembly. Traffic cutover, environment by environment, adds time because each consumer must be validated. Ask any vendor to state the assumptions behind the timeline and what is excluded.
Can an internal team run APISIX without outside help?
Many internal teams can run APISIX day to day, but the answer depends on existing skills in NGINX, etcd, Kubernetes or Linux and on who owns on-call. APISIX supports traditional, decoupled and standalone deployment modes, so the first decision is which mode fits your operating model. Standalone mode removes etcd but changes how configuration is managed. Internal teams often need help with the first migration, plugin development, identity integration and hardening, then take over operations. Ask any partner to state what they hand over, what runbooks and documentation they produce, and whether support is a separate retainer.
What does the Apigee Edge for Private Cloud end of life mean for timing?
Apigee documentation states that Apigee Edge for Private Cloud 4.53.01 reaches end of life on June 30, 2027, after which Apigee stops providing bug fixes, security updates, hotfixes or patches for that version line. Continuous support requires running a version within its 18-month full support window. If you run Edge for Private Cloud, that date sets a hard deadline, so plan the decision between upgrading, moving to Apigee hybrid, or replacing the gateway well before it. Confirm your exact version with Apigee and your support contract, because a migration that starts late may leave you running an unsupported line.
How do we handle the developer portal when moving off Apigee?
APISIX is a gateway, not a developer portal, so a portal must be provided separately. Apigee's integrated or Drupal-based portal covers API documentation, app registration, keys and approval flows, and each of these needs an equivalent in your new setup. Common choices include a portal in a self-hosted open-source API management product, or a catalog such as Backstage that documents APIs. Cost comes from building and maintaining the portal, the identity integration for developers, and the content work. Ask for a written list of what the portal must keep before choosing a tool, and confirm how key issuance and approval will connect to APISIX's authentication plugins.
What licensing terms should we confirm before choosing APISIX?
APISIX is a top-level Apache Software Foundation project released under the Apache License 2.0 (SPDX: Apache-2.0). Confirm three things. First, that the components you plan to use all fall under the same license, including any plugins, runners or dashboards you add. Second, which version you deploy, because the downloads page does not mark any release as long-term support, so you must plan your own upgrade cadence. Third, whether you want a commercial subscription from a third party such as API7.ai for support or enterprise features, and what that agreement covers. Ask your legal and procurement teams to review the license texts and any vendor terms in writing.
Which Apigee features need custom work in APISIX?
Features that map directly to APISIX plugins, such as authentication, traffic control and observability, usually move with less effort. Apigee features that depend on Apigee-specific constructs, such as certain policy types, shared flow logic, analytics add-ons and monetization, need custom plugins or a replacement tool. APISIX offers more than 100 built-in plugins and supports writing custom ones in several languages, so the gap is usually narrower for gateway policies than for analytics or portal functions. Ask for a policy-by-policy mapping as the first deliverable, so you can see exactly which items are native, custom or out of scope.
How DeployOpen helps evaluate and move from Apigee to APISIX
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Apigee to Apache APISIX evaluation, we start from your real traffic, policies and hosting constraints, then build and hand over a gateway your team can run.
How we scope
- Inventory the Apigee proxies, shared flows, products, environments and portal content in scope for the move.
- Record which Apigee policies map to APISIX plugins and which need custom plugins written in Lua or another plugin runner.
- Agree deliverables, timelines and responsibilities in a fixed-scope written statement before any work starts.
How we build
- Stand up APISIX in your chosen deployment mode, traditional, decoupled or standalone, inside your own infrastructure.
- Rebuild routes, upstreams and authentication, including openid-connect integration with your existing identity provider.
- Test traffic cutover environment by environment, with rollback steps and observability wired to your own monitoring stack.
How we hand over
- Document the gateway configuration, plugin inventory, deployment topology and the Apigee features that were not carried over.
- Deliver runbooks for upgrades, backups of the etcd configuration store and Admin API access controls.
- Walk your platform, security and API teams through operations so they can run the gateway without outside help.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Confirm the APISIX release and support status with the project before each upgrade, since the downloads page marks no release as long-term support.
- Ask for a written quote built from the agreed scope, which sets out the components, one-time work and recurring support.
