Kong vs Envoy Gateway: which to choose

When to choose Kong Gateway or Envoy Gateway for Kubernetes API traffic

Choose Kong Gateway when your platform team wants a mature plugin catalog and a management layer around the gateway. Choose Envoy Gateway when the team is standardizing on Gateway API resources and Envoy extensions. The decision turns on four factors: whether the OIDC licensing fits your budget, which plugins you need from the first release, which Kong topology your team can operate, and whether your clusters already run Kubernetes with Gateway API. Settle the licensing and plugin questions before you pilot either product, because they determine which features you can use at all in production.

Start with OIDC, since it is the factor most likely to change the cost. Kong's OpenID Connect plugin is marked as an Enterprise tier plugin, so it is not part of the open source gateway, and the open source Kong/kong line stays on 3.9 while newer releases ship as Kong Gateway Enterprise. Envoy Gateway's documentation covers OIDC alongside API key, basic and JWT authentication, mutual TLS and external authorization. Ask Kong for a written list of the plugins your traffic needs, marked by edition, and test the OIDC flow on Envoy Gateway in a non-production cluster against your own identity provider before you accept that it meets your token and session requirements.

Then check the topology and Kubernetes fit. Kong documents traditional, DB-less and hybrid self-managed topologies, and each one changes what your operators must run, including a database in traditional mode and separate control and data planes in hybrid mode. Envoy Gateway installs with Helm, Argo CD or Flux CD, offers a standalone mode outside Kubernetes, and publishes guides for air-gapped environments. If you are leaving Ingress NGINX, note that Kubernetes ended further Ingress NGINX releases after March 2026, which makes that migration a time-bound task. Confirm that your cluster's Kubernetes and Envoy Proxy versions appear in Envoy Gateway's compatibility matrix before you commit to a version.

Which gateway fits which scenario

This table maps common Kubernetes and mixed-estate scenarios to the gateway that fits each one better, with the condition that drives the choice. Read each row as a decision: if your condition matches the middle column, the right-hand column names the platform that usually fits, and the last column explains what to confirm before committing.

Scenario	Better fit and why	Condition that decides it
Kubernetes-only ingress built on Gateway API	Envoy Gateway, because it provisions and configures Envoy proxies through Gateway API resources and is designed around that model.	Your platform team standardizes on Gateway API and does not need a non-Kubernetes data plane.
Enterprise-tier OIDC enforced at the gateway	Kong Gateway Enterprise, because its OpenID Connect plugin is an Enterprise-tier plugin and is not part of the open-source line.	You need Kong's OIDC plugin specifically and accept an Enterprise license. Envoy Gateway documents OIDC authentication, so confirm the exact flows and claims you require against its documentation.
OIDC in the open-source tier	Envoy Gateway, since its documentation covers OIDC authentication alongside JWT, API key and basic authentication.	Your OIDC requirements match what Envoy Gateway documents. Test your identity provider integration in a staging cluster before relying on it.
Mixed VM and Kubernetes estate	Kong Gateway, because it documents traditional, DB-less and hybrid self-managed topologies, so one gateway model can cover VM-hosted and cluster-hosted services.	Services outside Kubernetes need a gateway that runs there. Envoy Gateway documents a standalone mode outside Kubernetes, so confirm that mode meets your operating model.
Air-gapped deployment	Either platform can fit, but Envoy Gateway publishes a guide for air-gapped environments, which makes it the easier starting point to verify.	Your mirror process covers all images, Helm charts and dependencies. Ask Kong for its air-gapped procedure for the edition you license.
Teams that want Lua or Go plugins	Kong Gateway, because its plugin ecosystem is written in Lua, Go or JavaScript and is the core of how teams extend it.	Your developers already write Lua or Go, and you value a plugin model with a long history. Envoy Gateway extends through Wasm, Lua, dynamic modules, external processing and an extension server, which suits teams building on Envoy.
Teams that want Wasm or Envoy-native extensions	Envoy Gateway, because Wasm and external processing are part of its documented extension options.	Your extensions must follow Envoy's extension model. Confirm the Wasm runtime, language support and maintenance path for your specific filters.
Hosted control plane through Konnect	Kong Gateway with Konnect, since Konnect is Kong's cloud control plane for managing gateways across environments.	You accept a vendor-hosted control plane for gateway configuration. Confirm data residency and where configuration is stored before you connect self-managed nodes.
Self-hosted control plane with no SaaS dependency	Envoy Gateway, because it runs as a Kubernetes controller or standalone deployment that you install with Helm, Argo CD or Flux CD.	Your policy forbids a vendor-hosted management plane. Confirm which Kong topology and licensing path avoids Konnect if you choose Kong.

