Open-source alternative to the Apigee developer portal: the short answer
If your Apigee developer portal is tied to Google's hosting, or your team is carrying the burden of running a Drupal-based portal, the short answer is that WSO2 API Manager and Gravitee both ship a self-hosted developer portal that covers API documentation, application registration and subscriptions. Backstage can host the API catalog and documentation side of a portal well, but it does not issue API keys, so you would pair it with a gateway or management product that handles credentials. Both WSO2 API Manager and Gravitee API Management are licensed under Apache-2.0, and Backstage is also Apache-2.0 with no paid edition from the project itself.
Read the licenses closely before you commit. Gravitee's Enterprise Edition requires a license, and its documentation lists features that many portal teams expect, including Dynamic Client Registration and an enterprise policy pack, as part of that paid tier. WSO2 sells commercial subscriptions for API Manager that add expert support, continuous updates, vulnerability monitoring and a licensed distribution for commercial use. Confirm with each vendor which portal workflows (self-service sign-up, approval of subscriptions, key rotation and developer onboarding) fall inside the open-source distribution and which need a paid license or a custom build.
The practical next step is a short inventory of what your current Apigee portal does for developers. List the API documentation sources, the app registration and approval steps, the key lifecycle your partners rely on, and any custom Drupal modules you maintain. Use that list to test each candidate in a non-production environment, because a catalog that displays docs well may still lack the key and approval flows your developers depend on.
Which open-source option covers each portal capability
This table maps the core jobs of an Apigee developer portal to WSO2 API Manager, Gravitee APIM and Backstage, marking where each option is native, partial or missing. Read the check marks as built-in features in the open-source edition only, and confirm every Enterprise-only item with the vendor before you commit to a design.
| Portal capability | WSO2 API Manager | Gravitee APIM | Backstage |
|---|---|---|---|
| API documentation and catalog | Developer Portal lists published APIs with documentation, and the Publisher manages their lifecycle | Portal UI provides a catalog of APIs with documentation, served from the management backend | Software Catalog and TechDocs render API docs from repository sources, but it is not a gateway-backed API catalog by default |
| App registration and self-service | Developers register applications in the Developer Portal and subscribe to APIs | Portal UI supports application creation and subscriptions; confirm the Community Edition scope for your version | Not built in; teams would build a registration flow with plugins or external identity and templates |
| API key and credential issuance | Keys and OAuth clients are issued through the gateway and key manager in the control plane | Keys and subscriptions are issued by the gateway; Dynamic Client Registration is listed as an Enterprise Edition feature | Not a key manager and not gateway-aware; keys must come from the gateway or identity provider |
| Approval and subscription workflows | Subscription workflows can be extended with custom workflows, according to the repository | Plan-based subscriptions with approval steps; confirm which approval modes are Community features | Not built in; approval would be a custom Software Template or external ticketing step |
| Branding and customization | Developer Portal theming is customizable, and the platform can be extended with custom components | Portal UI can be themed and extended; confirm theming limits in the open-source edition | Fully customizable frontend with plugins and a themed app shell, which requires React and TypeScript work |
| Developer analytics and usage | Traffic and usage analytics depend on the analytics setup you run; confirm the scope for developers | Audit trails of API consumption are listed as Enterprise Edition features | Not a usage analytics tool; plugins can surface metrics from your monitoring stack |
| Hosting and identity | Self-hosted on premises, on Kubernetes, or as a managed cloud service, with the commercial subscription available | Self-hosted through Helm on Kubernetes or Docker Compose with MongoDB; SaaS and hybrid options are Enterprise | Self-hosted with PostgreSQL in production and 19 built-in authentication providers; avoid guest access in production |
Which portal fits which team: WSO2, Gravitee or Backstage
Apigee's portal covers API docs, app registration, keys and approval flows. WSO2 API Manager and Gravitee each bundle a publisher or console with a developer portal, while Backstage is a catalog and docs portal that needs API management added alongside it. The right choice depends on whether you need a full API product or a developer-facing catalog.
WSO2 API Manager for full API products
WSO2 API Manager is Apache-2.0 licensed and includes a Publisher, a Developer Portal, a gateway and a traffic manager for throttling. It fits teams that want to publish APIs, manage subscriptions and key issuance, and apply quotas in one self-hosted product, and that already plan for Kubernetes or on-premises deployment. The trade-off is that the open-source distribution is the starting point, and WSO2 sells a commercial subscription for expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Confirm which of these your compliance program requires before you choose a support model.
Gravitee for a gateway and portal in one
Gravitee API Management is Apache-2.0 licensed and provides a gateway, a management API backend, a Console UI for administrators and a Portal UI with an API catalog and documentation. It suits teams that want Apigee-style plans and subscriptions in a single product, installed through a Helm chart on Kubernetes or Docker Compose with MongoDB. The main trade-off is licensing: some features, including Dynamic Client Registration and audit trails of API consumption, belong to the Enterprise Edition, so map each Apigee feature you rely on against the Community feature set before migration.
Backstage for a developer catalog and docs
Backstage is an Apache-2.0 framework from the CNCF, currently at Incubating maturity, with a Software Catalog, Software Templates and TechDocs as core features. It fits organizations that need an internal catalog of APIs and services, search and onboarding docs, but do not need a gateway or key issuance from the same tool. Backstage has no paid edition from the project itself, so the cost is the engineering effort to build and run it. Plan for PostgreSQL in production, a sign-in resolver so each provider maps to one identity, and no guest access in production. You will still need a separate gateway for key and approval flows.
Running a new portal next to Apigee during the transition
When the gateways stay on Apigee, the new portal is a front end for an existing control plane. Apigee still issues the keys, enforces the products and quotas, and records traffic, so the new portal must read from and write to Apigee rather than replace it. This situation suits teams that want a better developer experience before they decide on a gateway change. The main risk is duplicated developer records, because the new portal's sign-up can create accounts that Apigee does not know about.
- Single source for developers: Choose one system as the owner of developer accounts, and have the new portal create or look up developers through the Apigee management API instead of its own user table.
- Key lifecycle through Apigee: Keep key generation, rotation and revocation in Apigee so that quotas and product scopes stay enforced where traffic is checked.
- Listing sync: Publish API products from Apigee into the new portal's catalog on a schedule or on change, and treat the Apigee product definition as authoritative.
- Approval flows: Decide whether approval happens in the portal or in Apigee, and make sure a pending request cannot yield a live key in one system and a pending state in the other.
- Audit trail: Keep a record of which system approved each key so that access reviews can answer the question from either side.
Before cutover, confirm with your Apigee administrator which management API operations and IAM roles the new portal's service account will need, and test that a revoked key stops working through the gateway.
When gateways move first, the old Apigee portal stays online to serve existing developers while traffic shifts to the new gateway. Developers then hold keys issued by Apigee that must still be accepted by the new gateway, or they must be re-issued keys on a schedule you control. The old portal becomes a read-only reference during this period. This approach keeps the developer-facing surface stable but leaves two portals and two key systems to keep aligned until the old one is retired.
- Key import or reissue: Decide whether existing consumer keys are imported into the new gateway or whether developers receive new credentials, and communicate that choice before any traffic moves.
- Read-only old portal: Freeze publishing on the Apigee portal once the new catalog is live, so documentation edits do not diverge.
- Redirects: Map old portal URLs to the matching pages on the new portal, so bookmarks and links in partner documentation keep working.
- Dual running window: Keep both gateways able to serve the same APIs for a period you set in writing, and route a small set of consumers first.
- Rollback path: Keep the Apigee route and keys live until error rates and authentication failures on the new gateway are within your agreed thresholds.
Confirm with your platform team how long the old portal must remain reachable for audit evidence, and what a rollback looks like for each consumer group.
Backstage can sit in front of either gateway as a catalog and documentation entry point, with the software catalog listing APIs, owners and docs from Apigee or from the new gateway. It does not issue keys or enforce quotas, so it works alongside whichever gateway holds those functions. Use it when the goal is one place for internal engineers to find APIs, while the gateway team keeps control of access. Backstage ships 19 built-in authentication providers, which can connect it to the same identity source used elsewhere.
- Catalog entries as references: Register each API as a catalog entity that links to its Apigee or gateway definition, and record the owner team so listings do not go stale.
- Identity from one provider: Configure sign-in resolvers so every provider resolves to the same identity, as the authentication documentation advises, so an engineer does not appear as two people.
- No guest access in production: Disable guest sign-in in production, because catalog content and API metadata usually should not be open to anonymous visitors.
- Key requests outside Backstage: Link to the gateway's own sign-up or approval flow from the catalog entry rather than creating a second approval process.
- Sync checks: Schedule a comparison between catalog entries and the gateway's list of published APIs, and flag entries that exist in only one system.
Before committing, confirm which Backstage authentication provider your identity system supports and how the sign-in resolver maps group membership to catalog ownership.
Moving developers, apps and API documentation off the Apigee portal
This sequence moves API product documentation, developer accounts, registered apps and their credentials from Apigee's portal to a self-hosted portal without breaking consumers that are already calling your APIs. Each step ends with a check that the previous one is complete.
Confirm what your Apigee portal exposes
Before exporting anything, the API owner and the portal administrator confirm which portal your organization runs: the integrated portal or a Drupal-based portal. Apigee's publishing overview is the reference for current portal features, and the reader should confirm what their Apigee version and portal type expose, including whether self-service app registration, key management and API documentation pages are enabled. Record the result in a short inventory. The step is done when the team agrees on a list of features the new portal must replace.
Export API product and documentation content
The portal team exports API product definitions, descriptions, OpenAPI specifications, guides, changelogs and any custom pages from the Apigee portal, and stores them in version control. Product names, visibility settings and access levels are captured alongside the content, because they determine which developers can see each product in the new portal. Assets that only exist as portal page content, such as tutorials built in the CMS, need to be copied by hand. The step is done when every published product has a matching source file and a reviewer has confirmed that nothing is missing.
Inventory registered apps and their keys
The platform team lists every developer, app and API key registered in Apigee, along with each app's associated products, scopes and quota settings. This list is pulled through the Apigee management API or the administrative tooling your organization already uses, and it should be reconciled with the gateway's own view of active keys. Apps that have not called an API recently are flagged so the owners can decide whether to migrate them. The step is done when the inventory total matches the Apigee admin view and each app has a named owner.
Decide which keys are re-issued and which are rotated
The security lead decides, per app, whether the existing credential is carried over (rotated in place on the new gateway) or whether the developer receives a new key. Keys that were shared widely, stored in public repositories or issued to former partners are normally re-issued, while internal apps with secure secret storage can often keep a rotated credential under a planned window. This decision belongs to the security and API owners, not the developer portal project, and it must be written down per product. The step is done when every app in the inventory has a recorded decision and a named notification owner.
Rebuild approval flows and access rules
The API owners recreate the request, review and approval steps that Apigee used for product access, such as manual approval for partner tiers or automatic approval for public products. In WSO2 API Manager, Gravitee and Backstage the mechanism differs: WSO2 supports custom workflows, Gravitee has its own subscription and plan model, and Backstage relies on catalog entries and your identity provider rather than a built-in API key workflow, so each flow is mapped to the chosen product. Test each path with a non-production developer account. The step is done when every approval path has been exercised end to end and the outcome matches the Apigee behavior.
Migrate developer accounts and identity
The identity team decides whether developer accounts move as data or are federated from an existing identity provider. Passwords stored in the Apigee portal are not normally exported in usable form, so most teams either trigger a password reset flow or sign developers in through OIDC or another supported provider. Backstage ships 19 built-in authentication providers, and its documentation advises configuring sign-in resolvers so each provider maps to the same identity and guest access is not offered in production. Confirm the mechanism with the vendor you choose. The step is done when a test developer can sign in and see only the products their account is entitled to.
Run both portals in parallel
The portal team publishes the new portal alongside Apigee, points new registrations at the new portal, and asks existing developers to re-validate their apps and keys during an agreed period. Support staff log which developers have moved, which requests failed and which documentation pages got questions, and they fix gaps before anything is retired. Traffic from old keys continues to route through the gateway during this period. The step is done when the open support issues on the parallel portal are closed and every app in the inventory is either migrated or has an agreed exception.
Retire the Apigee portal and archive records
Once the parallel period ends and the migration inventory is complete, the team disables new registrations on the Apigee portal, removes its public access, and archives the exported content, the approval records and the access logs under the organization's retention policy. The archive is kept so that auditors and support staff can answer questions about past key issuance. Confirm retention requirements with your compliance lead before deletion. The step is done when the Apigee portal no longer accepts traffic and the archive has been reviewed and signed off.
How sign-in and identity shape the portal design
Decide how developers and approvers sign in before you choose a portal, because the identity model determines who can register an app, who approves a key and how an audit trail reads later. In Apigee, these roles sit in Google-managed or organization-level identity settings. In a self-hosted portal, you own them. Backstage ships 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta, Auth0, OneLogin, Bitbucket, Cloudflare Access, AWS ALB, Google IAP and generic OIDC, so the sign-in method is rarely the hard part. The harder part is mapping each identity to one person, team and role.
The Backstage authentication documentation advises configuring sign-in resolvers so every provider resolves to the same identity. This matters when a partner signs in through a social provider and an internal team through corporate SSO. Without a resolver rule, the same person can appear as two catalog users, and approval history splits across them. The same guidance advises against guest access in production, so a portal that lets anonymous users register applications or request keys will fail an access review. Ask your identity team which claim (for example, a verified email or a stable subject identifier) will be the join key, and test it with a partner account and an internal account before any build work starts.
Write down the approval model before the portal is configured. List who may request an API key, who approves access to each API product, who may revoke keys and who receives notifications. Then confirm with your identity provider whether group membership or role claims can carry those decisions, how quickly group changes propagate, and whether offboarding removes portal access automatically. Those answers determine whether approvals run through the portal's own workflows or through your existing ticketing process, and they will shape the portal evaluation more than any feature list.
Questions buyers ask before replacing the Apigee developer portal
What drives the cost of replacing the Apigee developer portal?
Portal scope, the number of APIs and developers, identity integration and customization drive most of the cost. A portal that only publishes reference documentation is a much smaller job than one that also handles app registration, key issuance, approval workflows and billing tiers. The cost splits into one-time work (design, configuration, identity wiring, content migration and testing) and recurring work (upgrades, security patching, hosting and support). Ask any quote to itemize each of these components, state who pays for each one, and separate the platform licence from the implementation effort. Apigee's own portal options include an integrated portal and a Drupal-based portal, so ask which of these features your current setup actually uses before estimating scope.
Can our own team migrate the developer portal without a partner?
Yes, a team with API management and identity experience can do it, but the work is usually larger than the portal itself. Gateways, developer portals and identity providers each have their own configuration model, and the portal depends on accurate API definitions, plan rules and approval logic exported from Apigee. Teams that already run Kubernetes, manage their own identity provider and have written API specifications tend to move fastest. Teams without that experience should weigh the time spent learning the platform against the cost of an implementation partner. DeployOpen plans and implements self-hosted platforms inside your own infrastructure, so you can ask for a written scope that covers only the parts you do not want to build in-house.
How long will the portal replacement take?
The duration depends on scope, so request a written plan with milestones before committing to a date. No supplied fact gives a general timeline for this work, and any figure presented without a written scope would not reflect your environment. The plan should list the APIs to publish, the number of developer accounts to migrate or re-register, the identity integration steps, the approval flows to rebuild, and the test and cutover criteria. Ask for each milestone to name its deliverable and its acceptance check. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements follow that fixed-scope model.
What do we need to provide during the portal migration?
The work needs named people from three groups. API owners must confirm which APIs are public, supply up-to-date specifications and approve documentation. Identity administrators must provide the directory, single sign-on settings and group mappings that control who can register apps and request keys. Approvers, such as security or product owners, must define who signs off on access requests and which requests need manual review. Without these people available on a schedule, the portal stalls even when the technical work is ready. Ask the implementation partner to list these roles in the scope document with expected time commitments, so your staff can plan for them.
Can Backstage replace an API developer portal on its own?
Backstage can serve as a catalog and documentation portal, but it does not provide the full API management portal experience by itself. Its Software Catalog, Software Templates and TechDocs cover discovery and documentation, and it ships with 19 built-in authentication providers. However, app registration, API key issuance, plan-based subscriptions and approval flows are not built in, so they would need to be built as plugins or connected to a gateway that handles them. Confirm which of these features your developers need before choosing Backstage alone. If your gateway already offers a developer portal, it may be simpler to keep that portal and use Backstage for the broader software catalog.
When is a commercial subscription or Enterprise license worth adding?
Add a commercial license when you need a feature that the open-source edition does not include, or when you need vendor support with a defined response process. For WSO2 API Manager, the commercial subscriptions provide expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. For Gravitee, some features require an Enterprise license, including Dynamic Client Registration, audit trails and the enterprise policy pack. Check which of these features are on your requirements list before purchasing. Ask each vendor for the exact feature list in writing and confirm whether the license covers the portal, the gateway or both.
Cost components of a self-hosted developer portal
The one-time costs of a self-hosted portal are mostly labor: scoping which API products, plans and approval rules the portal must reproduce, migrating API documentation and OpenAPI or AsyncAPI definitions, integrating the portal with your identity provider for developer and administrator sign-in, customizing the look and the onboarding flows, and testing key issuance, approvals and quota behavior end to end. Who is paid for what depends on the path. With WSO2 API Manager or Gravitee, the portal is part of the product, so most effort goes into configuration and content. With Backstage, the API catalog is one plugin set inside a framework you build, so frontend and backend development, plugin selection and template design carry more of the bill. Ask any implementation partner to price these items separately, and ask which of them assume your existing identity provider rather than a new one.
The recurring costs are hosting, the database, upgrades, support and staff time. Backstage requires PostgreSQL in production and runs each backend plugin on its own logical database, so database sizing and backups belong in the run budget. Backstage's versioning policy ships a main release line monthly and a next line weekly, and high and critical vulnerabilities are backported to releases from the last 6 months where feasible, so plan staff time for regular upgrades. Node.js support also follows the release policy, which currently names Node.js 22 and 24 as the supported pair. For WSO2 and Gravitee, ask whether your chosen edition includes the portal and advanced features, and which support subscription or Enterprise license covers the portal, its audit trails and its authentication options. Quotes should separate license, support, hosting and internal staff, and state what each one covers and how often it renews.
How DeployOpen scopes and delivers a developer portal replacement
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Apigee developer portal replacement, that means agreeing in writing what the portal must keep, then building and handing over the portal in your environment.
How we scope
- Inventory the Apigee portal's API docs, app registration, key issuance and approval flows before choosing a platform
- Agree in writing which portal capabilities move, which are retired and which need a new process
- Confirm identity provider, developer audience and data residency rules, since sign-in and access shape the portal design
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
How we build
- Stand up the chosen portal (WSO2 API Manager, Gravitee or Backstage) in your own infrastructure with the agreed database and caching setup
- Import API definitions and documentation, then configure sign-in resolvers so each identity maps to one developer account
- Rebuild approval workflows and key or subscription handling, and test them against the scope before go-live
- Run security testing on the portal and its APIs before developers are invited
How we hand over
- Document the deployment, configuration, backup and upgrade steps so your team can operate the portal
- Provide a written record of which Apigee portal features were moved, changed or dropped
- Walk your platform and developer relations staff through publishing new APIs and approving developer apps
- Deliver the agreed compliance evidence for your assessors, which independent auditors then review
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Track upstream releases of the chosen portal and plan upgrades with your change process
- Confirm with the vendor or project which security fixes and release lines apply to your version
- Request a quote from the written scope, since DeployOpen does not publish a price list
