Kong or Gravitee: which fits your API team
Choose Kong Gateway when your team needs a fast, self-hosted gateway for routing, load balancing, health checks and authentication, and you already have another way to publish and document APIs. Its open-source line is Apache-2.0 licensed and stays on the 3.9 line, which the Kong/kong repository shows with 3.9.4 released on October 12, 2026. Choose Gravitee APIM when you want the gateway, a management console for administrators and a Portal UI where API consumers find documented APIs in one platform, and you accept that some event and security features sit behind an Enterprise license.
The decision turns on three questions. First, do API consumers need a catalog and portal, or is your developer documentation handled elsewhere? Second, do you need event or Kafka endpoints? Gravitee lists Kafka publish and subscribe over HTTP and WebSocket as Enterprise Edition features, and its documentation states that the Enterprise Edition requires a license, so budget for that before you design around it. Third, how much vendor support do you need? Kong 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, so confirm with Kong what continuing support would look like after that date, and compare it with the Enterprise licensing terms you would need from Gravitee.
Run a short evaluation in your own environment before you commit. Deploy the Kong quick start (PostgreSQL through Docker Compose, with proxy traffic on port 8000) alongside a Gravitee Docker Compose stack with MongoDB, then test one real API with your authentication model. Ask each vendor in writing which features your use case needs and which edition includes them, and ask for the support terms in effect for your target release. Read the Kong version support policy before you pick a Kong release line, because the lines differ in support windows.
Which platform fits which team scenario
This table maps common team situations to the platform that fits better and the condition that decides it. Read each row as a starting point, then confirm the named condition against your own environment and the current edition terms before you shortlist.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Platform team wants a declarative gateway managed through GitOps in Kubernetes | Kong Gateway | DB-less mode keeps configuration in declarative files, which suits pipelines that review and apply changes. Confirm which plugins you need run in DB-less mode. |
| Team wants a console for administrators to manage APIs, plans and subscriptions | Gravitee APIM | The Console UI is a built-in component of APIM. Kong Manager is also a web interface, so confirm the admin workflows you need in each. |
| API product team must publish a developer portal for external developers | Gravitee APIM | APIM includes a Portal UI with an API catalog and documentation. Kong's open-source line does not describe a comparable portal, so confirm portal needs with Kong before deciding. |
| Team must expose Kafka, MQTT or RabbitMQ endpoints through the gateway | Gravitee APIM | Gravitee lists these endpoints as Enterprise Edition features. Confirm the license scope and which endpoints your deployment requires. |
| Team wants a lightweight gateway on the Apache-2.0 open-source line | Kong Gateway | Kong's open-source repository is Apache-2.0 and releases stay on the 3.9 line. Confirm support windows for 3.9 before committing, since end of sunset support is December 12, 2026. |
| Team already runs Kong and wants to add API management features | Kong Gateway (stay) | Migration cost and operator familiarity favor staying put unless Gravitee's console or portal is a hard requirement. Ask both vendors what a migration of your policies would involve. |
| Team already runs Gravitee and needs event or AI proxies | Gravitee APIM (stay) | Enterprise features such as Kafka endpoints and LLM or MCP proxies require an APIM Enterprise license. Confirm license terms and renewal scope. |
| Team needs OpenID Connect at the gateway | Confirm with both vendors | Kong's OpenID Connect plugin is an Enterprise tier plugin, so it is outside the open-source gateway. Confirm Gravitee's equivalent entitlement for your edition. |
How each platform is built and deployed
Kong and Gravitee both separate the traffic path from the management layer, but they place state in different components and offer different deployment shapes. The cards below show which parts need a database or backing store, where a failure would land, and which questions to settle before choosing a topology.
Kong traditional mode
In traditional mode every Kong node connects to a shared database, so the database holds routes, services and plugin configuration that all nodes read. This is the simplest mental model and the one most teams start with. The failure domain includes the database: if it becomes unavailable, nodes cannot pick up configuration changes, and the database must be backed up, upgraded and sized alongside the gateway. Confirm your recovery objectives for the database before choosing this mode.
Kong DB-less mode
In DB-less mode Kong holds its configuration in memory and loads it from a declarative file, so no database sits in the request path. Each node is an independent unit that can be replaced from the same configuration source, which suits GitOps pipelines. The trade-off is that changes flow through files and redeployment rather than the Admin API. Check which plugins and workflows your team relies on that expect a database before committing to this topology.
Kong hybrid mode
Hybrid mode separates a control plane, which holds the database and accepts configuration, from data planes that serve traffic without one. A control plane outage leaves running data planes serving their last known configuration, which limits the blast radius of management failures. Operators must still secure the link between control and data planes and plan for certificate handling. Confirm that the open-source 3.9 line supports the topology you need, since hybrid deployments are typically tied to the licensing and support model you choose.
Kong Konnect and Kong Manager
Kong Manager is the web interface that ships with the gateway and runs against the Admin API in your own environment. Kong Konnect is Kong's cloud control plane for managing gateways across environments, so choosing it moves some management state outside your infrastructure. Decide whether administrators need a self-hosted console, a hosted control plane or both, and confirm which management features each option includes on the edition you plan to run.
Gravitee gateway and management backend
Gravitee APIM separates the gateway from the management API backend, which holds API definitions and lifecycle data, and from the Console UI for administrators and the Portal UI for consumers. The gateway is the traffic component, while the management backend and its store are the control path. A failure in the management backend does not stop traffic already routed through the gateway, but it does block publishing and administration. Map which store backs each component in your chosen deployment.
Gravitee deployment options
Gravitee documents a Helm chart for Kubernetes, including AKS, GKE, EKS and OpenShift, and a Docker Compose setup that uses MongoDB. The Docker Compose path is a quick start, while Kubernetes adds replicas, rolling upgrades and more moving parts for your platform team to operate. Gravitee also documents SaaS, hybrid and fully self-hosted deployment for Enterprise customers, while the Community Edition is self-hosted. Confirm with Gravitee which edition and deployment model your compliance and data residency rules allow.
Which capabilities each open-source edition includes
This table compares what each open-source edition ships with, row by row, so you can separate the free core from features that sit behind an Enterprise license. Where a cell says to confirm, check the current release notes or ask the vendor before you plan around that feature. The main takeaway: Kong's open-source line covers the gateway, while Gravitee's Apache-2.0 scope adds a console and portal but keeps Kafka, event and AI endpoints in the Enterprise Edition.
| Capability | Kong Gateway open source (3.9 line) | Gravitee APIM Apache-2.0 edition |
|---|---|---|
| License | Apache-2.0 for the Kong/kong repository, with releases on the 3.9 line | Apache-2.0 for Gravitee API Management; Enterprise Edition requires a license |
| Authentication | JWT, basic auth, OAuth and ACL listed; OpenID Connect is an Enterprise-tier plugin | Confirm the Community policy set; the enterprise policy pack is Enterprise only |
| Management UI | Kong Manager web interface; confirm which features ship in the 3.9 open-source build | Console UI for administrators and Portal UI for consumers |
| Developer portal | Not described in the supplied open-source facts; confirm with Kong before planning | Portal UI with a catalog of APIs and documentation, per the repository README |
| Kafka and event endpoints | Not listed in the open-source facts; confirm before relying on event endpoints | Kafka publish and subscribe over HTTP and WebSocket is Enterprise Edition only |
| LLM and MCP features | LLM and MCP gateway features listed in the README; confirm scope on the 3.9 line | LLM and MCP proxies are listed as Enterprise Edition features |
| Kubernetes support | Kubernetes ingress controller listed in the README; confirm the chart and version for your cluster | Helm chart for AKS, GKE, EKS and OpenShift; confirm which components it deploys |
How plugin models and identity integration differ
Kong extends its gateway through plugins, which the Kong/kong README describes as written in Lua, Go or JavaScript. Custom logic lives in the request path as plugin code, so a team that builds its own plugins owns the language choice, the test harness and the upgrade work each time the gateway moves to a new release. Some capabilities sit outside the open-source line entirely. The OpenID Connect plugin is an Enterprise-tier plugin in Kong's plugin documentation, so a team that expects to federate users against an existing OIDC provider must check that plugin's tier before it commits to the open-source 3.9 line. Confirm which of the authentication plugins you need (JWT, basic auth, OAuth, ACL or OIDC) are available on the edition you plan to run, and list any custom Lua, Go or JavaScript plugins you would have to maintain yourself.
Gravitee takes a policy-based approach in its APIM gateway, and its Enterprise Edition adds a further policy pack alongside controls such as data masking, GeoIP filtering and Dynamic Client Registration. Those features matter most when your requirements include protecting sensitive fields in responses, restricting access by country, or letting client applications register themselves against an identity provider. Each of them is an Enterprise capability according to Gravitee's Enterprise Edition documentation, so a team that only needs the Community Edition should not assume they are present. The open-source policies are the part you must test directly. Confirm, in a proof of concept against your own identity provider, how the Apache-2.0 gateway handles OIDC or JWT validation, token introspection and the Console and Portal sign-in flows, and do not rely on the feature list alone.
The decision comes down to where identity logic should sit. If your identity provider is already the source of truth and your gateway only needs to validate tokens, check whether Kong's open-source authentication plugins meet that need before budgeting for Enterprise. If you need masking, geographic controls or client self-registration at the gateway, test whether Gravitee's Enterprise features are required and price them into the quote. Ask each vendor, in writing, which plugin or policy implements each identity control you need, which edition includes it, and what changes when you upgrade. That answer, tested against your own identity provider, is the most reliable basis for comparing the two.
What each license covers and what the paid tiers add
The open-source Kong Gateway is licensed under Apache-2.0, and the Kong/kong repository keeps its releases on the 3.9 line. The most recent release in the supplied record is 3.9.4, published October 12, 2026, following 3.9.3 on June 17, 2026. This edition covers core gateway functions: routing, load balancing, health checking, and authentication through JWT, basic auth, OAuth and ACL, plus plugins written in Lua, Go or JavaScript. It suits teams that want the gateway under an open license and can carry their own patching and upgrades.
- What you pay for: no license fee for the gateway itself. Your costs are infrastructure, internal staff time for patching and upgrades, and any support you buy separately.
- Support window: Kong's version support policy shows 3.9 past full support since December 12, 2025, with sunset support ending December 12, 2026. The policy applies to Kong Gateway Enterprise, so confirm in writing what, if anything, covers the open-source line after that date.
- Enterprise-tier plugins: the OpenID Connect plugin is marked Enterprise in Kong's plugin documentation, so OIDC is not part of this line.
- Management features: Kong Konnect and Kong Manager appear in Kong's documentation. Confirm which management features your 3.9 build includes before you design around them.
Before committing, confirm the upgrade path from 3.9 to a supported line and who will ship security fixes after December 12, 2026.
Kong Gateway Enterprise is the commercial distribution that ships the newer release lines. Kong's version support policy lists 3.16 as the latest version, released September 15, 2026, with 3.10 and 3.14 designated as LTS releases supported until March 31, 2028 and April 7, 2029. You pay for the license, the support entitlement and any Enterprise-tier plugins, and the support window you buy is the main factor in how long a release line stays under vendor care.
- Release lines: choose between the latest 3.16 release and the LTS lines 3.10 or 3.14, depending on how often your team can take upgrades.
- Support windows: 3.10 is supported until March 31, 2028 and 3.14 until April 7, 2029. Ask whether the contract covers patches for the full window of the line you select.
- Enterprise plugins: OpenID Connect and other Enterprise-tier plugins are licensed separately from the Apache-2.0 gateway. Ask for the complete plugin list in the quote.
- Deployment and control plane: Kong documents traditional, DB-less and hybrid self-managed topologies, and Konnect is the cloud control plane. Ask which topologies and management features the license covers.
Ask for the license terms in writing, including the metering basis, upgrade rights and what happens to support when a release line leaves its window.
The Gravitee API Management Community Edition is licensed under Apache-2.0 and is self-hosted. The repository describes the platform as an open-source solution to control who, when and how users access APIs and to manage the API lifecycle. Its components are the gateway, the management API backend, the Console UI for administrators and the Portal UI, which provides a catalog of APIs with documentation. The repository was tagged core_4.13.1 on October 15, 2026, and Gravitee's documentation covers API Management 4.12.
- What you pay for: no license fee for the platform. Your costs are infrastructure, database operations, internal upgrade effort and any support contract you choose to buy.
- Install options: the README lists Docker Compose with MongoDB and a Helm chart for Kubernetes, including AKS, GKE, EKS and OpenShift.
- Support window: no supported support policy for the Community Edition is in the record for this page. Ask Gravitee for its published patch policy for the 4.12 documentation line and the 4.13 release tag before adopting.
- Enterprise-only features: Kafka endpoints, audit trails and data masking are listed under Enterprise Edition, so they are not part of the open-source distribution.
Verify that every feature your use case depends on appears in the Community documentation before you assume parity with Enterprise.
Gravitee's documentation states that the APIM Enterprise Edition requires a license. Gravitee documents SaaS, hybrid and fully self-hosted deployment for Enterprise customers. The paid layer adds event and messaging endpoints, security and governance features, and AI proxies that the Community Edition does not include. Gravitee's own feature list is the basis for what follows, so confirm each item against the contract scope.
- Event endpoints: Kafka publish and subscribe over HTTP and WebSocket, Azure Service Bus, MQTT5, RabbitMQ, Solace and JMS, plus Server-Sent Events and Webhook entrypoints. Confirm the broker versions your estate runs.
- Security and governance: data masking, GeoIP filtering, Dynamic Client Registration, an enterprise policy pack, the Alert Engine, Redis caching, and audit trails of API consumption and activity.
- AI and agent proxies: Agent-to-Agent, LLM and MCP proxies. Confirm model and protocol coverage in writing, since these features change quickly.
- Deployment model: SaaS, hybrid or fully self-hosted. Self-hosted matters when API traffic and audit data must stay inside your own infrastructure.
- Support window: no support window is supplied for Enterprise releases. Ask for the release lines covered and how long each one receives patches.
Before signing, ask for the license scope, the metering basis and the written support window for each feature you plan to use.
What drives the running cost of each platform
Running cost for Kong and Gravitee comes from the components you operate, the skills your team needs to run them, and the licensing that unlocks features you may need. The cards below separate one-time work from recurring cost and list what to request in a written quote.
Database and cluster footprint
Kong in traditional mode requires every node to connect to a shared database, so you run and back up PostgreSQL alongside the gateway nodes. DB-less and hybrid modes change that footprint, and both are documented options. Gravitee's Docker Compose path runs MongoDB as a required component. Ask each vendor, or your own architect, which components run in production, who patches them, and what backup and restore testing the design needs.
Kubernetes and hosting footprint
Gravitee publishes a Helm chart for AKS, GKE, EKS and OpenShift, and Kong runs as a Kubernetes ingress controller. The recurring cost is the cluster capacity, load balancers and observability you add to each environment. Hybrid deployments add a control plane alongside data planes, so you pay for more nodes. Estimate the footprint per environment, including staging, and ask who sizes it and who supports it after go-live.
Skills needed to run each
Kong's open-source path centers on declarative configuration, the Admin API and plugins in Lua, Go or JavaScript, so your team needs gateway operations skills plus plugin development for custom logic. Gravitee's platform includes a console, a developer portal and a management API, which spreads the work across more roles. Plan for on-call coverage, configuration review and the people who own each policy or plugin over time.
Support window on Kong 3.9
The Kong/kong open-source line stays on 3.9, and 3.9 reached end of full support on December 12, 2025. Its end of sunset support falls on December 12, 2026, which is the date to plan around. Ask Kong which support options apply to your open-source deployment after that date, and whether a move to a supported Enterprise line is needed to keep receiving fixes. Build the migration into your budget as a recurring risk, not a one-off.
Enterprise licensing for event and AI features
Gravitee's Enterprise Edition requires a license and adds Kafka publish and subscribe, MQTT5, RabbitMQ, Solace, JMS, data masking, Redis caching and LLM and MCP proxies. Kong's OpenID Connect plugin is an Enterprise-tier plugin, so it is not in the open-source gateway. Both are recurring subscription costs that scale with the features you enable. Ask each vendor for a written quote that lists the exact features, the node or environment counts they price against, and renewal terms.
Upgrade effort and moving later
Kong publishes LTS releases, including 3.10 and 3.14, alongside non-LTS releases, so you choose a release cadence and plan upgrades against it. Gravitee's Enterprise and Community lines also move on their own schedules. Moving away later means rebuilding routes, policies, plugins and developer portal content, and re-testing every integration. Ask for a documented upgrade path, a rollback plan, and a written estimate of the migration effort if you switch platforms.
How to move between Kong and Gravitee without losing routes or policies
This sequence moves API traffic, consumer access and policy behavior from one gateway to the other in controlled stages, so the old and new gateways can run side by side until each route is proven. It also sets clear expectations about what exports cleanly and what must be rebuilt by hand.
Inventory routes, consumers, plugins and policies
The team that owns the current gateway lists every service, route, upstream, consumer, credential type, plugin attachment and global configuration, and records which API each one serves. Architects and API owners confirm which routes carry production traffic and which are retired. The output is a signed inventory that names each item, its owner and its traffic volume source, so nothing is migrated by memory. Done when every production route maps to one owner and one consumer group.
Map each Kong plugin to a Gravitee policy
Platform engineers and security reviewers go through the inventory and pair each Kong plugin with the Gravitee policy or flow that produces the same behavior, such as authentication, rate limiting, transformation or logging. Items with no direct equivalent are flagged as gaps with a named decision owner and a proposed workaround. Confirm each mapping against the current documentation for both products, because plugin names, tiers and behavior differ. Done when every plugin has a mapped policy, a documented gap or an agreed removal.
Confirm edition, licensing and deployment topology
Before any build, the team confirms which Gravitee edition covers each required feature, since Gravitee documents that the Enterprise Edition requires a license and lists event, security and AI features under it. The team also decides on Kong's topology (traditional, DB-less or hybrid) and on Gravitee's Helm, Docker Compose or other deployment path, then records which Kong plugins are Enterprise-tier, such as OpenID Connect. Ask Gravitee and Kong to confirm these details for your use case. Done when a written decision record covers edition, topology and any licensed features.
Deploy a parallel Gravitee gateway
The platform team stands up Gravitee in the client's own environment alongside the running Kong deployment, with separate hostnames and no production traffic routed to it yet. Network, DNS, certificate and secrets handling are configured to the same standard as Kong, and the management API database is backed up before first use. The check is a working health endpoint, a successful test call through a test route and a restore test on the backup. Done when both gateways run in the same environment with separate traffic paths.
Rebuild plugin logic and portal content
Engineers rebuild anything that cannot be exported: custom Lua, Go or JavaScript plugin code must be re-implemented as Gravitee policies or external components, and portal pages, API documentation and onboarding text are rewritten in Gravitee's Portal UI. Security reviewers test each rebuilt policy against the original behavior, including error responses and header handling. Done when every custom plugin has a tested replacement, and the developer portal lists the migrated APIs with current documentation.
Import definitions and move consumer access
API definitions and consumer records are exported from Kong in a structured form and imported or recreated in Gravitee, with credentials handled through a documented secret transfer rather than plain files. Identity configuration, including OAuth or OpenID Connect clients, is aligned with the identity provider, and each consumer is tested against its new credential. Done when a sample of consumers from each credential type authenticates successfully on Gravitee and access rules match the inventory.
Shift traffic in stages and verify
Traffic moves route by route, starting with low-risk internal APIs, using DNS, load balancer weights or client configuration changes that can be reversed quickly. Each stage has written success criteria covering error rates, latency, authentication failures and logging output, reviewed by the API owner before the next stage. Done when every production route runs on Gravitee for an agreed observation period and the rollback path has been exercised at least once.
Retire Kong and its database
Once all routes are verified, the team disables Kong traffic, takes a final export and backup of its configuration and database, and stores them under the retention policy the organization requires. The Kong nodes, the database and any hybrid control plane components are decommissioned, and access credentials are rotated or revoked. Auditors or security reviewers confirm the removal and the stored archive. Done when Kong serves no traffic, its data is archived and its credentials are no longer valid.
Where implementation projects usually run long
Implementation projects on this pair usually run long for reasons outside the gateway itself, so plan for those before the first install. On the Kong side, the first decision is the topology: traditional mode with a database, DB-less mode with declarative configuration held in memory, or hybrid mode with separate control and data planes. That choice sets how routes and plugins are promoted through CI/CD, how Kubernetes ingress is wired, and whether Konnect is involved. On the Gravitee side, the work centers on the Helm chart or Docker Compose deployment with MongoDB, customization of the Portal UI, and a licensing decision made early. Kafka publish and subscribe, MQTT5, RabbitMQ, Solace, JMS and webhook entrypoints sit in the Enterprise Edition, so a team that needs event endpoints must get license approval before design is frozen, not after.
Overruns tend to start with plugin gaps found late. Confirm each required capability against the edition you will actually run: Kong's OpenID Connect plugin is an Enterprise-tier plugin, and Gravitee's data masking, GeoIP filtering, Dynamic Client Registration and Redis caching are Enterprise features. Identity integration is the second common source of delay, because token validation, client registration and consumer mapping differ between the two platforms and need an identity owner in the room. Consumer migration is the third. Moving applications from an existing gateway means changing hostnames, credentials and routing, and that work is often planned as a one-day cutover when it runs for weeks.
DeployOpen works from a fixed written scope agreed before work starts, so the scope must name the platform, the edition and the topology in play. A scope that says only "API gateway" cannot be priced or timed honestly. Ask for the Kong topology and whether Konnect is included, the Gravitee edition and license status, the list of event and security features in use, the identity provider, the deployment target, and the consumers to be migrated. DeployOpen does not publish a price list, so the quote follows from that written scope.
What buyers ask before choosing Kong or Gravitee
How much does it cost to run Kong or Gravitee?
Neither open-source edition charges a license fee, so the cost to run either one is mostly infrastructure, staff time and any Enterprise license, and the vendor quote sets the figure to compare. Kong Gateway's open-source line is Apache-2.0, and Gravitee APIM's gateway, console and developer portal are Apache-2.0 as well. The recurring costs are hosting for the gateway, database or MongoDB, observability, and the people who operate and upgrade the platform. Gravitee's Enterprise Edition requires a license for features such as Kafka endpoints, and Kong's Enterprise tier also carries licensing terms. Ask each vendor for a written license quote covering the editions, number of nodes or APIs, and support level you plan to use. Ask DeployOpen for a fixed-scope quote based on your written requirements, since DeployOpen does not publish a price list.
How long does a Kong or Gravitee implementation take?
The duration depends on how much of the platform you deploy, integrate and govern, and no fixed timeline applies to every team. The main drivers are the topology you choose for Kong (traditional, DB-less or hybrid), the number of APIs and environments, authentication and identity integration, and whether you need Gravitee's event endpoints, developer portal and API lifecycle workflows. Plugin development, certificate and network work, and testing against your upstream services also add time. Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ask for a timeline that lists each milestone, the environments it covers, and the testing and handover steps included.
Can our own team run Kong or Gravitee without outside help?
A team with Kubernetes, PostgreSQL and API security experience can run either platform, but the skills differ by product and topology. For Kong, operators need to understand declarative configuration for DB-less mode, the control and data plane split in hybrid mode, database administration for traditional mode, and plugin development in Lua, Go or JavaScript where custom behavior is needed. For Gravitee, the self-hosted options include a Helm chart for Kubernetes and Docker Compose with MongoDB, so the team needs container, database and console administration skills. Check whether your staff can own on-call, backups and upgrades before choosing. DeployOpen can plan, implement, document and support either platform inside your infrastructure, and ongoing support and upgrades are available as retainers.
Is Kong Gateway 3.9 safe to run after December 12, 2026?
Kong Gateway 3.9 is safe to run only if you have a dated plan to move off it, because its sunset date falls on December 12, 2026. Kong's version support policy says 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, and the policy applies to Kong Gateway Enterprise. The open-source Kong/kong repository stays on the 3.9 line, with 3.9.4 released on October 12, 2026, so confirm with Kong whether open-source 3.9 receives patches after the sunset date. Plan the upgrade path to a supported line: Kong lists 3.10 and 3.14 as LTS releases supported until March 31, 2028 and April 7, 2029, and 3.16 as the latest release. Test configuration, plugins and topology changes in a staging environment before the cutover.
Does Gravitee Community Edition include Kafka endpoints?
No, Kafka publish and subscribe over HTTP and WebSocket is listed among Gravitee's Enterprise Edition features, so the Community Edition does not include it. Gravitee lists Kafka endpoints alongside Azure Service Bus, MQTT5, RabbitMQ, Solace and JMS endpoints, plus Server-Sent Events and Webhook entrypoints, as Enterprise features. The Community Edition is self-hosted under Apache-2.0 and covers the core gateway and management components. If Kafka is central to your design, budget for an Enterprise license and confirm the exact edition matrix with Gravitee before you commit to an architecture. Ask Gravitee for a written statement of which endpoints each edition supports for your version.
Does Kong open source include OpenID Connect and other enterprise plugins?
No, Kong's OpenID Connect plugin is marked as an Enterprise tier plugin, so it is not part of the open-source gateway. The Kong/kong README describes open-source authentication options including JWT, basic auth, OAuth and ACL, along with routing, load balancing and health checking. Teams that need OIDC with an identity provider on the open-source line should plan an alternative such as an upstream authentication service, or evaluate the Enterprise tier. Confirm the plugin tier in Kong's documentation for your exact version before finalizing the design. DeployOpen can help define the authentication architecture and integration, with the scope agreed in writing first.
How are DeployOpen engagements scoped and priced for these platforms?
DeployOpen scopes most engagements as fixed-scope work, with the scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from that written scope. The scope usually covers planning, implementation, customization, integration, hardening, backups, upgrades, documentation and support for the platform inside your own cloud accounts, data centers or air-gapped networks. Ask for the quote to list each deliverable, the environments in scope, the handover and training included, and any ongoing retainer for support, upgrades or continuous testing. Compare quotes on the same written scope, and list the platform licenses separately, since those are paid to the vendor.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Kong vs Gravitee, we start from the gateway and management decisions in front of you, then build and hand over only what your written scope agrees.
How we scope
- We confirm which Kong topology (traditional, DB-less or hybrid) and which Gravitee edition fit your traffic and governance needs.
- We list which Enterprise Edition features, such as Kafka endpoints or audit trails, are in or out of scope before work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and ongoing support available as a retainer.
How we build
- We deploy the chosen gateway in your environment and wire authentication, routing and plugin configuration to your identity provider.
- We test plugin behavior, health checks and failover against the scenarios written into the scope, not generic defaults.
- We run security testing on the exposed APIs and gateway configuration so findings are fixed before go-live.
How we hand over
- You receive architecture notes, configuration as code, and runbooks covering upgrades, backups and day-two operations.
- We document the support window for the release line you run, so your team knows which version lifecycle applies to it.
- We walk your operators through the setup and record the decisions behind each topology and licensing choice.
How we support
- Retainers can cover ongoing support, version upgrades and continuous testing of your gateway and API layer.
- We help you prepare the controls and evidence that compliance assessors will ask for, without issuing any audit report.
- Ask us to confirm the exact retainer terms and response arrangements in the written quote before you commit.
