Which open-source Kong Konnect alternative fits your renewal, residency or lock-in concern
Kong Gateway OSS and Apache APISIX cover the data plane when you self-host it, so the traffic path, policies and plugins can run inside your own clusters. Neither one gives you a hosted management UI or a developer portal out of the box, so if your teams rely on Konnect's console, you will need a management layer such as Gravitee API Management or WSO2 API Manager. Which one you pick depends on whether your concern is renewal cost, data residency or lock-in, because each pushes the decision in a different direction.
Konnect is a SaaS platform with a Kong-managed control plane, and that control plane is where configuration, analytics and administration live. Kong's documentation describes several places to run the data plane: self-hosted nodes, serverless gateways, or Dedicated Cloud Gateways that Kong fully manages on AWS, Azure or GCP. If your residency rules require that configuration metadata and operational data stay in your own environment, the Konnect control plane is the first thing to check against those rules. Ask your legal and compliance leads which data classes the control plane touches, and confirm with Kong exactly what is stored and where before you assume a self-hosted data plane solves the problem.
For lock-in, the practical question is how much of your estate depends on Konnect-specific constructs. Export your declarative configuration, list the plugins you use, and mark which ones are available in Kong Gateway OSS and which depend on enterprise or Konnect features. The Kong Gateway repository is licensed under Apache-2.0, so the core engine is open, but the management experience is not. Plan the replacement around the features your teams use daily, and test the control plane choice against your renewal timeline, not the other way around.
Which open-source gateway and control plane options replace Konnect
Konnect combines a managed control plane with data plane nodes you can run yourself. Replacing it means choosing a gateway that runs without Kong's SaaS control plane, then deciding who provides configuration management, the admin UI and the developer portal. The options below differ mainly in license boundaries and in how much management tooling ships under the open-source license.
Kong Gateway OSS
Kong Gateway is licensed under Apache-2.0 and can be installed with Docker, on Kubernetes or from packages for Ubuntu, RHEL, Debian and Amazon Linux. The supplied release for this comparison is 3.9.1, the second OSS release in the 3.9 series. It is the most direct path for teams keeping existing Kong configuration and plugins, but you should confirm which plugins and admin features in your current setup are included in the OSS edition, since Konnect-only management features will not carry over.
Apache APISIX with etcd
APISIX is licensed under Apache-2.0 and is built on NGINX and etcd. Routes and plugins are stored in etcd, so changes apply without restarting the gateway. This suits teams that manage configuration through automation and Kubernetes ingress. The trade-off is that you will operate an etcd cluster alongside the gateway, and you will need to confirm whether its dashboard and portal features meet your governance needs or require a separate tool.
Tyk Gateway with license boundaries
Tyk Gateway is licensed under MPL-2.0, except code in the ee folder, which is commercial. The dashboard GUI, management control plane and developer portal are sold as Tyk Self-Managed or Tyk Cloud under a commercial license. Tyk fits teams that only need the gateway and will build their own management layer. Check the license of every component you deploy, because a feature you assume is open source may sit in the ee folder.
Gravitee as control plane and portal
Gravitee API Management is licensed under Apache-2.0 and includes a gateway, management backend, console UI and developer portal. It is the closest open-source match to Konnect's management and portal experience. Some features require a Gravitee Enterprise License, so list the capabilities your governance, analytics or access workflows depend on and confirm each one against the license terms before you commit.
WSO2 API Manager for full lifecycle
WSO2 API Manager is licensed under Apache-2.0 and includes a gateway, developer portal, publisher, control plane and traffic manager. It suits organizations that want API lifecycle tooling and subscription workflows in one product. WSO2 also sells on-prem subscriptions with support, continuous updates and a licensed distribution for commercial use. Ask whether you need that support contract, and what it would cost compared with staffing your own patching and upgrade cycle.
How Konnect capabilities map to open-source components
This table compares each main Konnect capability with the open-source option that covers it, and notes where the supplied documentation does not confirm parity. Read the gap column first, since it shows what you must build, buy or verify before cutting over from a SaaS control plane. Kong Gateway OSS covers the data plane and declarative configuration, but the management UI, portal and analytics need a separate decision.
| Konnect capability | Open-source option | Coverage and gaps |
|---|---|---|
| Gateway data plane | Kong Gateway OSS (Apache-2.0), or Apache APISIX (Apache-2.0) | Kong Gateway OSS runs in Docker, Kubernetes or Linux packages. Konnect-managed data plane modes (serverless and Dedicated Cloud Gateways) have no open-source equivalent, so you run and scale nodes yourself. |
| Declarative configuration | Kong declarative config files (decK-style workflows), or APISIX YAML and etcd-backed config | Confirm whether your Konnect exports (entities, routes, services, plugins) import cleanly into a self-managed Kong DB-less setup. Plan version pinning and a review step for config drift. |
| Plugins and policies | Kong Gateway OSS bundled plugins, or APISIX plugins | Enterprise-only Kong plugins and Konnect-managed plugin features are not covered by OSS. Inventory every plugin in use and check each one against the OSS edition before migration. |
| Konnect control plane UI | Kong Manager OSS (confirm edition), or Gravitee or WSO2 API Manager consoles | The supplied facts do not confirm the feature set of Kong Manager OSS. Verify the UI scope with Kong before relying on it. Gravitee and WSO2 provide their own publisher and management consoles. |
| Developer portal | Gravitee developer portal or WSO2 API Manager developer portal | Kong Gateway OSS does not provide a portal in the supplied facts. Gravitee and WSO2 include portals, but some Gravitee features require an Enterprise License. Confirm which portal features your consumers need. |
| Analytics and observability | Prometheus and Grafana with Kong or APISIX metrics plugins, or WSO2 and Gravitee analytics | Konnect analytics dashboards have no direct open-source twin. Confirm which metrics, retention and per-consumer reporting you need, then build or verify them with the vendor. |
| RBAC and multi-workspace management | Gravitee or WSO2 role model; Kong workspaces in Enterprise only | Confirm whether Kong OSS supports the multi-workspace isolation you use in Konnect. Map teams to roles in your identity provider and verify separation in your test environment. |
| Kubernetes ingress | Kong Ingress Controller or Apache APISIX Ingress Controller | Both run in Kubernetes. Confirm the controller version, CRD compatibility and upgrade path against your current Konnect-connected deployment. |
How to keep existing Kong configuration and plugins
Start with an audit, not a copy. Kong Gateway OSS runs the same core gateway that serves as the data plane under Konnect, so most proxy behavior, declarative configuration and common plugins should carry over. The risk sits in the edges: anything configured through Konnect's control plane, such as RBAC roles, workspaces, analytics dashboards, portal settings and some plugins that appear only in the Enterprise tier. List every plugin attached to a service, route or consumer, then mark each one as OSS, Enterprise or unknown. Confirm the tier of each plugin against Kong's current documentation and your Konnect subscription, because plugin packaging changes between releases and this page does not assert parity for any specific plugin.
Export and test before you cut over. Pull the current configuration from Konnect or your existing control plane in declarative form, then review the exported services, routes, upstreams, consumers and plugin entries for references to Konnect-only features or Enterprise-only plugin settings. Load that file into a non-production Kong Gateway OSS instance (the 3.9.1 release is a reasonable baseline to confirm against) and run your full regression suite, including authentication flows, rate limits, header transformations and error responses. Keep secrets out of the exported file and move them into your own secret store before committing it to version control. Plan a rollback path that keeps the Konnect data plane available until the OSS deployment has passed a full cycle of production-like traffic.
If you move to Apache APISIX or Tyk instead, treat plugin and policy translation as a rewrite. APISIX stores routes and plugins in etcd and applies changes without restarts, so you map Kong plugin configuration to APISIX plugin names and schemas one by one, then verify behavior with the same test suite. Tyk expresses similar controls through its own API definitions and policies, and its dashboard and developer portal sit behind a commercial license, so confirm which components you need before choosing it. For either target, ask the vendor or community for a written mapping of each plugin you use, and do not assume an equivalent exists until your tests show identical responses for the same requests.
Which Kong Konnect alternative fits each situation
When the main driver is keeping API traffic and configuration inside a specific country, region or data center, the question is where the control plane sits, not only where the gateway runs. Konnect's control plane is Kong-managed SaaS, while its data plane nodes can be self-hosted, so teams with strict residency rules often keep the gateway nodes in-region and confirm exactly what metadata leaves the environment. Apache APISIX is a strong fit here because it stores configuration in etcd, which you operate inside your own network, and it has no required external control plane.
- Best-fit option: Apache APISIX with its own etcd cluster, or Kong Gateway OSS with a self-hosted control plane.
- Control plane needed: Your own etcd deployment (APISIX) or Kong's database-backed mode and admin API (Kong OSS).
- Telemetry and logs: Confirm which logs, metrics and traces are exported and to which endpoints.
- Backups: Confirm where etcd or the Kong database snapshots are stored and who can restore them.
- Decision point: Check whether your residency obligation covers configuration metadata, not only request payloads.
Before you choose, ask your legal and privacy team which data classes count as in scope, then confirm each gateway component's network dependencies with the vendor or project documentation.
Cost-driven moves usually separate the subscription fee from the operating effort. Moving to open-source software removes the license line item but adds the engineering time to run upgrades, monitoring, high availability and on-call support. The total cost depends on how many gateways you run, how many teams publish APIs, and whether you already have platform engineers who can absorb the work. Gravitee and WSO2 API Manager bring a management UI and developer portal in their open-source editions, which reduces the custom tooling you would otherwise build, though some features sit behind commercial licenses.
- Best-fit option: Kong Gateway OSS for lean gateway-only workloads, or Gravitee or WSO2 API Manager when you need a portal and publisher workflow.
- Control plane needed: Kong's own admin API with declarative configuration, or the bundled management backend of Gravitee or WSO2.
- Recurring costs: Infrastructure, upgrades, security patching and staff time, which are not one-time.
- Hidden costs: Commercial add-ons you may still need, such as enterprise features or vendor support subscriptions.
- Decision point: Ask each candidate for a written list of features that require a paid license, then compare that list with your actual requirements.
Request a quote from DeployOpen based on a written scope that lists gateways, environments, plugins and portal needs, so the comparison reflects your workload rather than a generic estimate.
Teams with many custom or bundled Kong plugins face the most direct migration cost. Kong Gateway OSS is the natural continuation because it is Apache-2.0 licensed and uses the same configuration model, so existing declarative files and most plugins can stay in place. The main gap is the management layer: features that Konnect provides through its hosted UI, such as analytics dashboards and team-level access, will need an open-source control plane or your own tooling. Confirm plugin compatibility for each version you plan to run, because plugins that depend on enterprise or Konnect-only features will not carry over.
- Best-fit option: Kong Gateway OSS, deployed with Docker, Kubernetes or Linux packages.
- Control plane needed: Kong's admin API with declarative configuration, managed through Git and CI pipelines.
- Plugin inventory: List every plugin in use and mark each as OSS, enterprise-only or custom.
- Custom plugins: Confirm they run against the target Kong version in a test environment.
- Decision point: Verify that no enterprise-only plugin is required by a production route before you commit.
The Kong Gateway repository and the 3.9.1 community release notes are the natural starting points for checking which features ship in the open-source edition.
When your platform team already runs everything on Kubernetes, the gateway should follow the same operating model: declarative manifests, GitOps delivery and controllers that reconcile state. Kong Gateway OSS can run through Kubernetes, and Apache APISIX doubles as a Kubernetes ingress controller, which makes it a candidate when ingress and API traffic should share one component. The control plane choice then shifts to whatever your cluster tooling supports for configuration, rollout and observability, and you should confirm how each option handles upgrades and multi-cluster deployments.
- Best-fit option: Apache APISIX as ingress controller and gateway, or Kong Gateway OSS on Kubernetes.
- Control plane needed: Custom resources and controllers managed through your GitOps tool.
- Configuration model: Confirm whether routes, plugins and consumers are expressed as custom resources or through an admin API.
- Upgrades: Check the rollout method and whether configuration changes apply without restarts.
- Decision point: Test a canary upgrade in a non-production cluster before standardizing on one gateway across clusters.
Ask your platform team which Kubernetes distributions and versions you support, then verify the gateway's compatibility matrix against them.
In banking, healthcare and public sector settings, the gateway is part of the evidence chain for access control, logging, change management and vendor risk. Moving off Konnect means you become responsible for producing that evidence yourself. Open-source options give you full access to source code and configuration, but they do not come with certifications or attestations, and independent auditors decide whether your controls are sufficient. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications.
- Best-fit option: WSO2 API Manager or Gravitee for access control, subscriptions and audit-oriented portals, with Kong or APISIX as the runtime if preferred.
- Control plane needed: A self-hosted management plane with role-based access, audit logs and change records.
- Evidence: Define which logs, approvals and configuration histories you will retain and for how long.
- Vendor support: Decide whether you need a paid support subscription for open-source components.
- Decision point: Ask your assessor which control evidence they expect before you finalize the architecture.
Document the control mapping early, and confirm each control requirement with your independent auditor rather than assuming an open-source component satisfies it.
What you give up when leaving Konnect and the usual workarounds
Moving Kong Gateway to self-hosted operation keeps the data plane you already run but removes the Kong-managed control plane, its hosted cloud options and the vendor-run operations behind them. Each card below names one gap, the workaround teams usually adopt, and what to confirm before you commit.
Management UI and developer portal
Konnect gives you a hosted console for services, routes, consumers and a developer portal. Open-source Kong Gateway OSS is managed through its Admin API and declarative configuration files, so the console has to be replaced by a separate control plane, a GitOps workflow or a self-hosted UI. Check whether your teams need self-service API key issuance and documentation publishing, because those are the features that usually drive a portal decision.
Dedicated Cloud Gateways and serverless options
Konnect can run data plane nodes as serverless gateways or as Dedicated Cloud Gateways that Kong operates on AWS, Azure or GCP. Once you leave, every gateway node becomes your workload to size, patch, scale and place in a network. Confirm which regions and clouds you need, who will own node capacity planning, and how traffic failover works across your own clusters.
Vendor-managed upgrades and support
Under Konnect, Kong operates the control plane and the hosted runtime options, so upgrades to that layer happen without your team scheduling them. With Kong Gateway OSS you schedule upgrades yourself, for example moving from one 3.9 release to the next, and test plugin compatibility before each change. Decide whether you will rely on internal platform staff, community channels or a commercial support contract for production incidents.
Analytics dashboards
Konnect provides hosted analytics on API traffic and latency. Self-hosted gateways need a metrics pipeline you build, typically Prometheus-compatible metrics feeding a dashboard tool and log storage with your own retention rules. Ask what request-level detail auditors and product owners need, how long it must be kept, and which team owns the dashboards after launch.
SSO and RBAC depth
Konnect offers organization-level roles, team scoping and identity federation managed by Kong. Open-source Kong Gateway OSS does not give you that control plane identity model out of the box, so access to the Admin API and configuration repositories becomes the main control. Map who may change routes, plugins and consumers, then decide whether to use an identity provider in front of a self-hosted UI or to restrict changes through Git review. Confirm these controls with your security team before cutover.
Configuration migration and plugin parity
Your existing Kong declarative configuration and plugins are the asset that carries over most directly. Export entities from the current environment, validate them against the open-source gateway version you plan to run, and list every enterprise-only plugin or feature in use before you start. Where a feature has no open-source equivalent, plan a replacement or a commercial license, and confirm each item in writing.
What running a self-hosted gateway costs compared with Konnect
This table lists each cost component of running Kong Gateway OSS, APISIX or Tyk Gateway yourself against a Konnect subscription, and marks whether it is one-time or recurring. No prices appear because none are published here, so use the drivers column to scope your internal estimate and the quote column to compare vendor and partner offers on the same basis.
| Cost component | One-time or recurring | Main drivers | What to request or estimate |
|---|---|---|---|
| Konnect subscription | Recurring | Tier, number of gateway and data plane nodes, feature set, and whether you use Kong-managed Dedicated Cloud Gateways | Written Konnect quote for the same node count and features, so you can remove this line from your model |
| Data plane node infrastructure | Recurring | Node count, traffic volume, high availability layout, and whether nodes run in your cloud, data center or air-gapped network | Your own sizing from peak request rates and failover requirements, priced against your cloud or hardware contracts |
| Control plane hosting | Recurring | Choice of Kong Gateway control plane with a database or a GitOps model, and the database and backup layers it needs | Hosting, database and backup costs in your own environment, plus the operating hours needed to keep them current |
| Migration and configuration rewrite | One-time | Number of services, routes and plugins, custom Lua or Go plugins, and how much Konnect-specific configuration must be exported and re-expressed | Fixed-scope proposal listing the inventory, conversion approach and acceptance tests, agreed in writing before work starts |
| Testing and regression | One-time, plus recurring for upgrades | Route coverage, plugin behavior, performance targets and the number of environments to validate | Test plan with defined pass criteria per environment, and the cost of repeating it for each Kong or APISIX release |
| Developer portal setup | One-time, then recurring hosting | Whether you need a portal at all, catalog size, authentication integration and branding | Choice between an open-source portal such as Gravitee or a self-built site, with hosting and content upkeep quoted separately |
| Monitoring and logging | Recurring | Metrics volume, log retention, alert routing and the tooling you already run | Confirm which observability stack you will reuse and the storage cost of retained logs in your environment |
| On-call and internal skills | Recurring | Team size, hours of coverage, Lua or plugin development skills and familiarity with the chosen gateway | Internal staffing estimate covering on-call rotation and training, since this is usually the largest line item to model |
| Vendor and partner support | Recurring (optional) | Support tier, response expectations, upgrade and security patch handling and retainer scope | Written support scope and response terms from each vendor or partner, compared with your current Konnect support level |
How to move Konnect configuration to self-hosted gateways
This sequence moves services, routes, plugins and consumers from Konnect's managed control plane to a gateway you run in your own infrastructure, with traffic verified and a tested rollback before Konnect is switched off. Each step closes with a written output that the next step depends on.
Inventory services, routes, plugins and consumers
The platform or API team lists every Konnect service, route, plugin, consumer, certificate and upstream target, and marks each one as portable, rewritable or dependent on a Konnect-only feature such as the managed portal, analytics or Dedicated Cloud Gateway hosting. Include the data plane deployment type (self-hosted, serverless or Dedicated Cloud Gateway) because it changes where the replacement runs. Done when the inventory is a reviewed spreadsheet or config file that the security and application owners have both signed off on.
Export declarative configuration and secrets
Export the current control plane state in declarative form using Kong's tooling, and record which plugin settings reference secrets, vault entries or consumer credentials that must be recreated outside Konnect. Store the export in version control with restricted access, because it contains credentials and upstream details. Done when a fresh export can be diffed against the inventory and every entry has a matching line item.
Map each element to the target gateway
For each plugin and feature, decide whether Kong Gateway OSS, Apache APISIX or Tyk Gateway covers it natively, through an open-source plugin, or needs custom code or an external component. Kong Gateway OSS keeps the declarative format and most plugins closest to the current setup, while APISIX and Tyk need configuration translation. Confirm plugin availability and licensing against each project's documentation, since some capabilities sit behind commercial editions. Done when a mapping table lists every element as mapped, translated or unresolved, with an owner for each unresolved item.
Build and test a pilot gateway
Stand up the chosen gateway in a non-production environment inside your own cloud account or data center, using Docker, Kubernetes or a supported Linux package. Load a small set of low-risk routes and their plugins, then test authentication, rate limiting, header handling, TLS and logging against the same upstreams. Check consumer credentials and any secrets pulled from your vault. Done when the pilot passes the agreed functional and security test cases and the results are recorded.
Shadow production traffic in parallel
Run the self-hosted gateway alongside Konnect and mirror a copy of selected live traffic to it, while only Konnect serves responses to clients. Compare status codes, latency, response bodies and plugin decisions for the same requests, and investigate every difference. Confirm that the self-hosted gateway's logs and metrics reach your monitoring tools, since the managed analytics in Konnect will no longer be available. Done when mismatches are explained or fixed and the team accepts the observability replacement.
Cut over route groups in stages
Move production traffic one route group at a time, starting with the lowest-risk group, by changing DNS, load balancer or ingress targets to the self-hosted gateway. Keep the Konnect route active for that group so traffic can be returned quickly if errors appear. Advance to the next group only after the agreed monitoring period passes without incidents. Done when each group is serving from the self-hosted gateway and the cutover log records the time, owner and result of each change.
Rehearse rollback before decommissioning
Before turning anything off, run a rollback exercise for every migrated route group: switch traffic back to Konnect, confirm service, then switch forward again. Include a failure scenario such as losing the self-hosted control plane or data plane node. Record the steps and timings the team actually achieved. Done when the rehearsal results are signed off by the platform, security and application owners.
Decommission Konnect data plane and control plane
Once rollback tests pass and a stable period has elapsed, remove Konnect data plane nodes, revoke their certificates and API keys, and delete or archive the Konnect control plane objects according to your retention policy. Confirm that the contractual and billing end date with Kong matches the shutdown, and that exported configuration, logs and audit records are retained where your policies require. Done when no production traffic reaches Konnect, access is revoked, and the decommissioning record is filed with the change board.
Questions buyers ask before replacing Konnect
How much effort does moving off Kong Konnect actually take?
The effort depends mostly on how much of your estate is managed through Konnect and how much you rely on its portal and analytics. Moving the data plane is usually the smaller task, since Kong Gateway OSS can run in Docker, on Kubernetes or from packages on Ubuntu, RHEL, Debian and Amazon Linux, and it is licensed under Apache-2.0. The larger work is replacing what the Konnect control plane did for you: declarative configuration management, role-based access, developer onboarding, dashboards and audit trails. Count the services, routes, consumers, certificates and custom plugins you run today, then decide which management tooling will own each one. Ask any implementation partner to break its quote into those components.
How long does a Konnect replacement take, and what sets the timeline?
No timeline figure is supplied here, so treat any duration you see as something to verify against your own environment. The main drivers are the number of gateways and environments, whether traffic is already described in declarative files, how many consumers and developer portal users need migrating, and how strict your change windows are. Parallel running is the usual cutover pattern: you bring the open-source gateway up beside the Konnect data plane, shift routes gradually and keep a rollback path. Security review, certificate reissue and sign-off from application owners often take longer than the technical cutover itself. Ask for a dated plan with milestones tied to specific environments.
What does the internal team need to supply during the migration?
Your team needs to own the decisions that a SaaS control plane used to make for you. That includes choosing how configuration is stored and promoted between environments, who approves route and plugin changes, how secrets and TLS certificates are managed, and what monitoring and alerting replaces the Konnect dashboards. Engineers who already operate Kubernetes, load balancers and CI pipelines will adapt faster. Assign a named owner for the gateway platform, a security reviewer for policies and authentication, and application contacts who can test their own routes. Without these people, the project tends to stall at the first unclear ownership question.
Can we replace Konnect without outside help?
Yes, many teams do it with internal staff, provided they have the skills and time to run the platform after cutover. Outside help is most useful for scoping the move, designing the self-hosted control plane and developer portal, hardening the deployment, writing runbooks and testing failover. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, typically under a fixed scope agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. Compare a self-run plan with a partner-run plan on the same written scope, not on headline cost.
Does Kong OSS keep our existing plugins and configuration?
Kong Gateway OSS keeps the open-source plugin set and the core configuration model, so most routes, services and consumers can be exported from a Konnect-managed environment and re-applied to a self-hosted gateway. However, plugins and features that exist only in Kong's commercial offerings will not carry over, and some Konnect-specific settings need a different home. Inventory every plugin in use, check it against the OSS edition, and test each one in staging with production-like traffic. Custom Lua or Go plugins need a compatibility check against the version you deploy. Confirm the exact plugin list with Kong's documentation before you commit to a target version.
What happens to support and upgrades once we leave Konnect?
Once you run open-source software yourself, upgrades, security patches and vulnerability response become your responsibility or your partner's, unless you buy a commercial support subscription from the vendor. Kong Gateway OSS is developed in the open on its GitHub repository, and release notices appear on Kong's forum, such as the Community Edition 3.9.1 announcement dated June 6, 2025. Set a patch cadence, test upgrades in a staging copy of your configuration, and track end-of-life dates for every component, including the database and operating system. Ask any vendor or partner what response times they commit to in writing, and whether those terms are a fixed fee or a retainer.
How do license boundaries in Tyk and Gravitee affect the choice?
Tyk and Gravitee have different licensing lines, so the choice depends on which features you need. Tyk Gateway is under MPL-2.0 except code in its ee folder, and its management control plane, dashboard GUI and developer portal come with Tyk Self-Managed or Tyk Cloud under a commercial license. Gravitee API Management is Apache-2.0 with a gateway, management backend, console UI and developer portal, but some features require a Gravitee Enterprise License. Before you select either, list the management features you rely on today, map each one to the open-source or commercial tier, and get the license terms in writing. Apache APISIX, which is Apache-2.0 with etcd as its configuration store, is another option to compare on the same list.
Official sources for Kong, APISIX, Tyk and Gravitee
Start with the vendor's own documentation before you decide what to keep from Konnect. The Kong Konnect documentation describes the Kong-managed control plane and the three data plane options Kong lists: self-hosted nodes, serverless gateways and Dedicated Cloud Gateways. Read it for the exact list of features tied to the SaaS control plane, such as the management UI, analytics and portal, so your gap analysis matches what Kong actually provides rather than what you remember from your current setup. Confirm which of those features your team uses today by exporting your current configuration and reviewing the list of services, routes and plugins in use.
For the open-source gateway itself, the Kong Gateway repository is the primary reference for license terms, build instructions and the list of plugins that ship in the open-source edition. The Kong forum announcement for Kong API Gateway OSS Community Edition 3.9.1 confirms the June 6, 2025 release and the supported install methods, including Docker, Kubernetes and Linux packages. Pin your target version to a release named in that announcement or in the repository, and check the release notes for any plugin behavior that differs from the version you run now.
If you are evaluating Apache APISIX, Tyk Gateway, Gravitee or WSO2 API Manager as alternatives, start with their repositories. The Apache APISIX repository documents its etcd-backed configuration store, and the Tyk Gateway repository states that its dashboard, control plane and developer portal sit under a commercial license. The Gravitee API Management repository notes that some features require an enterprise license, and the WSO2 API Manager repository lists the components included under Apache-2.0. Confirm in each repository which management features are open source before you assume a UI or portal is free to run.