How Kong and Envoy Gateway are built and deployed

Kong and Envoy Gateway start from different operating models. Kong is a gateway you choose a database topology for, while Envoy Gateway is a Kubernetes controller that provisions and manages Envoy proxies from Gateway API resources. The cards below set out what each choice means for day-to-day operations, upgrades and the blast radius of a failure.

Kong traditional mode with a database

In traditional mode every Kong node connects to a shared database, so configuration is stored centrally and any node can serve the same state. Operations are familiar to teams used to database-backed services, but the database becomes a dependency you must back up, size, and upgrade alongside the gateway. Confirm how your team will handle database migrations during Kong version changes, and who owns database failover in your environment.

Kong DB-less mode

DB-less mode holds configuration in memory and loads it from a declarative file, which removes the database from the runtime path. This suits GitOps pipelines where every change is reviewed and versioned, but changes must go through the declarative file rather than the Admin API. Check how your team will roll out config updates across nodes and how it will detect configuration drift between them.

Kong hybrid mode

Hybrid mode separates control plane nodes, which hold the database, from data plane nodes that serve traffic without one. This narrows the failure domain for proxy traffic and limits how much of the estate is exposed to the database, but it adds a second set of components to patch and monitor. Confirm the connectivity and certificate arrangements between planes in your network, and whether the hosted Konnect control plane fits your data residency rules.

Envoy Gateway on Kubernetes

Envoy Gateway runs as a controller that reads Gateway API resources and provisions the Envoy proxies those resources describe. Upgrades touch the controller and the proxy versions it manages, so the project's compatibility matrix between Envoy Gateway, Envoy Proxy and Kubernetes versions becomes a required upgrade check. Confirm that your Kubernetes version and Helm, Argo CD or Flux CD workflow are on that matrix before you schedule an upgrade window.

Envoy Gateway standalone mode

Envoy Gateway also supports a standalone deployment outside Kubernetes, which lets teams run the same gateway model on virtual machines or bare metal. Standalone mode changes where failures land, since the host and its process supervision become your responsibility rather than the cluster scheduler. Ask whether your platform team can operate that model, and whether the air-gapped installation guides cover the images and charts your environment needs.

Plugin, extension and identity features compared

This table compares how Kong Gateway and Envoy Gateway handle routing, authentication, traffic controls, extensibility and management. Read each row as a question to confirm in your own environment, because Kong's plugin set depends on edition and Envoy Gateway's features depend on the Gateway API resources you deploy. The main takeaway is that Kong offers a broad plugin catalog with an Enterprise-tier OIDC plugin, while Envoy Gateway covers OIDC in its documented feature set and fits Kubernetes-native teams.

Capability	Kong Gateway	Envoy Gateway
Routing and load balancing	Routing, load balancing and health checking are described in the Kong/kong README for the open-source gateway.	Traffic routing is configured through Gateway API resources that Envoy Gateway uses to provision managed Envoy proxies.
Authentication methods	JWT, basic auth, OAuth and ACL are listed in the open-source README. Confirm which plugins your edition includes.	API key, basic, JWT, OIDC, external authorization and mutual TLS are in the documentation. Confirm each against your Gateway API version.
OIDC support	The OpenID Connect plugin is an Enterprise-tier plugin, so it is not part of the open-source gateway.	OIDC is listed in the Envoy Gateway documentation. Confirm the supported provider configuration and version with the project.
Rate limiting, CORS and IP filtering	Covered through plugins in the plugin catalog. Confirm which of these plugins your edition and version ship with.	Rate limiting, CORS and IP allow and deny lists are documented. Confirm the policy resources and proxy version you plan to run.
Extension languages	Plugins can be written in Lua, Go or JavaScript, according to the Kong/kong README.	Wasm extensions, Lua extensions, dynamic modules, external processing and an extension server are documented. Confirm which are production-ready for your release.
Kubernetes integration	Includes a Kubernetes ingress controller. Confirm the controller version and its fit with your Gateway API or Ingress plans.	Built around Gateway API resources, with Helm, Argo CD or Flux CD install guides and a migration guide from Ingress resources.
Management interface	Kong Manager is the web interface, and Konnect is the cloud control plane for managing gateways across environments.	Managed through Kubernetes Gateway API resources, with a standalone deployment mode outside Kubernetes for non-cluster use.
Deployment outside Kubernetes	Traditional, DB-less and hybrid self-managed topologies are documented. Confirm which mode fits your plugin needs.	Standalone deployment mode is documented. Confirm air-gapped install steps with the project before you commit.

