Apigee vs Kong Gateway open source: when each option fits
If you need a managed control plane with analytics, monetization and a developer portal already built in, Apigee fits better than a bare gateway. If you need a gateway your own team can run on infrastructure you control, with configuration held in Git and no per-call billing, Kong Gateway Open Source fits that situation, provided you accept that the portal, analytics and monetization layers must come from elsewhere. Renewal dates, data residency rules and the wish to stop paying per call are the usual triggers, but they do not settle the choice on their own. The decision turns on three questions: how much of the API management stack you need from one product, whether you can run a gateway on infrastructure you own, and who will patch and upgrade it.
The first question is scope. Apigee bundles proxies, policies, analytics and portal features in one commercial product, while Kong Gateway's README describes routing, load balancing, health checking, JWT, basic auth, OAuth and ACL authentication, rate limiting and transformation plugins. Inventory the Apigee features your APIs actually use, including shared flows, API products, developer app keys and reporting, and map each one to a plugin, a separate tool or a gap. The second question is hosting. Kong Gateway can run in DB-less mode from declarative files kept in Git, which suits a team that wants configuration reviewed like code. Confirm which of your rate limiting and OAuth2 needs depend on database-backed plugins, because the Kong deployment topologies documentation says only traditional mode supports them.
Which scenario favors Apigee and which favors Kong Gateway open source
This table matches common buying situations to the platform that usually fits them better. Read each row as a starting point, then check the reason against your own traffic, team skills and network rules before deciding.
| Scenario | Better fit | Why |
|---|---|---|
| Team already runs Apigee analytics, monetization and a portal | Apigee | Replacing those built-in reporting and developer portal functions means rebuilding them, which takes time and skills your team may not have yet. |
| Team manages gateway configuration in Git and wants declarative changes | Kong Gateway open source | DB-less mode reads declarative files that can be kept in Git, and decK syncs them to the gateway. |
| Regulated team must keep all API traffic and control in its own network | Kong Gateway open source | The open-source gateway runs entirely in your environment, though you must confirm which control plane features you need from the commercial edition. |
| Team with no in-house Kong experience and a tight internal skills plan | Apigee | Apigee's managed options reduce what your staff must operate, while Kong self-hosting puts gateway operations on your team. |
| Team needs rate limiting shared across a cluster or OAuth2 with database-backed plugins | Kong Gateway open source (confirm first) | These plugins need traditional mode with a database, so confirm the open-source edition covers your exact plugin set before committing. |
| Team needs features only in Kong Gateway Enterprise, such as fully self-hosted control planes | Apigee | Enterprise-only features carry commercial licensing, so compare that subscription directly against Apigee's pricing terms. |
| Team leaving Apigee Edge for Private Cloud before its end of life | Kong Gateway open source | Edge for Private Cloud reaches end of life on June 30, 2027 (Apigee documentation), so a move to a self-run gateway avoids a second platform upgrade. |
What the Kong Gateway open-source edition covers and where it stops
The Apache-2.0 Kong Gateway edition covers routing, authentication, traffic control and declarative configuration, which is enough for many API gateway workloads. The cards below separate what runs in the open-source edition from what depends on traditional mode, Konnect or Enterprise features, so you can test each Apigee capability against a specific Kong version.
Authentication plugins for consumers
The open-source edition ships JWT, basic auth, OAuth and ACL plugins that enforce who can call an API and which consumer group may reach which route. Map each Apigee verify-API-key, OAuth and JWT policy to one of these plugins, then test token validation with your own identity provider. Note that the OAuth plugin behaves differently across modes, so check the OAuth2 entry in the boundary card before you rely on it.
Rate limiting and request transformation
Rate limiting and transformation plugins replace Apigee quota and message mediation policies for many routes. Local rate limits work without a shared store, which suits single-node or DB-less setups. Rebuild each quota from your Apigee product definitions and run load tests to confirm the limit counts match what developers were promised.
DB-less declarative configuration in Git
In DB-less mode Kong reads its entire configuration from declarative files that you can keep in Git and review through pull requests. There is no database to back up, but the Admin API is read-only, so every change goes through the file pipeline. Plan how Apigee environments and shared flows become separate files, and confirm the file format for your target version before you write tooling around it.
Hybrid control and data plane separation
The open-source edition supports separating the control plane from data plane nodes, which lets you place gateways close to upstream services in several zones. Decide early whether a central control plane runs in your own network, since the control plane sits with your data plane rather than in Kong's cloud. Test node registration and failover in each zone, and confirm with Kong which hybrid features are open source for your version.
decK for syncing configuration
The decK tool, also Apache-2.0 licensed, exports a running gateway with a dump command and applies declarative files to open-source Kong Gateway. It gives a diff before changes land, which helps reviewers compare an Apigee proxy migration against the live state. Keep decK versions aligned with your gateway release, and script the sync step in your CI pipeline so manual edits do not drift from Git.
Where the open-source edition stops
Database-dependent plugins such as cluster-strategy rate limiting and OAuth2 need traditional mode with a database, so a DB-less design cannot use them. Konnect management, self-hosted Enterprise-only features and newer Enterprise releases sit outside this edition. The open-source repository's newest line is 3.9, with no published support window, so ask Kong directly about portal, analytics and GUI capabilities for your version before you plan around them.
How Apigee and Kong Gateway open source compare on capabilities
This table sets Google-managed Apigee against the Apache-2.0 Kong Gateway open-source edition on the capabilities that drive a gateway decision. Read each row as a question to ask: where the open-source edition covers the need, the cell says so, and where the supplied facts do not confirm a capability, the cell tells you what to confirm with Kong or Google. The main takeaway is that the open-source edition covers the core gateway work, while analytics, portal, monetization and support depend on what you add or buy.
| Capability | Apigee (Google-managed or hybrid) | Kong Gateway open source (3.9 line) |
|---|---|---|
| Gateway policies and plugins | Apigee policies within proxies and shared flows, with custom extensions for needs outside the built-in set | Plugin-based gateway with routing, load balancing and health checking; confirm the plugin set for your version |
| Authentication | API key, OAuth and JWT handling through Apigee policies; confirm the exact policy list with Google | JWT, basic auth, OAuth and ACL plugins listed in the Kong Gateway README; database-dependent OAuth2 needs traditional mode |
| Rate limiting | Quota and spike arrest policies, configured per proxy or product; confirm scope options with Google | Rate limiting plugin; cluster-strategy rate limiting needs traditional mode with a database |
| Transformation | Mediation policies for message and header transformation; confirm coverage for your payload types | Transformation plugins listed in the Kong Gateway README; confirm they meet your mapping needs |
| Deployment modes | Google-managed runtime, hybrid with a customer-run runtime on Kubernetes, or Edge for Private Cloud | Traditional mode with a database, DB-less declarative mode, or hybrid control and data plane separation |
| Configuration as code | Proxy bundles and API-based configuration; confirm the export and CI workflow with Google | Declarative files in Git for DB-less mode; decK exports and syncs configuration to open-source and Enterprise Kong |
| Analytics | API analytics available as a separately purchased capability; confirm what is included in your contract | No built-in analytics dashboard in the open-source edition; plan logging and metrics pipelines yourself |
| Developer portal | Integrated developer portal; confirm the portal option for your Apigee edition | No developer portal in the open-source edition; a portal or catalog must be added separately |
| Monetization and licensing | Monetization is a commercial add-on; confirm terms with Google | Apache-2.0 repository; features in Kong Gateway Enterprise are commercially licensed, and the open-source repository has no published support window |
Where traffic, configuration and logs sit with each option
Apigee and Kong Gateway put traffic, configuration and logs in different places, and that split decides who answers a residency or audit question. Use the cards below to map each option's data path against your own network diagram before comparing features.
Google-managed Apigee control and data
In Google-managed Apigee, Google operates the management plane and the runtime in its environment, so API traffic, proxy configuration and analytics data follow Google's hosting model. Ask Google which regions and components hold each data type for your organization, and confirm whether analytics and debug data leave the region you need. Your team controls proxies and policies but not where the platform runs.
Apigee hybrid with a customer-run runtime
In Apigee hybrid, the runtime plane runs on your Kubernetes clusters, so request processing and local logs stay in your infrastructure, while the management plane remains with Google. Map which configuration, analytics and telemetry still reach Google, and confirm that against your own environment and the current hybrid documentation. Plan for two sets of operations: your cluster and the managed control plane.
Apigee Edge for Private Cloud lifecycle
Apigee Edge for Private Cloud keeps the full stack on your own servers, but its version line has a fixed horizon. Version 4.53.01 reaches end of life on June 30, 2027, after which bug fixes, security updates and patches stop for that line. Continuous support requires running a version within its 18-month full support window, so schedule the upgrade or migration with that date in view.
Self-hosted Kong Gateway nodes
Open-source Kong Gateway nodes can run in your own network, on Docker, Kubernetes or Linux packages, with traffic, logs and configuration held where you deploy them. In DB-less mode, configuration lives in declarative files you can keep in Git. Confirm where your logging plugins send data and where any database used in traditional mode is hosted.
Konnect control plane and data placement
Kong Konnect hosts the control plane as SaaS, while data plane nodes can be self-hosted, run as serverless gateways, or run as Dedicated Cloud Gateways that Kong manages on AWS, Azure or GCP. Decide which metadata and configuration reach Kong's control plane and whether that is acceptable for your residency rules. Confirm each hosting choice against your own environment and contract terms.
Compliance evidence stays with you
Neither Apigee nor a self-run Kong Gateway produces an audit report on its own. For Kong open source, the evidence for access control, change records, log retention and encryption is assembled by your team and reviewed with your auditor. Ask each vendor for the documentation they can provide, then map it to the controls your assessment covers. DeployOpen can prepare systems and evidence, but independent auditors issue the findings.
The 3.9 release line and the support question buyers must settle
The newest open-source Kong Gateway release line is 3.9, and the latest tag on the GitHub releases page in that series is 3.9.4, published October 12, 2026. Kong Gateway Enterprise has moved on: it reached 3.16 on September 15, 2026 and has shipped quarterly releases since March 2025. Buyers should read this gap as a statement about where new features and fixes land, not as a statement that the open-source code is unsafe today. The practical question is whether a 3.9 deployment will receive security patches on a schedule your organization can rely on, and Kong's published material does not answer that for the open-source edition.
Kong's version support policy applies only to Kong Gateway Enterprise, so no support window is published for Kong API Gateway OSS. Kong's pricing page also places fully self-hosted gateways with a local control plane and data plane inside the commercial Kong Gateway Enterprise offering, and notes that Kong Gateway 3.10 removed the unlicensed free mode from Enterprise. For a regulated buyer, this means the open-source option is a self-run build of a repository that is still licensed under Apache-2.0, with no vendor commitment on patch timing. Ask Kong in writing whether it will publish a security advisory process and patch window for the 3.9 line, whether it will back-port fixes, and what the end-of-life date for 3.9 will be.
Whoever runs the gateway owns the upgrade path. If you stay on OSS 3.9, your team, or a partner such as DeployOpen under a written scope, must track CVEs in Kong, its bundled NGINX and OpenResty components, and the plugins you use, then build, test and roll out the patched image. If you move to Kong Gateway Enterprise, the commercial contract should state which versions are supported, how long and what the upgrade test expectations are. Before choosing, put these questions to Kong and record the answers: the support window for 3.9, the process for critical fixes, the expected migration path to a newer OSS line if one appears, and the cost of Enterprise for a fully self-hosted deployment. Those answers decide whether the platform fits your patch management policy.
What drives the cost of Apigee against self-run Kong Gateway open source
The cost gap between Apigee and self-run Kong Gateway open source is set by who pays for each component, not by a single licence line. Read each card below as a separate line in your own cost model, and ask for the same components in every quote so the comparison stays like for like.
Apigee licence and usage charges
Apigee charges come from your Google agreement, and the exact structure depends on the deployment model and the commercial terms you hold. Recurring usage, environment and subscription charges are the main drivers, so traffic growth and the number of environments will move the bill over time. Ask Google or your reseller to itemize every recurring charge by component, state the usage metric they bill against, and confirm which features sit in each tier. Also ask what changes at renewal and what the exit terms are for exporting proxies.
Kong open-source software and Enterprise options
The Kong Gateway repository is Apache-2.0, so the gateway software itself carries no licence fee. The cost question is whether you need features that sit only in Kong Gateway Enterprise, such as fully self-hosted control plane deployments that Kong's pricing page places in the commercial offering. Ask Kong for a written list of the Enterprise features your use case depends on, the license term, and the support and upgrade terms that apply if you buy it. Confirm that the open-source 3.9 line meets your plugin and deployment needs before you budget for Enterprise.
Infrastructure and the database in traditional mode
Infrastructure is a recurring cost on both sides, but Kong adds a database when you run traditional mode. Traditional mode is needed for database-dependent plugins such as cluster-strategy rate limiting and OAuth2, while DB-less mode needs no database and reads declarative files kept in Git. Compare the compute, load balancers, database high availability, backups and monitoring each option requires across your regions. Ask your platform team which plugins you need, since that choice decides whether you run a database at all.
Migration work for policies without direct equivalents
This is mostly a one-time cost. Apigee policies that have no direct Kong plugin, such as some custom mediation logic or specialized transformations, need custom plugins or a redesign, and each one must be written, tested and documented. Effort rises with the number of shared flows, custom JavaScript or Java callouts, and environments in scope. Ask any implementation partner for a written scope that lists each Apigee policy, its Kong mapping or custom plugin, and the test evidence for each one, before agreeing to a fixed price.
Developer portal and analytics you add yourself
Apigee bundles analytics and a portal that Kong's open-source edition does not provide in the same form, so you must choose and run replacements. Options include a portal from another open-source platform or a catalog in Backstage, plus metrics and logging pipelines for traffic and error reporting. Each one adds licensing, hosting, integration and maintenance work. Ask for the portal and analytics components named in the quote, the owner of each, and whether business reporting such as monetization is included or excluded.
Operating staff and upgrade work over time
Running Kong yourself is a recurring staffing cost. Your team handles upgrades, security patches, certificate rotation, on-call response and capacity planning, and Kong's version support policy covers only Kong Gateway Enterprise, so the open-source edition has no published support window. Enterprise support or an ongoing retainer is one way to cover that gap. Ask for the number of hours and roles your team needs each month, the upgrade cadence you will follow, and the escalation path if the open-source line stops receiving fixes.
What a move from Apigee to Kong Gateway involves
The sequence moves proxies, policies and portal-facing configuration from Apigee into a Kong Gateway OSS estate that is versioned in Git, tested against the same traffic, and then switched over one environment at a time. Each step has a check that tells the team when it can move on.
Inventory proxies, shared flows and products
Your platform or API team lists every API proxy, shared flow, product, app and key set in each Apigee environment, and records the upstream targets, the policies attached to each flow and the traffic volume per API. Security and product owners confirm which APIs are customer-facing and which carry regulated data. The step is done when the list reconciles with what the Apigee management API returns for each environment, and every proxy has an owner and a named cutover window. Teams usually do this themselves because they hold the Apigee knowledge, though an implementation partner can help with the audit of policies that have no direct equivalent.
Export proxy bundles and configuration
Download the current revision of each proxy as a bundle zip, along with product, app and key configuration, using the Apigee API or the apigeecli tool. Your team stores the exports in a version-controlled repository with the Apigee revision number recorded beside each one. The IAM permission needed for export must be granted to the person running the job, so confirm that before starting. The step is complete when every inventoried proxy has a stored bundle that can be opened and read, and a second person has checked the file list against the inventory.
Map flows and policies to Kong constructs
Translate each proxy's target endpoints into Kong services, match conditions into routes, and each Apigee policy into a Kong plugin where a built-in plugin exists. Policies such as JavaScript callouts, Java callouts, certain message logic and custom data stores have no direct match and need a custom plugin or a redesign, which your architects should list separately. The output is a mapping sheet with one row per policy showing the Kong equivalent, the owner and the disposition. Your architects and an implementation partner with Kong experience often lead this step, because the judgment calls about custom code affect the rest of the plan.
Choose DB-less or traditional mode by plugin needs
Decide the deployment mode before writing configuration. DB-less mode takes its configuration from declarative files and needs no database, which suits a Git-driven workflow. Traditional mode with a database is required for database-dependent plugins such as cluster-strategy rate limiting and OAuth2. Use the Kong deployment topologies documentation to confirm which plugins each mode supports, and record the decision with the reason. Your platform team makes this call, and the step is complete when each planned plugin is marked as supported in the chosen mode or the mode is changed to fit it.
Store configuration in Git and sync with decK
Write the declarative configuration for services, routes, consumers and plugins as files in a Git repository, and use decK to diff and sync those files to the open-source gateway. Your team sets up a review process so every change to a route or plugin goes through a pull request. Run a diff against a non-production gateway first, and confirm that a gateway dump reproduces the files. The step is done when a sync from Git produces no unexpected differences and a reviewer has approved the first change set. Your engineers can do this directly, and it is a common area for a partner to set up the pipeline.
Rebuild rate limits, authentication and transformations, then test
Recreate authentication (such as JWT, key auth, OAuth or ACL), rate limiting and transformation behavior using the plugins chosen in the mapping. Test each API against a staging environment with requests that cover success cases, rejected credentials, quota breaches and malformed payloads, and compare the responses with those Apigee returns for the same inputs. Security testers should review the authentication paths and the behavior of any custom plugins. The step is complete when the test results show matching behavior for every production-facing API, and any gaps have an agreed owner and fix.
Run in parallel, then cut over by environment
Route a copy or a small share of traffic through Kong while Apigee stays live, and compare latency, error rates and logs from both paths. Move one environment at a time, starting with non-production, and keep a rollback route to Apigee for each cutover. Confirm that logging, metrics and tracing feed the monitoring stack your operations team uses. The step is done when each environment has run on Kong through an agreed period with no unresolved defects, and the operations owner has signed off.
Decommission Apigee after the final check
Once every environment runs on Kong and the rollback window has closed, disable the Apigee proxies, retain exported bundles and configuration under your records policy, and cancel or reduce the Apigee subscription according to your contract terms. Confirm the contract end date and any data retention obligations with Google before the final shutdown. The step is done when no client references the old Apigee endpoints, the archive is verified, and the decommission is recorded for auditors. Your compliance team usually owns the evidence, and an implementation partner can prepare the runbook.
Apigee alternative questions buyers ask before hiring help
What drives the cost of moving from Apigee to Kong Gateway open source?
The cost is driven by the number of proxies, shared flows and custom policies to map, the number of environments, the portal and analytics you need to rebuild, and how much of the work your own team can absorb. Kong Gateway open source is Apache-2.0 licensed, so the software itself carries no license fee, but you still pay for infrastructure, the people who build and run the gateway, and any outside implementation help. Costs that recur include hosting, monitoring, upgrades and on-call time. Ask any provider for a quote that separates one-time migration work from ongoing operation, and that names which Apigee policies are expected to need custom plugins, since those add build and test effort.
Can our team migrate from Apigee to Kong Gateway without outside help?
Yes, a team with gateway, Kubernetes or Linux operations experience can do it, but the work is more than copying configuration. Your engineers need to map each Apigee proxy flow and policy to Kong services, routes and plugins, decide which settings belong in declarative files managed with decK, and test authentication, rate limiting and transformation behavior against real traffic. The Kong deployment topologies documentation notes that DB-less mode cannot run database-dependent plugins such as cluster-strategy rate limiting and OAuth2, so teams must check those requirements early. Outside help is most useful for the mapping review, cutover planning and hardening.
How long does an Apigee to Kong Gateway migration take?
The duration depends on scope, not on a fixed number. The main variables are how many API proxies and shared flows you run, how many of your policies have direct Kong plugin equivalents, whether you rely on custom Java or JavaScript logic that needs rewriting, how many environments must be cut over, and how much developer portal and analytics work sits alongside the gateway move. Kong's version support policy covers only Kong Gateway Enterprise, so the open-source edition has no published support window that should set your schedule. Ask any provider for a written, fixed-scope plan with milestones, and confirm that it lists each proxy group and environment.
What access and people do we need to provide for the engagement?
You need a named owner for the API inventory, staff who know the business rules behind each proxy, an operations contact for the target environments, and security reviewers for authentication and secrets handling. On the technical side, the work typically requires read access to Apigee proxy bundles and configuration, and an exported copy of your API product and developer setup, which the export guide for Apigee describes. The target environment needs cloud or data center access, container or package installation rights, and a place to store Git-managed declarative configuration. Agree on these access requirements in writing before work starts so that no step waits on an approval.
Can Kong open source replace the Apigee developer portal and API analytics?
Not on its own. The Kong Gateway open-source edition handles routing, authentication, rate limiting and transformation, but the Kong Gateway README does not describe a developer portal or business analytics suite, so you should confirm the exact capabilities of the edition you plan to use. Teams usually cover the portal with a separate tool and rebuild traffic, latency and error reporting with logging and metrics pipelines feeding dashboards. Kong's pricing page places fully self-hosted gateways with a local control plane and data plane in the commercial Kong Gateway Enterprise offering, so review that boundary before you commit to a design.
What happens to Apigee Edge for Private Cloud customers at end of life?
Apigee documentation states that Apigee Edge for Private Cloud 4.53.01, first released on August 26, 2025, reaches end of life on June 30, 2027. After that date Apigee stops providing bug fixes, security updates, hotfixes or patches for that version line. Continuous support also requires running a version within its 18-month full support window. If you run Edge for Private Cloud, plan your choice now between upgrading, moving to Apigee hybrid, or replacing the gateway with a self-run open-source option such as Kong Gateway, and confirm the exact support terms with Apigee before you set a deadline.
Can DeployOpen help us evaluate Apigee against Kong Gateway open source?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it can scope an evaluation as a fixed-scope engagement with written deliverables and timelines agreed before work starts. An evaluation would typically cover a policy-by-policy mapping of your Apigee estate, a test of the features your traffic needs in the open-source edition, and a review of the operating model. DeployOpen does not publish a price list, so a quote follows from that written scope. DeployOpen is not a Kong partner or reseller.
Which parts of Apigee are hardest to move to open-source Kong?
The hardest parts are usually custom policy logic, features tied to Apigee's managed analytics and monetization, and any behavior that depends on a database-backed setting. Kong's DB-less mode reads declarative files and exposes a read-only Admin API, which suits Git-based change control but limits some plugins, so an engineer should check each rate limit, OAuth2 and cluster-wide setting against the deployment topology. Run a pilot on a representative proxy with real client traffic and compare results before moving production. Ask any provider to list the Apigee policies that need custom plugins before agreeing a fixed price.
How DeployOpen helps you evaluate, implement or migrate Kong Gateway
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Apigee vs Kong Gateway open source, we start with a written scope that matches your Apigee footprint to the open-source Kong Gateway features you actually need.
How we scope
- Inventory your Apigee proxies, shared flows, products, developer apps and portal dependencies before any design work starts.
- Confirm which features you need from the open-source edition and which depend on Kong Gateway Enterprise or other tooling.
- Agree deliverables, timelines and fixed scope in writing before work begins, with ongoing support available as a retainer.
How we build
- Design the Kong Gateway topology, choosing DB-less declarative or hybrid control plane and data plane separation for your environment.
- Map authentication, rate limiting and transformation policies to Kong plugins, flagging any Apigee behavior that needs a custom plugin.
- Manage declarative configuration in Git with decK and test routing, authentication and rate limits in a staging environment.
How we hand over
- Document the gateway architecture, configuration repository, upgrade path and runbooks so your own teams can operate it.
- Deliver evidence for compliance readiness, such as access controls, logging and change records, for your auditors to review independently.
- Provide a handover session covering cutover steps, rollback procedures and open items agreed in the written scope.
How we support
- Offer retainers for upgrades, backups, hardening and continuous testing of the gateway after handover.
- Track the Kong Gateway open-source release line and plan upgrades against your own change windows and risk tolerance.
- Keep the post-migration backlog visible, including analytics and developer portal gaps you choose to close with other open-source tools.
