Which open-source option replaces the Konnect Dev Portal
Konnect bills its developer portal and published APIs as metered items, and the portal is tied to Kong's control plane. Two options can replace it inside your own infrastructure: Gravitee's Portal UI or WSO2 API Manager's Developer Portal, if you want a portal bundled with the gateway and its management console, or Backstage's API catalog, if you want a software catalog that lists APIs alongside services, owners and docs. Choose Gravitee or WSO2 when the portal must publish and manage API subscriptions, and Backstage when the goal is discovery across an engineering organization.
Gravitee API Management is Apache-2.0 licensed and its repository describes a catalog of APIs with documentation in the Portal UI. Several features you may expect from a commercial portal sit in Gravitee's Enterprise Edition, which requires a license, including Dynamic Client Registration and the audit trails of API consumption. WSO2 API Manager is also Apache-2.0 and includes a Developer Portal and Publisher, but WSO2 sells commercial subscriptions for expert support, continuous updates and vulnerability monitoring. Confirm with each vendor which portal functions you need in the open-source core before you assume they are free to run in production.
Backstage is Apache-2.0 with no paid edition from the project itself, and it ships a Software Catalog and TechDocs as core features. It does not issue API keys or handle subscriptions, so pair it with a gateway if consumers must self-register for credentials. Before you choose, list your published APIs, the consumers who need credentials, and whether your identity provider is one of the 19 built-in Backstage authentication providers. Ask the implementation partner to confirm how each option's catalog import handles your existing specs.
Mapping Konnect Dev Portal capabilities to open-source options
This table maps each Konnect Dev Portal capability to the Gravitee Portal UI, the WSO2 Developer Portal and the Backstage API catalog with TechDocs. Read each row for coverage and the items to confirm in your own pilot, since the open-source options differ in how much they bundle and how much you assemble yourself.
| Capability | Gravitee Portal UI | WSO2 Developer Portal | Backstage API catalog with TechDocs |
|---|---|---|---|
| API catalog and documentation | Portal UI includes a catalog of APIs with documentation under Apache-2.0. Confirm which portal features sit in the Community Edition. | Developer Portal is a bundled web interface in Apache-2.0 WSO2 API Manager for browsing published APIs. | Software Catalog and TechDocs are core built-in features. You author entity descriptors and docs-as-code, and the portal is what you build. |
| Self-service application registration | Consumers can subscribe to APIs through the portal. Confirm the subscription and application model in your version. | Subscriptions and applications are handled through the Developer Portal. Confirm approval options in the release you deploy. | Not provided by the catalog. Requires a custom plugin, a Software Template or an external identity and request workflow. |
| API key and credential issuance | Credentials are issued through API subscriptions. Dynamic Client Registration is listed as an Enterprise Edition feature, so confirm what is open source. | Keys and OAuth credentials are issued through the API manager. Confirm how keys are rotated and revoked in your deployment. | No credential issuance. Backstage sign-in covers people, not API consumers, so you need the gateway or identity provider to issue keys. |
| Access approval workflows | Confirm whether approval flows are in the Community Edition or the Enterprise policy and workflow features. | Custom workflows can be added to WSO2 API Manager. Confirm the built-in approval steps before relying on them. | Not built in. Use a Software Template, pull request review or an external ticketing workflow, and confirm ownership in your catalog. |
| Spec publishing (OpenAPI, AsyncAPI, GraphQL) | Documented API catalog supports publishing specifications. Confirm which spec formats the portal renders in your version. | WSO2 API Manager supports REST, GraphQL and AsyncAPI APIs. Confirm rendering for each format in the Developer Portal. | Publishing depends on the API docs plugins you install and the spec files you keep in the catalog. Confirm the formats you need. |
| Branding and custom domains | Portal UI is customizable. Confirm theme and custom domain options in the open-source edition. | Confirm theme customization and domain mapping for the Developer Portal in your release and reverse proxy setup. | Theming is done in the Backstage frontend code. Custom domains are set by your ingress and hosting layer. |
| Analytics for consumers | Enterprise Edition lists audit trails of API consumption and a Cloud Reporter, so consumer analytics may sit behind a license. Confirm the Community reporting. | Traffic and usage analytics are part of the API manager. Confirm which consumer-facing views the portal exposes. | No consumer analytics in the catalog. Usage must come from your gateway, observability stack or a plugin you add. |
Gravitee, WSO2 or Backstage: which portal fits which team
Each option replaces the Konnect Dev Portal in a different way: Gravitee and WSO2 bundle a publisher and portal with the gateway, while Backstage is a catalog and documentation framework you build on. The right choice depends on whether your team wants a finished API portal or a platform it will extend and maintain.
Gravitee Portal UI and API catalog
The Gravitee Portal UI presents a catalog of APIs with documentation, which is the closest one-to-one replacement for the Konnect Dev Portal listing. The Community Edition is self-hosted under Apache-2.0, but several portal-adjacent features sit in the Enterprise Edition, including Dynamic Client Registration and audit trails of API consumption. Check which of your current portal workflows depend on those features before you commit, and ask Gravitee to confirm the Community Edition's exact feature list against your requirements. A fit for teams that want a catalog and console from one vendor's project.
WSO2 Developer Portal with Publisher
WSO2 API Manager provides a Developer Portal for consumers and a Publisher for API owners, both under Apache-2.0 in the repository. Its control plane can also manage third-party gateways, including Kong, which matters if you keep Kong data planes while leaving Konnect. The main cost is the operating model: a commercial subscription adds expert support, continuous updates and vulnerability monitoring, and the repository notes that building the product requires JDK 21. Confirm subscription scope and support terms in writing before you rely on them for production.
Backstage software catalog and TechDocs
Backstage's Software Catalog lists services, APIs and owners, and TechDocs renders documentation kept beside the code. It fits organizations where the portal must cover more than APIs, such as services, infrastructure and templates. The trade-off is that Backstage is a framework, not a finished API portal: your team builds and maintains a React application, selects plugins, and manages the Node.js versions the versioning policy supports. There is no paid edition from the project itself, so the cost is engineering time and hosting, not a license fee.
Backstage authentication and sign-in resolvers
Backstage ships 19 built-in authentication providers, but you must still configure them and decide how identities resolve. The authentication documentation advises sign-in resolvers that map every provider to the same identity and no guest access in production. Without that work, developers may hold different identities across providers, which breaks ownership and credential controls for APIs. Ask your identity team which provider is authoritative, and test sign-in, offboarding and group mapping before go-live.
Keeping Backstage current
The versioning policy ships a main release line monthly and a next release line weekly, and high and critical vulnerabilities are backported to releases from the last six months where feasible. Staying within that window means scheduling regular upgrades of the application, its plugins and the Node.js runtime, which must match the two adjacent even-numbered releases the policy supports. Plan this as recurring work with a named owner, and confirm whether an upgrade retainer or internal rota will cover it.
Choosing between a bundled portal and a framework
Choose Gravitee or WSO2 when the portal must follow the gateway and the API lifecycle closely, and your team wants a supported product rather than a build project. Choose Backstage when developer experience spans many systems and you have engineers who will own a React application. Run a short pilot with your own API specs and two or three consuming teams, then compare how many portal features you still need to build. An illustrative test: if the pilot needs custom plugins for every workflow, the framework cost is higher than it looked on paper.
What running a self-hosted portal requires
Before choosing between Gravitee, WSO2 API Manager and Backstage, confirm what each one asks of your platform team, because the portal is a stack of services rather than a single download. Gravitee API Management ships as a gateway, a management API backend, the Console UI and the Portal UI, and its repository lists three ways to run it: Gravitee Cloud SaaS, a Helm chart for Kubernetes (including AKS, GKE, EKS and OpenShift), and Docker Compose with MongoDB. For a self-hosted Helm deployment, ask Gravitee which chart version matches the 4.12 documentation you plan to follow, and confirm that your MongoDB or other backing store is sized and backed up by your own team. WSO2 API Manager runs on premises from extracted packages, as a managed service, or on Kubernetes through its separate API Platform for Kubernetes. Its 4.7.0 release notes that building the product requires JDK 21, so any internal build pipeline needs that runtime before anyone starts.
Backstage has the most components to own. Its architecture overview recommends PostgreSQL in production, with SQLite intended for development, and each backend plugin gets its own logical database through Knex. Your team therefore needs a PostgreSQL service with backups and a caching choice (Redis, Memcache, Infinispan or in-memory) that it can operate. The versioning policy supports exactly two adjacent even-numbered Node.js releases; as of Backstage 1.46.0 those are Node.js 22 and 24, so confirm the current pair in the policy before you pin your container image. Backstage also ships a main release line monthly and a next line weekly, so plan a recurring upgrade owner. The policy says high and critical vulnerabilities will be backported to releases from the last 6 months where feasible, which means a version older than that window may not receive those fixes.
Be precise about maturity when you present Backstage to a risk committee. The CNCF project page records acceptance on September 8, 2020 and the move to the Incubating level on March 15, 2022. Incubating is a CNCF maturity status, not a security certification or an assurance of fitness for your environment, so verify your own dependency scanning, plugin review and authentication configuration. The Backstage authentication guidance advises sign-in resolvers that map every provider to the same identity and no guest access in production. Costs for all three options are mostly people and infrastructure: the software licenses for Apache-2.0 Backstage and Gravitee Community are zero, but staff time to upgrade, patch and back up recurs. Ask any implementation partner to quote upgrades, backup testing and on-call coverage separately from the initial build.
Keeping Kong gateways while the portal moves
Some teams keep Kong data planes and only need the developer portal to leave Konnect. The options below differ in how far they reach beyond their own gateway, so the choice depends on which gateways you run and where consumers should get credentials.
WSO2 control plane over Kong
WSO2 API Manager's control plane can manage WSO2 gateways and third-party gateways, including Kong, according to WSO2. That lets you keep existing Kong data planes while Publisher and the Developer Portal move on-premises. Confirm with WSO2 which Kong version and configuration model its integration supports, and how Kong routes and plugins map to WSO2 APIs before you commit.
Backstage catalogs any gateway
Backstage's software catalog records APIs as entities with owners, lifecycle and documentation, and does not depend on which gateway serves them. Your Kong routes can be described as API entities alongside their specs, so teams find an API without a gateway-specific portal. Backstage is a catalog and documentation layer, so it does not issue keys or enforce plans on Kong.
Gravitee portal tied to its gateway
Gravitee's Portal UI is part of its own APIM stack, so using it means running Gravitee's gateway for the APIs it publishes. Keeping Kong data planes alongside it means two gateways and two policy sets to operate. Treat Gravitee as a full gateway replacement, and check the Enterprise Edition license for any portal features you need.
Aligning identity across portal and gateway
Backstage ships 19 built-in authentication providers, including generic OIDC, so it can sign in through your existing identity provider. Its documentation advises sign-in resolvers that map every provider to the same identity and no guest access in production. Use the same IdP group model that your Kong consumers and plugins already rely on, so a developer sees one identity across both.
Where consumer credentials are issued
Developer portals usually show consumers how to get keys, but the gateway owns the credential. With Kong, consumers and their keys or OAuth2 credentials live in Kong, so a new portal must either call Kong's Admin API or link to the process that issues them. Decide which system is the source of truth before you migrate consumers, and document the revocation path.
Checks before keeping Kong
Confirm which Kong edition and version your data planes run, and whether any Konnect-only features such as the portal's application registration are in use. Inventory the consumers, plans and specs that the portal currently serves so each one has a new home. Map who owns each API, because Backstage entities and Kong routes need a shared naming scheme.
Moving specs, applications and credentials off Konnect
This sequence moves published API definitions, developer applications and access plans from the Konnect Dev Portal into a self-hosted portal, with each step closed by a check your team can verify before the Konnect portal is retired.
Inventory published APIs and consumers
Your API owners list every API published in the Konnect Dev Portal, its version, its owning team and its consumers, including partner and internal applications. Export or record the portal's visibility settings and any documentation pages that sit beside the specs. Confirm the inventory with each owner, since the Konnect console is the only place some of these details may be held. The step is done when every published API has an owner, a version and a named list of consuming applications.
Export gateway configuration with decK
An engineer runs decK against the Konnect control plane to dump services, routes, consumers and plugins to a declarative file, then stores that file in version control with a dated tag. Ask Kong to confirm the decK version and the Konnect control plane settings your tenant needs, because the export format may not map one to one onto the portal's own model. The step is done when a dump file can be read back and diffed against the live configuration without unexpected changes.
Import OpenAPI and AsyncAPI definitions
A platform engineer loads each OpenAPI and AsyncAPI definition into the chosen portal, either Gravitee APIM, WSO2 API Manager or Backstage's API catalog, and checks that the portal renders endpoints, schemas and examples correctly. Definitions that Konnect stored with extra metadata, such as tags or custom documentation, may need manual mapping. The step is done when each imported API renders in the portal and matches its source file on a sample of endpoints.
Recreate applications and access plans
Product owners rebuild the developer applications and subscription tiers in the new portal, using the inventory from the first step as the source. In Gravitee or WSO2, this means defining plans and subscriptions. In Backstage, access is usually governed by the catalog and the upstream gateway, so the team must confirm where enforcement lives. Map each Konnect consumer to one application record so usage history stays traceable. The step is done when every consumer has an application and each plan's rules have been reviewed by the API owner.
Plan credential re-issuance, not secret copying
Security and platform leads decide that developers receive new API keys or client credentials issued by the new portal rather than copying existing secrets out of Konnect. Plan a window in which old and new credentials both work, and confirm with the vendor how Konnect credentials can be revoked. Record who approves each re-issuance and log the revocation of old keys. The step is done when a written credential plan exists, approved by the security owner, and a test consumer can authenticate with a newly issued key.
Run the new portal in parallel
The team keeps the Konnect portal online while the new portal serves a pilot group of internal and partner developers. Compare the API listings, documentation, sign-up flow and test calls in both portals, and log every gap. Verify that gateway traffic from the pilot group is reaching the self-hosted gateway and that metrics are visible to the owners. The step is done when the pilot group completes its test calls against both documented listings and no open gaps block cutover.
Communicate the cutover to developers
The API product lead announces the new portal URL, the date the Konnect portal will stop accepting new sign-ups, and the steps developers must take to obtain new credentials. The message goes to every consumer on the inventory list, with a named contact for questions. Confirm the date with Kong and with your own change board before publishing it. The step is done when each consumer has acknowledged the notice or has been contacted directly.
Retire the Konnect developer portal
After the cutover date, the team disables new registrations in the Konnect portal, confirms that no active consumers still depend on its listings, and then removes the portal from the Konnect account. Keep the decK dump, the inventory and the credential revocation log in your records for audit purposes. The step is done when the Konnect portal is disabled, the archive is stored under your retention policy, and the new portal is the only documented entry point for developers.
Questions buyers ask before replacing the Konnect Dev Portal
What drives the cost of replacing the Konnect Dev Portal?
The cost depends on which open-source portal you choose, how many portals and published APIs you run, and how much identity and branding work the portal needs. Konnect bills portals and published APIs as metered items, so the replacement cost is mostly one-time setup plus the recurring cost of hosting and upkeep. Cost components to request in a written scope:
- Licensing: Gravitee Community Edition and WSO2 API Manager are Apache-2.0, but Gravitee Enterprise Edition requires a license and WSO2 sells subscriptions with support and continuous updates.
- Identity integration: connecting developer sign-in to your existing identity provider.
- Spec volume, custom branding, and hosting and upkeep, including Backstage's own monthly and weekly release cadence.
Can our internal team replace the Konnect Dev Portal without a partner?
Yes, many teams can, provided they have engineers who already run APIs on Kubernetes or Docker and can own a web portal after go-live. The harder parts are usually identity configuration, moving specs and applications cleanly, and running upgrades on a set cadence. Ask whether your team can cover these tasks:
- Deploying and upgrading the portal platform, including JDK 21 for WSO2 API Manager 4.7.0 builds.
- Configuring sign-in resolvers so every identity provider maps to one user identity.
- Writing the runbooks, backup routines and evidence that auditors will ask for.
DeployOpen plans, implements, integrates and documents these pieces under a fixed-scope written agreement if you prefer to hand them over.
How long does a Dev Portal migration take?
Duration depends mainly on the number of portals, the number of published APIs and the consumer onboarding plan, and no timeline is fixed in this page. A single portal with a small API set is far simpler than several business-unit portals with separate sign-in rules. Ask for a written schedule that breaks the work into phases: discovery, platform build, spec and application import, pilot consumers, and cutover. Also ask how onboarding of each consumer group is sequenced, because that step often sets the pace.
What does the migration need from our teams?
The migration needs three groups to commit time early. API owners must confirm which specs are current, which versions are retired and who approves consumer access. The identity team must provide the provider settings, group mapping and decisions on guest access, which the Backstage authentication guidance advises against in production. The platform team must provide the cluster or servers, databases, backup targets and change windows. Agree these responsibilities in writing before work starts so delays are traceable.
Can we move API keys and credentials out of Konnect, or must consumers reissue them?
Konnect keeps credentials inside its control plane, so exported configuration alone usually does not carry consumer secrets across. Plan on reissuing or rotating credentials for each consumer application, and treat that as a coordinated event rather than a silent copy. Confirm the following with Kong and your target portal before deciding:
- Whether any credential material can be exported from your Konnect organization.
- How the target gateway stores consumer keys and whether it can accept hashed or imported values.
- How consumers are notified and given a window to switch, so no production calls fail unexpectedly.
What do Enterprise licenses or WSO2 subscriptions add to the cost?
They add recurring fees in exchange for capabilities that the open-source editions do not provide. Gravitee states that its Enterprise Edition requires a license and lists features such as audit trails of API consumption and activity, data masking, Dynamic Client Registration and an enterprise policy pack. WSO2 sells on-prem subscriptions that provide expert support, continuous product updates, vulnerability monitoring and access to a licensed distribution for commercial use. Request a line-item quote showing which features you need, the license term and what happens to support if you change plans.
What should we verify about security and compliance before cutover?
Verify that the new portal enforces the same access rules, logs developer activity and keeps credentials under your control before any consumer moves. Backstage's authentication documentation recommends one identity per user across providers and no guest access in production. Ask DeployOpen or your team to prepare the controls, configuration evidence and test results that your auditors will review. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
What a fixed-scope portal migration covers
A portal replacement starts with a written scope agreed before any work begins. DeployOpen does not publish a price list, and a quote follows from that scope. For a Konnect Dev Portal move, the scope should name the portal platform (Gravitee's Portal UI, WSO2 API Manager's Developer Portal, or a Backstage API catalog), the environments it runs in, and the list of APIs and applications to be published. Deployment happens in your own cloud account, data center or air-gapped network, so the scope should also state which infrastructure, databases and certificates you provide and which DeployOpen builds.
The remaining scope items are the ones that most often change the effort. Identity integration covers how developers sign in and how portal accounts map to your corporate directory, including the sign-in resolver choices that Backstage's authentication documentation recommends so each provider resolves to the same identity. Spec migration covers exporting OpenAPI and AsyncAPI documents from Konnect, checking them for broken references, and deciding which versions stay visible. Application and credential migration needs a separate decision: consumer keys cannot be copied silently, so the scope should say whether developers re-register, rotate keys, or receive a cutover window. Ask the vendor to confirm which of these the target platform imports directly.
Testing and documentation close the scope. Testing should cover sign-in, subscription approval, key issuance, try-it requests against the gateway, and the portal's behavior under your access rules. Documentation should cover runbooks, the upgrade procedure and the evidence your assessors may ask for. Ongoing upgrades, patching and continuous testing are available as optional retainers, which you can price separately from the one-time build. Ask for the scope, deliverables and timeline in writing, and confirm which costs recur, such as platform licenses for Gravitee Enterprise or WSO2 subscriptions, before you accept the quote.
How DeployOpen delivers a developer portal replacement
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Konnect Dev Portal replacement, we start from your published APIs, consumer onboarding flows and identity setup, then build and document the portal you will run.
How we scope
- Inventory the APIs, specs, applications and credentials currently published through the Konnect Dev Portal.
- Confirm which portal fits your needs: Gravitee's Portal UI, WSO2 API Manager's Developer Portal, or a Backstage API catalog.
- Agree the written scope, deliverables and timeline before any work starts, since most engagements are fixed-scope.
How we build
- Deploy the chosen platform in your environment, using the Docker Compose, Helm or Kubernetes options your team already runs.
- Export and import specs, then test that each API page, try-it flow and access plan behaves as your consumers expect.
- Configure sign-in with your identity provider and test security controls, including access rules and API consumer authentication.
How we hand over
- Provide documentation for the portal's configuration, onboarding steps, backup procedures and upgrade path.
- Walk your platform and API teams through daily administration, publishing new APIs and managing consumer credentials.
- Deliver a migration record listing what moved, what was reissued and what your consumers must change.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Confirm with us the scope of any post-handover retainer in writing, including upgrade and testing frequency.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