What is open source and what is paid in each platform

Kong's open-source gateway is the Apache-2.0 licensed Kong/kong repository, and its releases stay on the 3.9 line. The most recent open-source release in the supplied facts is 3.9.4, released October 12, 2026, following 3.9.3 on June 17, 2026. Newer feature releases are not published on that line. Kong's version support policy places the newest release, Kong Gateway (Enterprise) 3.16, under Enterprise distribution, so the open-source line and the commercial line now diverge in version number.

Apache-2.0 repository: The Kong/kong code is open source, and the README covers routing, load balancing, health checking, JWT, basic auth, OAuth, ACL, a Kubernetes ingress controller and plugins written in Lua, Go or JavaScript.
3.9 release line: 3.9.4 (October 12, 2026) is the latest open-source release in the supplied facts, and 3.9.3 came before it on June 17, 2026.
Support window: 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, so plan the next upgrade before that date.
Enterprise releases: Kong Gateway (Enterprise) 3.16 was released September 15, 2026, and 3.10 and 3.14 are LTS releases supported until March 31, 2028 and April 7, 2029.
Enterprise-tier plugins: The OpenID Connect plugin is marked Enterprise tier, so OIDC is not part of the open-source gateway.

Confirm with Kong which edition, release line and support terms apply to your deployment before you commit to the open-source path.

How OIDC login works at each gateway and what it costs to get it

Kong's OpenID Connect plugin is an Enterprise-tier item, so a team that runs only the open-source Kong Gateway line cannot use it for browser or API login through OIDC. Kong's plugin documentation marks the plugin as Enterprise tier, and the open-source gateway on the 3.9 line does not include it. If OIDC is a requirement, the decision is between two paths: move to a licensed Kong Gateway Enterprise edition and budget for that license, or plan a different login path, such as an identity-aware proxy or an authentication service in front of the gateway, and confirm it meets your session and token handling rules. Confirm the current licensing terms with Kong directly before you finalize either path.

Envoy Gateway documents OIDC alongside JWT, API key, basic and external authorization, so the open-source project is a candidate for OIDC login without a separate paid tier. The licensing consequence is that the project is Apache-2.0 licensed, so there is no per-edition license to buy for the feature. The cost sits in configuration, testing and operations, and that work is yours or your implementation partner's. Treat the documentation as the starting point, not as proof that your flow works. Test the full redirect, token exchange, session and logout path against your own identity provider, and confirm which OIDC settings are supported for the Envoy Gateway version you deploy, using the Envoy Gateway documentation as the reference for that version.

Do not assume feature parity between the two gateways. Kong offers a plugin model with its own configuration and support boundaries, while Envoy Gateway expresses the same need through Gateway API resources and policies. Ask each vendor or project for a written statement of the OIDC configurations it supports, the identity providers it has been tested with, and the upgrade path for those settings. Put the outcome of a proof-of-concept against your identity provider into the scope document so the effort and the licensing decision are both grounded in tested behavior.

Moving API traffic from Kong to Envoy Gateway or back

This sequence lets a team move routes and policies between Kong and Envoy Gateway with both gateways carrying traffic at once, so each route can be checked before Kong is retired. It works in either direction, but the rebuild effort falls mainly on plugins and identity policies.

