Apigee is a capable gateway, but its per-call and capacity-based pricing, environment and add-on costs, and coupling to Google Cloud make it an expensive place to run APIs that do not need everything it offers. Kong Gateway OSS is a common landing spot: it covers the core gateway job, services, routing, authentication, rate limiting, and transforms, as open source you run yourself. This guide covers how Apigee concepts translate and where the honest gaps are.
How Apigee concepts land in Kong
Apigee organizes work around API proxies that carry a chain of policies. Kong organizes work around services (an upstream), routes (how requests reach that service), and plugins (behavior attached to a service, route, or globally). The mental shift is from an ordered policy flow inside one proxy to a set of plugins bound to a route.
- An Apigee API proxy becomes a Kong service plus one or more routes.
- The proxy’s policy chain becomes plugins on that service or route.
- Apigee environments become separate Kong instances or workspaces at the deployment level, expressed in your declarative config rather than as a first-class product concept.
The upside of this model is that plugins are composable and declarative. The adjustment is that Apigee’s fine-grained, ordered flow with conditional steps does not always have a single plugin equivalent, so some logic moves closer to the upstream service.
Mapping the policies you actually run
Most Apigee proxies lean on a small set of policies. These are the honest mappings:
- Quota → rate-limiting plugin. Per-consumer or per-route request ceilings.
- Spike Arrest → rate limiting with a short window. Smoothing bursts rather than enforcing a daily cap.
- VerifyAPIKey → key-auth plugin, with consumers and credentials modeled in Kong.
- OAuthV2 → oauth2 plugin, or delegation to an external identity provider via JWT validation if you already run one.
- AssignMessage, JSON/XML transforms → request-transformer and response-transformer plugins.
- Access control lists → the acl plugin, paired with an auth plugin.
Where Apigee let you drop in JavaScript, Python, or XSL callouts, there is no drop-in Kong equivalent that preserves the code. You reimplement that logic as a stock plugin where one fits, as a serverless plugin, or by pushing it into the upstream service. Count these callouts early, because they are the part of the migration that takes real engineering time.
The features that do not come in the box
Kong Gateway OSS is the core gateway. Several things Apigee bundled are not included and need an open replacement:
- Developer portal. Apigee’s portal is a product; in Kong OSS you generate a portal from your OpenAPI specs using an external or open portal tool.
- Analytics dashboards. Apigee’s built-in analytics become a Prometheus and Grafana pipeline: expose Kong metrics to Prometheus, build the dashboards you need in Grafana.
- Role-based administration. Fine-grained RBAC over the admin surface is not in OSS; the open approach is to keep configuration in Git and control who can merge, so GitOps becomes your access model.
None of these are blockers, but each is a workstream. Scope them before you commit a date.
Config as declarative YAML
A practical win in this migration is moving from Apigee’s proxy bundles to Kong’s declarative configuration. You define services, routes, plugins, and consumers in YAML and apply it with decK or a GitOps pipeline, or you drive the Admin API directly. Keeping the config in version control gives you review, rollback, and reproducible environments, which also fills the RBAC gap described above by putting change control in your existing Git workflow.
A per-API cutover behind DNS
The safe path is incremental, not a single switch:
- Inventory every proxy, its policy chain, its consumers, and its portal and analytics dependencies.
- Stand up Kong and express the first proxy as a service, routes, and plugins in declarative config.
- Validate in parallel. Point a test hostname at Kong and confirm auth, quotas, and transforms match Apigee’s behavior for that API.
- Shift traffic per API by updating DNS or the load balancer, while Apigee keeps serving everything not yet migrated.
- Decommission each Apigee proxy only after its Kong replacement is proven, and export analytics history before you tear anything down.
Running both gateways at once is the point: the blast radius of any mistake stays contained to a single API.
What to check before you trust it
Before an API is considered migrated, confirm a few things end to end: a call with a valid key or token is authorized and one without is rejected, quota and spike limits trigger at the expected thresholds, request and response transforms produce byte-for-byte the payloads consumers expect, and the new Grafana dashboards show the traffic you just moved. Acceptance is simple to state: consumers see no behavioral change, and you can observe the API in the new stack.
Weighing it up
Apigee to Kong OSS is a sound move when you want the core gateway without premium per-call pricing and Google Cloud coupling, and you accept that the portal, analytics, and admin RBAC become open components you assemble and run. The policy-to-plugin mapping is clean for the common cases and hand-built for the callouts. Model the licensing and capacity savings against the engineering time to rebuild the portal and observability in the calculator above, and treat those figures as illustrative until you validate them against your own proxy inventory.