Inventory Kong plugins and configuration
The platform or gateway team exports the current Kong configuration, including services, routes, consumers, certificates, upstreams and every plugin with its scope (global, service, route or consumer). Each plugin is recorded with its owner, the routes it protects and whether it is Enterprise-only, such as OpenID Connect. Confirm which Kong edition and version runs in production, because the open-source Kong Gateway line stays on 3.9 while newer releases ship as Kong Gateway Enterprise. The step is done when every route has a written list of the policies that apply to it and nothing is left as an undocumented default.
Map each policy to a Gateway API or Envoy extension
The team maps every inventoried item to a target construct: Gateway API resources for routing, TLS and header rules, and Envoy Gateway's built-in security features for API key, basic, JWT and OIDC authentication, external authorization, mutual TLS, IP allow and deny lists, CORS and rate limiting. Anything without a direct match goes to an extension path, such as Wasm, Lua, external processing or an extension server, each of which needs its own review. Mark each mapping as direct, partial or rebuild. The output is a mapping table that a security reviewer and a platform engineer have both signed off on.
Replace Enterprise-only OIDC with a tested alternative
Kong's OpenID Connect plugin is an Enterprise-tier plugin, so teams on the open-source line cannot carry it over unchanged. The security engineer selects the Envoy Gateway OIDC configuration or another approved pattern, then tests token validation, redirect handling, session behavior and failure modes against the same identity provider settings used today. Confirm licensing terms with Kong and the identity provider before relying on any Enterprise feature in the target design. The step closes when a test suite shows the same accept and deny outcomes for representative users, including expired and malformed tokens.
Rebuild custom plugins and Kong-specific policies
Plugins written in Lua, Go or JavaScript do not move as-is. A developer rewrites each one for the Envoy Gateway extension model, or replaces it with a standard policy where one exists, and records the behavior each replacement preserves and changes. Kong-specific policies, such as rate limits tied to Kong consumers or data stored in the Kong database, need a documented equivalent or a decision to retire them. The output is a rebuilt set of extensions with unit tests and a change record that names every behavior difference for the owners of affected APIs.
Stand up Envoy Gateway beside Kong
The platform team installs Envoy Gateway in the target environment, using the install path the organization already supports (Helm, Argo CD or Flux CD, or a standalone deployment mode outside Kubernetes), and checks the compatibility matrix against the Envoy Proxy and Kubernetes versions in use. Where the environment is air-gapped, the team follows the project's air-gapped guide and confirms the image and chart sources are mirrored. Kong keeps serving production traffic during this step. The step is done when Envoy Gateway passes health checks and both gateways run side by side with separate hostnames or test listeners.
Run both gateways in parallel and compare
Traffic is mirrored or split so the same requests reach Kong and Envoy Gateway, and the team compares status codes, latency, authentication decisions, rate limit behavior and logs for each route. Certificates and identity provider configuration are reused where the target supports them, so the comparison isolates gateway behavior rather than credential differences. Each route receives a sign-off from its API owner. The step closes when every route in the inventory has a recorded parity result and every known difference has an accepted owner decision.
Shift routes, then retire Kong
Routes move in small groups, starting with low-risk APIs and ending with the most sensitive ones, with a tested rollback to Kong for each group. After the last route runs on Envoy Gateway and the rollback window agreed in writing has closed, the team removes Kong, its database or hybrid control plane, and its credentials, then archives the final configuration export. Ingress resources are migrated where present, because Ingress NGINX received only best-effort maintenance until March 2026 and no further releases after that. The step is done when Kong no longer receives traffic and the archive is stored with the change record.

Where Kong and Envoy Gateway implementation projects usually run long

Most of the schedule risk in a Kong or Envoy Gateway project sits in identity integration testing, not in the initial install. Kong's OpenID Connect plugin is an Enterprise-tier plugin, so a team that expects OIDC on the open source 3.9 line will find the gap late. On the Envoy side, the documentation covers OIDC alongside API key, basic and JWT authentication, but the policy objects must be attached to the right Gateway API routes and tested against your actual identity provider's token claims, redirect URIs and session behavior. Plan a test matrix per route class (public, machine-to-machine, interactive user) and confirm with the vendor and your identity team which claim mappings and token lifetimes are in scope before you commit to a date.

The second source of overrun is plugin and filter rewrites. Kong plugins are written in Lua, Go or JavaScript, and any custom logic you have built on those plugins has to be re-expressed for Envoy Gateway, which offers Wasm extensions, Lua extensions, dynamic modules, external processing and an extension server instead. Each option has different build, packaging and debugging costs, and the choice is an architectural decision for your platform team, not a porting task for a contractor. Inventory every custom plugin, record its data dependencies, and decide early which ones are worth rebuilding and which can be replaced by a standard policy. Gateway API conformance differences between the two stacks also cause rework: confirm the resource fields you rely on are supported in the Envoy Gateway release you intend to run, and check the compatibility matrix against your Envoy Proxy and Kubernetes versions.

Air-gapped installs and GitOps pipelines are the third area to budget for, and the client's team owns most of it. Envoy Gateway publishes guides for air-gapped environments and installation with Helm, Argo CD or Flux CD, but mirroring images, charts and dependencies into your registry, and reconciling them with your change-control process, is work you must plan and staff. Decide whether the gateway runs in Kubernetes or in standalone mode, which pipeline owns the Gateway API resources, and who approves changes to policy objects. Ask DeployOpen or any implementer to state in the written scope which of these steps they perform, which your team performs, and what evidence is delivered at handover.

Questions buyers ask before choosing Kong or Envoy Gateway

Can Envoy Gateway replace Kong's OpenID Connect plugin?

Partly, and the answer depends on your identity setup. Envoy Gateway's documentation covers OIDC authentication alongside API key, basic and JWT authentication, external authorization, mutual TLS and rate limiting, so the capability is documented in the project itself. Kong's OpenID Connect plugin is an Enterprise tier plugin and is not part of the open source gateway. What you must confirm is how your identity provider's flows, token claims and session handling map onto Envoy Gateway's policy resources, and whether the behavior matches what your applications expect today. Test that against your own identity provider before you commit.

What does the migration effort from Kong to Envoy Gateway depend on?

The effort depends on how much of your Kong configuration relies on Kong-specific plugins and on how your routes are defined. The main drivers are the number of Kong plugins in use, whether any of them have no direct Envoy Gateway equivalent, how much custom Lua, Go or JavaScript plugin code you maintain, and whether your traffic policies live in declarative files, the Admin API or a control plane. Teams that run Kong on Kubernetes with Gateway API resources will usually have less translation work than teams using Kong's database-backed Admin API. Inventory your plugins and routes first, then compare each one against Envoy Gateway's documented features.

Is Kong's open source 3.9 line still supported?

Support for the 3.9 line is time-limited. According to Kong's version support policy, Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, and that policy applies to Kong Gateway Enterprise. The open source Kong/kong repository is Apache-2.0 licensed and its releases stay on the 3.9 line, with 3.9.4 released on October 12, 2026. Confirm with Kong which support commitments apply to your deployment, and plan an upgrade path well before the sunset date if you rely on the 3.9 line.

How long does a switch from Kong to Envoy Gateway take?

No duration can be stated reliably from the information available here, so treat any figure you are given with caution. The timeline is driven by the number of routes and services, the count and complexity of plugins that need replacing, how many teams and applications depend on the gateway, your change windows, and how thoroughly you test authentication and rate limiting before cutover. Running both gateways in parallel during a staged cutover usually adds planning work but reduces risk. Ask any implementation partner for a timeline built from a written inventory of your environment, with the assumptions listed.

Can our team run Kong or Envoy Gateway without outside help?

Your team can run either gateway in-house if it already operates Kubernetes or NGINX-based infrastructure, has someone comfortable with declarative configuration and has capacity for upgrades and security reviews. Kong documents traditional, DB-less and hybrid self-managed topologies, each with different operational needs, such as a PostgreSQL database in traditional mode. Envoy Gateway is installed with Helm, Argo CD or Flux CD and supports standalone deployment outside Kubernetes. Be honest about who will own upgrades, certificate rotation, plugin or extension maintenance and incident response, because those recurring tasks decide whether in-house operation stays manageable.

What does a fixed-scope implementation need from our side?

DeployOpen's engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. To write that scope, DeployOpen needs an inventory of your current gateway configuration, including routes, plugins, authentication methods and upstream services, plus the target topology and deployment platform. It also needs named contacts for identity, networking and application owners, access to the environments where the work will run, and your decisions on acceptance criteria. A quote follows from that written scope, so the more complete the inventory, the more precise the quote. Ask for the assumptions and exclusions to be written out as well.

Which questions should we ask before we accept a quote?

Ask what is in scope, what is excluded, and who performs each task. Confirm which Kong edition and support window the work assumes, and whether the plan covers the Envoy Gateway features your authentication and authorization model needs, including OIDC. Ask how the plan handles rollback, parallel running and testing of rate limits and access controls. Finally, ask what ongoing support is included after handover and what would be offered as a separate retainer for upgrades and continuous testing. Any figure in the quote should trace back to a line item in the written scope.

Four risks to check before committing to either gateway

Kong and Envoy Gateway fail in different places, so the risks below are not interchangeable. Each one turns on a licensing, lifecycle or skills question that is easy to defer and expensive to unwind once routes, plugins and policies are in production.

OIDC sits in the Enterprise tier

Kong's OpenID Connect plugin is an Enterprise-tier plugin, so it is not part of the open-source gateway. If your design relies on OIDC at the gateway, the open-source Kong line will not meet that need on its own. Envoy Gateway documents OIDC authentication alongside JWT and API key options, which changes the cost comparison. Confirm with Kong which edition and subscription terms apply to your planned OIDC use, and confirm the Envoy Gateway OIDC behavior against your identity provider in a test cluster before you decide.

Support window on the 3.9 line

The open-source Kong/kong releases stay on the 3.9 line, and Kong's support policy applies to Kong Gateway Enterprise. Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026. If you choose the open-source line, plan an upgrade path before that sunset date and ask Kong what support, if any, covers 3.9 after it. Teams that need a longer window should compare the LTS releases with their own upgrade calendar.

Kubernetes and Gateway API skills

Envoy Gateway is built around Gateway API resources, and it provisions and configures the Envoy proxies it manages. Teams without Kubernetes operations experience or Gateway API knowledge will carry a learning curve that Kong's Admin API and Kong Manager do not impose in the same way. Envoy Gateway also supports standalone operation outside Kubernetes, so check whether that mode fits your estate. Assess your platform team's skills and run a pilot of your core routes before committing.

Rebuilding plugins during a switch

Kong plugins are written in Lua, Go or JavaScript, while Envoy Gateway extends through Wasm extensions, Lua extensions, dynamic modules, external processing and an extension server. A move in either direction means reimplementing custom policies, rate limits and authentication flows in a different model, then retesting them under load and in your audit evidence. Inventory every plugin and its dependencies, map each to a native feature or an extension path, and get a quote that covers that rework before you sign.

How DeployOpen evaluates the choice in your environment

DeployOpen plans, implements, hardens and documents self-hosted gateways inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. Most engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before any work starts. For a Kong versus Envoy Gateway decision, that means the evaluation is tied to your traffic patterns, your Kubernetes platform and your control requirements, not to a generic feature checklist. DeployOpen can run a proof of concept against both platforms in the same environment, and it does not favor either one.

A useful proof of concept tests the points where the two products actually differ. On the Kong side, that means deciding between traditional, DB-less and hybrid topologies and confirming which plugins your policies need, including OpenID Connect, which is an Enterprise-tier plugin in Kong's documentation. On the Envoy Gateway side, it means checking how your required authentication, external authorization and rate limiting map onto Gateway API resources, and whether a Wasm or Lua extension or an external processing service covers any custom logic. Ask each vendor, in writing, which of your requirements are built in, which need an extension and which need a commercial license, and have the proof of concept verify those answers rather than accept them.

Set the evaluation criteria before the proof of concept starts and record the results against them. Confirm the release line you would run and its support window directly with Kong, using Kong's version support policy, and confirm the Envoy Gateway release and Envoy Proxy compatibility you would pin using the project's compatibility matrix. Include operations in the test: how configuration is delivered through Helm, Argo CD or Flux CD, how changes are rolled back, and who on your team owns each component. The written scope from a proof of concept also becomes the starting point for any production implementation, so agree on its deliverables and exit criteria up front.

How DeployOpen helps you choose, implement or migrate your API gateway

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Kong vs Envoy Gateway, we start by mapping your Kubernetes traffic, authentication and extension needs to the platform that fits them, then carry the chosen gateway through to a documented, supported running system.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
Scope covers which API routes, authentication methods and plugins or extensions each gateway must handle.
We confirm whether OIDC is needed and whether it requires a Kong Enterprise license or Envoy Gateway configuration.

How we build

We deploy the selected gateway in your environment, choosing traditional, DB-less or hybrid Kong topology, or Envoy Gateway on Kubernetes.
We build Gateway API resources or Kong plugin configuration, including custom Lua, Go or JavaScript plugins where needed.
We run security testing against the gateway configuration, authentication flows and exposed endpoints before handover.

How we hand over

You receive documented configuration, deployment runbooks and upgrade notes tied to the versions in scope.
Deliverables include a written record of authentication, mutual TLS, rate limiting and external authorization settings.
We walk your platform and security teams through operation, monitoring and the rollback steps they will use.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades when your chosen gateway's release line or support window changes.
Ask any proposal to confirm which vendor support, license tier and support windows are included in its scope.

Kong vs Envoy Gateway