Apache APISIX vs Kong: which to choose

Apache APISIX vs Kong: when each one fits the shortlist

A platform team that must self-host an API gateway and also needs OpenID Connect or other enterprise features should settle early which license tier those features require. APISIX fits when the team wants OIDC inside its Apache-2.0 distribution, because the openid-connect plugin works with providers such as Keycloak, Okta and Microsoft Entra ID and supports authorization code, client credentials, token introspection and PKCE flows. Teams comfortable running etcd, or content to keep configuration in a file in standalone mode, will find the configuration model straightforward to automate. Confirm that your identity provider and flow appear in the openid-connect plugin documentation before committing.

Kong fits when the estate already runs Kong, when the organization wants vendor-backed support for Kong Gateway Enterprise, or when it plans to manage gateways through Konnect, Kong's cloud control plane. It also suits a team already fluent in the Admin API on port 8001, since runbooks, scripts and tooling carry over. Kong's OpenID Connect plugin is an Enterprise tier plugin, so OIDC on Kong requires an Enterprise subscription. Ask Kong to confirm in writing which Enterprise components, support terms and Konnect features your use case depends on, because those are the items that drive the commercial comparison.

Three checks settle most shortlists. First, identify the license tier your required features need: if OIDC, enterprise support or Konnect is mandatory, price Kong Gateway Enterprise against APISIX's Apache-2.0 plugin set and get written confirmation of what each tier includes. Second, pick the Kong line. The open source repository stays on 3.9, where 3.9.4 was released on October 12, 2026 and sunset support ends December 12, 2026. Kong Gateway Enterprise 3.16 is listed as the latest version, released September 15, 2026, and 3.10 and 3.14 are LTS releases supported until March 31, 2028 and April 7, 2029. Third, decide the configuration store. APISIX traditional and decoupled modes depend on etcd, while Kong traditional mode depends on a database such as PostgreSQL, and DB-less or hybrid topologies change that picture again. Confirm your team can operate the chosen store before you choose.

Which gateway fits each scenario, and why

This table matches common team situations to the gateway that fits them better, with the condition that makes each choice hold. Read each row as a starting question: if the condition describes your environment, the named gateway is the stronger starting point, and the confirm column lists what to verify before you commit.

Scenario	Better fit and condition	Confirm before deciding
Kubernetes-first platform team	Kong, if the team wants a hybrid topology with a separate control plane and data plane and the Kong Kubernetes ingress controller already in its tooling. APISIX fits when the team accepts a separate ingress controller (APISIX Ingress Controller 2.2.0, released August 18, 2026) and wants etcd-backed configuration.	Which ingress controller version and Gateway API resources your cluster needs, and whether your platform tooling already targets one of them.
Regulated bank needing OIDC without an enterprise license	APISIX, because the openid-connect plugin ships under Apache-2.0 and supports authorization code, client credentials, token introspection and PKCE flows with identity providers such as Keycloak, Okta and Microsoft Entra ID. Kong's OpenID Connect plugin is an Enterprise tier plugin and is not part of the open source gateway.	Whether your bank's security and audit teams accept the Apache-2.0 open source plugin set, and which identity provider flows your applications require.
Existing Kong estate	Kong, when plugins, Kong Manager, decK-style workflows and team skills already depend on Kong and you stay on the 3.9 open source line. Moving to APISIX makes sense only if the cost of rewriting plugins and policies is lower than the cost of staying on a line whose full support ended on December 12, 2025.	Whether you need Kong Gateway Enterprise features or newer releases, and the sunset support date of December 12, 2026 for Kong Gateway 3.9 in your planning.
Mixed-protocol workloads including MQTT and Dubbo	APISIX, because its repository lists MQTT, Dubbo, gRPC, WebSocket, HTTP/3 with QUIC and TCP/UDP proxying. Confirm that Kong's protocol and plugin coverage meets each workload before choosing Kong for these flows.	Protocol support for each service in your inventory, and whether the chosen version handles your traffic volumes in a load test.
Team that wants declarative Git-managed configuration	Kong, when DB-less mode with configuration held in memory fits the release process and the team wants a single declarative model. APISIX fits when the team wants file-driven standalone mode, which checks conf/apisix.yaml or conf/apisix.json every second and hot-reloads, or the Admin API with etcd.	How configuration changes are reviewed, rolled back and promoted across environments, and whether your GitOps tooling supports the chosen format.
Lua-based plugin development	APISIX, because custom plugins can be written in Lua or through plugin runners in Java, Go and Python. Kong's README describes plugins in Lua, Go or JavaScript, so the choice depends on which languages your engineers already maintain.	Plugin runner maturity for your chosen language and whether WebAssembly plugins, still experimental in APISIX, are needed.
Operations team that wants a database-backed control plane	Kong, in traditional mode where all nodes connect to a database, or hybrid mode, when your DBAs already run PostgreSQL highly available. APISIX fits when the team is comfortable operating an etcd cluster in traditional or decoupled mode.	Which datastore your operations team supports, and the backup, restore and failover procedures for it.

How APISIX and Kong are built and deployed

Both gateways run on NGINX with Lua, but they store configuration differently and ask different things of your operations team. The cards below cover each documented deployment mode and what each one means for the database or configuration store you will run, back up and upgrade.

APISIX traditional and decoupled modes

APISIX on NGINX and ngx_lua with LuaJIT keeps its configuration in etcd. In traditional mode, data plane and control plane run together on each node. In decoupled mode, they run as separate instances that share one etcd cluster. The etcd cluster becomes the component you must size, secure, back up and monitor, so ask your team who already operates etcd and how it is patched. Client traffic uses port 9080 and the Admin API uses port 9180 in traditional mode.

APISIX standalone with a file

In standalone mode APISIX drops etcd entirely and reads its routes and plugins from conf/apisix.yaml or conf/apisix.json. The file is checked for changes every second and reloaded without a restart, which suits GitOps pipelines that deliver configuration as files. The trade-off is that configuration changes arrive by file rather than through a live Admin API workflow, so confirm that your change process and rollback plan fit a file-based model before choosing it.

Kong traditional mode with a database

In traditional mode every Kong node connects to one shared database, which is PostgreSQL in the open source quick start. Configuration lives in that database, so the database becomes the component you must back up, replicate, upgrade and restore. Check your backup and point-in-time recovery tooling, your PostgreSQL expertise, and the upgrade sequence for Kong and its schema before you commit to this mode.

Kong DB-less mode

DB-less mode holds Kong's configuration in memory and loads it from a declarative file, so no database is required on the gateway nodes. This removes the database from the runtime path and simplifies scaling, but changes must go through the declarative file and redeployment rather than a database-backed workflow. Confirm that your team can manage the declarative configuration in version control and that your change approvals work with that flow.

Kong hybrid mode

Hybrid mode separates a control plane, which holds configuration in a database, from data planes that receive it and serve traffic. This lets you place gateways close to workloads in several networks while keeping one administrative point. The cost is a second tier to operate: the control plane database and the control-to-data plane connection both need monitoring and certificate management. Ask whether your network design allows those connections and who owns the certificates.

Operational consequence and quick start ports

APISIX asks you to run etcd, Kong asks you to run PostgreSQL unless you choose DB-less, and each choice sets your backup, upgrade and disaster recovery work. In the Kong quick start, the proxy uses port 8000, the Admin API uses port 8001 and Kong Manager uses port 8002. Map these ports to your firewall and ingress rules during evaluation, and confirm the recovery steps for your chosen store with each vendor's current documentation.

Side-by-side capabilities from supplied facts

This table sets Apache APISIX against Kong Gateway on the facts we could verify for a self-hosted deployment, with the open source and Enterprise boundary marked on each row. Read the rows that mention an edition first, because the open source Kong line and Kong Gateway Enterprise differ on OIDC and on which releases receive support.

Capability	Apache APISIX	Kong Gateway
License	Apache-2.0 for the gateway and all built-in plugins	Open source repository is Apache-2.0 and stays on the 3.9 line; newer releases ship as Kong Gateway Enterprise
Configuration storage	etcd in traditional and decoupled modes; no etcd in standalone mode (file or API)	PostgreSQL in traditional mode; in-memory in DB-less mode; hybrid mode with separate control and data planes
Deployment modes	Traditional, decoupled and standalone	Traditional, DB-less and hybrid
Plugin coverage	More than 100 built-in plugins covering authentication, security, traffic control, observability and AI gateway functions	Routing, load balancing, health checking and authentication built in; plugin count and tier split to confirm in Kong's plugin catalog
Authentication plugins	JWT, basic auth, OAuth and ACL available; openid-connect plugin supports Keycloak, Auth0, Entra ID, Google and Okta	JWT, basic auth, OAuth and ACL available in open source; OpenID Connect plugin is Enterprise tier only
Custom plugin languages	Lua; Java, Go and Python through external plugin runners; WebAssembly (experimental)	Lua, Go and JavaScript
Protocol support	HTTP, HTTPS, HTTP/3 with QUIC, gRPC, WebSocket, MQTT, Dubbo and TCP/UDP proxying	Confirm protocol matrix for your version in Kong's gateway documentation
Kubernetes ingress	APISIX Ingress Controller, released separately (2.2.0 on August 18, 2026)	Kubernetes ingress controller included in the project README; confirm supported versions and Gateway API behavior with Kong
Admin UI	Admin API for configuration; confirm dashboard options with the APISIX project	Kong Manager web interface; Konnect cloud control plane for multi-environment management
AI or MCP gateway features	AI gateway functions are listed among plugin categories; confirm specific AI plugins for your version	LLM and MCP gateway features listed in the project README; confirm tier for each feature
Commercial tier boundary	No commercial tier is named in the supplied facts for the gateway itself; confirm any vendor support terms directly	OpenID Connect plugin and newer releases sit in Kong Gateway Enterprise; Kong 3.16 is the latest Enterprise release

What is free in each gateway and what is paid for

Apache APISIX is a top-level Apache Software Foundation project released under the Apache License 2.0. The gateway's plugins live in the open repository, so the plugin set you evaluate is the same set you deploy, without a separate edition for authentication or traffic control. The project is built on NGINX and etcd, and its documentation describes more than 100 built-in plugins. The APISIX downloads page does not mark any release as long-term support, so the support window you can plan around depends on the release cadence and your own upgrade policy.

License scope: The Apache-2.0 license applies to the gateway and its listed plugins in the open repository.
Plugin coverage: Authentication, security, traffic control, observability and AI gateway plugins are documented in the open project.
Identity integration: The openid-connect plugin supports flows such as authorization code, client credentials, token introspection and PKCE, with providers such as Keycloak and Microsoft Entra ID.
Support windows: The downloads page does not mark LTS releases, so ask whether any vendor or partner commits to a support window for the version you pick.
Paid components: Commercial support, managed services and vendor products built on APISIX, such as API7 Enterprise, are separate purchases from the open project.

Confirm which APISIX features your team needs are in the open repository and which, if any, your chosen support provider charges for.

Where OIDC login sits in APISIX and in Kong

The APISIX openid-connect plugin is in the open tier, so a self-hosted APISIX deployment can put OIDC login in front of routes without a commercial license. The plugin works with identity providers including Keycloak, Auth0, Microsoft Entra ID, Google and Okta, and supports the authorization code, client credentials, token introspection and PKCE flows. That covers a browser-based sign-in for internal tools and a machine-to-machine token check for services. The decision to make is which flow matches each route: authorization code and PKCE for user-facing applications, client credentials for service callers, and introspection where you need the gateway to ask the identity provider whether a token is still active. Confirm the exact plugin settings for your identity provider against the APISIX openid-connect plugin documentation before you write them into a route.

In Kong, the OpenID Connect plugin is classified as an Enterprise tier plugin in Kong's plugin documentation, so it is not part of the open source gateway. An open source Kong deployment therefore needs a different method to authenticate callers. The options Kong's open source README describes are JWT, basic auth, OAuth and ACL authentication, each of which validates credentials or tokens differently and none of which is a full browser login flow equivalent to OIDC. Keep the open source path only when your callers are services or API clients that can present a token or credential your team issues and rotates, or when an external service in front of Kong handles the login. Otherwise, budget for a Kong Enterprise subscription, and ask the vendor to confirm which Enterprise version and plugin set includes OIDC for your edition.

Before you choose, verify three things with your identity provider and security team: which OIDC flows your provider supports for each client type, how token lifetimes and revocation work when a session ends, and whether your policy accepts gateway-side token introspection or requires local JWT validation. Also confirm who owns client secrets and redirect URIs, and how they are rotated. If your security team requires an audited login path or vendor support for the authentication layer, weigh that against the open tier of APISIX, where support comes from your own team or a partner, and the Enterprise path in Kong, where the subscription is the support channel.

What drives the running cost of each gateway

Running either gateway costs more than its license line. The cards below separate the infrastructure, skills, upgrade cadence, support and edition choices that shape the bill, and name what to request in a quote so the two options can be compared on the same basis.

Configuration store and infrastructure

APISIX in traditional or decoupled mode needs an etcd cluster that you size, back up and monitor, while Kong needs PostgreSQL in traditional mode or runs without a database in DB-less mode. Standalone APISIX avoids etcd entirely. Ask who provisions and patches the store, whether backups and restore tests are in scope, and how many data plane nodes the quote assumes for your peak traffic. These costs recur monthly in cloud spend and staff time.

Data plane nodes and topology

Each gateway node consumes compute, and hybrid Kong or decoupled APISIX add control plane components that run continuously. Kong's hybrid mode separates control and data planes, so it adds at least one more tier to size. Cost rises with the number of environments, regions and high availability replicas. Ask the implementer to state node counts, instance classes and the topology assumed in the written scope, and whether the quote covers sizing tests.

Skills for custom plugins and operations

Custom APISIX plugins are written in Lua inside worker processes or in external plugin runners, so the team needs NGINX and Lua knowledge to maintain them. Kong operations depend on the Admin API, declarative configuration and, for hybrid mode, control plane experience. Skill gaps are usually paid as one-time training or consulting, then as recurring effort on every change. Ask whether the quote includes knowledge transfer and documented runbooks for your staff.

Upgrades and release windows

Kong's open source repository stays on the 3.9 line, and Kong Gateway 3.9 reaches end of sunset support on December 12, 2026, so an upgrade decision falls inside a short window. Kong Enterprise LTS releases carry published support dates, while APISIX minor releases are not marked long-term support. Each upgrade is a recurring cost in test time and change control. Ask who runs upgrades, how many per year the quote covers and whether regression testing is included.

Support options and who answers

Community channels for both projects cost staff time but no license fee. Kong Enterprise includes vendor support under its subscription, while APISIX support is available through commercial providers that you would contract separately. Confirm response targets in writing, since no SLA figures are supplied here, and confirm who escalates a production incident. Ask each vendor for the support tier, named contacts and the price basis, which is typically per year or per node.

Editions and Konnect fees

Kong's OpenID Connect plugin is an Enterprise feature, and Kong Konnect is the cloud control plane for managing gateways across environments. Those components add recurring subscription cost and can change which deployment models are practical. APISIX's documented plugin set is under Apache-2.0, so the paid elements are usually support or services. Ask for a line-item quote separating the license, Konnect or control plane fees, support tier and implementation services, and state the term and renewal rules.

Moving a gateway estate from Kong to APISIX, or back

The sequence below moves live API traffic between the two gateways without a single cutover event, and ends with a documented inventory of what was carried over, what was rebuilt and what was retired.

Inventory routes, plugins and consumers
The platform team exports every Kong service, route, upstream, plugin attachment, consumer and certificate, whether from the Admin API or from the declarative configuration file used in DB-less or hybrid mode. Each object is tagged by API owner, traffic volume and whether it is public, partner or internal. The step is done when the inventory reconciles against the live Kong instance, so no route or consumer exists only in someone's memory or in a Kong Manager session.
Map each Kong plugin to APISIX
For every plugin attachment, the team records whether an APISIX built-in plugin covers the same behavior, which configuration keys change and where behavior differs in ordering, defaults or error responses. Kong plugins that are Enterprise-only, such as the OpenID Connect plugin, are flagged separately because their replacement is a design decision. Any gap is assigned to a custom plugin, written in Lua or run through an external plugin runner, with an owner. The output is a signed mapping table that security and API owners both review.
Choose the APISIX deployment mode
The architecture lead selects traditional, decoupled or standalone mode based on how many clusters exist, whether a shared etcd cluster is acceptable and whether configuration will live in Git. Standalone mode reads conf/apisix.yaml or conf/apisix.json and hot-reloads on change, which suits teams that want file-driven, GitOps-style configuration; traditional and decoupled modes depend on etcd. The decision is recorded with the failure domains it creates, and it is done when the target topology is drawn and reviewed against the Kong topology it replaces.
Rebuild authentication on the target
Identity is rebuilt before any traffic moves. Each identity provider configuration is re-created on APISIX, and the openid-connect plugin is configured for the flows in use, such as authorization code, client credentials or token introspection. Consumers, JWT keys, API keys and ACL groups are migrated with their secrets handled through the team's existing secrets process rather than copied in plain text. Done means every protected route passes a test token, a rejected token and a revoked token in a non-production environment, with results attached to the change record.
Rebuild observability and Kubernetes resources
Monitoring hooks, log shipping, dashboards and alerts are re-pointed to the APISIX metrics and logs, and Kubernetes resources such as ingress definitions or controller configuration are rewritten for the APISIX Ingress Controller if the estate runs on Kubernetes. Teams confirm which Kong-specific metric names and alert rules no longer match and update them. The step closes when alerts fire correctly on a deliberate test fault and the on-call runbook names the new components.
Run both gateways behind a traffic split
Both gateways serve production traffic at the same time behind a load balancer or DNS weighting that the operations team controls. Traffic shifts in small, reversible steps per API, starting with low-risk internal routes. Error rates, latency, authentication failures and upstream health are compared between the two paths at each step. The step is complete when every API has served its full production load through APISIX with error rates inside thresholds the owners agreed in advance.
Cut over and retire Kong
Once every route is stable on APISIX, the traffic split is set to APISIX only and the Kong data plane is drained. The Kong Admin API is disabled, the Kong database is backed up under the retention policy and then decommissioned, and certificates and secrets that are no longer needed are revoked. Plan the timing against Kong's version support dates: Kong Gateway 3.9 reaches end of sunset support on December 12, 2026, so any fallback path that depends on 3.9 has a fixed end date. Done means the old Kong endpoints return no traffic and the decommission record is signed.

Where a gateway implementation usually runs long

The longest stretches in an APISIX or Kong rollout are rarely the gateway install itself. Effort concentrates in four places: choosing and hardening the topology, building the identity integration, porting custom plugins, and writing the backup and upgrade runbooks. For APISIX, hardening means deciding between traditional, decoupled and standalone modes, then protecting the Admin API on port 9180 and the client listener on port 9080 so the management plane never sits on a public network. For Kong, it means choosing traditional, DB-less or hybrid mode, then protecting the Admin API on port 8001 and Kong Manager on port 8002 in the same way. Effort depends on scope, including how many environments, clusters and identity providers are involved, so treat any duration as something to confirm in the written scope, not something to assume from this page.

The delays that recur most often are predictable. Identity provider approvals take longer than the technical work, especially when an APISIX openid-connect setup or a Kong OIDC plugin needs client registrations, redirect URIs and token policies signed off by the identity team. Plugin parity gaps surface late: a team may assume a Lua plugin, a Kong Go or JavaScript plugin, or an APISIX external plugin runner covers a policy it actually needs, and discover the gap only in testing. Sizing decisions also slip. Choosing etcd for APISIX or PostgreSQL for Kong without a load test forces a rework once route counts and plugin chains grow. Finally, edition questions often arrive after design is signed off. If OIDC, Kong Manager features or Konnect are required, ask Kong early which edition covers them, because the open source Kong line on 3.9 does not include the Enterprise OIDC plugin.

Ask any implementation partner, DeployOpen included, for a written scope that names the topology, identity provider, plugins to be ported, Kubernetes ingress approach, observability stack, and the backup and upgrade runbooks to be delivered. Ask which items are fixed scope and which are retainers for ongoing upgrades and testing. Ask for a list of assumptions, such as who provides the etcd or PostgreSQL platform and who approves identity changes. Those answers will show more about likely effort than any general estimate, and they give you a basis for comparing the two platforms on the same terms.

Questions buyers ask before choosing or switching

Does OIDC need Kong Enterprise, or can open source Kong do it?

In Kong's plugin documentation, the OpenID Connect plugin is marked as an Enterprise tier plugin, so it is not part of the open source gateway. If OIDC login at the gateway is a requirement, the Kong Enterprise license is the path to confirm. Apache APISIX ships its openid-connect plugin under Apache-2.0, and the APISIX documentation lists support for identity providers such as Keycloak, Auth0, Microsoft Entra ID, Google and Okta, with authorization code, client credentials, token introspection and PKCE flows. Confirm with Kong which edition, license term and support level your OIDC design needs, and confirm with your identity provider that the flows you plan are supported on both sides. See the Kong OpenID Connect plugin page for the tier details.

Can Apache APISIX run without etcd?

Yes. APISIX supports three documented deployment modes: traditional, where data and control plane run together and etcd holds configuration; decoupled, where separate data plane and control plane instances share one etcd cluster; and standalone, which has no etcd and loads configuration from a YAML or JSON file or an API. In file-driven standalone mode, APISIX checks conf/apisix.yaml or conf/apisix.json for changes every second and hot-reloads without a restart. Standalone suits GitOps workflows and fixed configurations, but it changes how you manage routes and secrets, so test your change process before you commit to it. Confirm the current caveats for each mode in the APISIX deployment modes documentation and with your platform team.

Which Kong line should we run after the 3.9 sunset?

Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, according to Kong's version support policy, which applies to Kong Gateway Enterprise. The open source Kong repository stays on the 3.9 line, with 3.9.4 released on October 12, 2026. Kong's policy lists Kong Gateway (Enterprise) 3.16 as the latest version, released September 15, 2026, and 3.10 and 3.14 as LTS releases supported until March 31, 2028 and April 7, 2029. The choice depends on whether you need Enterprise features and how long you need patches. Confirm with Kong which line matches your support window, upgrade path and licensing before the sunset date.

How long does a gateway implementation take, and what drives it?

No supplied fact gives a duration for a gateway implementation, so the answer depends on scope. The main drivers are the number of routes and upstream services, the authentication model, how many environments and clusters you run, the deployment mode, and whether you must migrate existing policies from another gateway. Integration with your identity provider, logging, certificate management and CI/CD pipelines usually adds more work than the gateway install itself. Most DeployOpen engagements are fixed-scope, so the timeline is set in writing from the agreed scope before work starts. Ask each option for a written list of deliverables and a dependency plan, and ask DeployOpen to show how it sizes your scope.

What does the work need from our own team?

Expect your team to provide access, decisions and knowledge that only your organization holds. Typical inputs are a list of upstream services and their owners, identity provider settings and claim mappings, network and DNS details, certificate authorities, logging and monitoring endpoints, and approvals for change windows. For APISIX, someone must own the etcd cluster in traditional and decoupled modes or the configuration files in standalone mode. For Kong, someone must own the database in traditional mode or the control and data plane setup in hybrid mode. Name these owners before scoping, because gaps there delay most projects more than the software does.

Can an internal team run either gateway alone after go-live?

It can, if the team has operations skills for NGINX-based gateways, the chosen data store and a Kubernetes or VM platform. Both gateways are built on NGINX and Lua, and both expose administrative APIs, so the skills overlap. Each adds its own operating load: APISIX asks you to run etcd for most topologies, while Kong asks you to run PostgreSQL in traditional mode, or a hybrid control plane. Plugin development in Lua is required for custom logic on both, though the extension languages differ. Assess your team against those specific components, and ask DeployOpen whether a retainer for upgrades, testing and support fits your plan.

How do the Kubernetes ingress options differ?

Both projects offer a Kubernetes path, but the components differ. APISIX has a separate APISIX Ingress Controller, and the downloads page lists version 2.2.0, released on August 18, 2026. Kong's README describes a Kubernetes ingress controller, and Kong's deployment topologies include hybrid mode with separate control and data planes. Check which controller and Gateway API support you need, how each handles your existing ingress resources, and whether your clusters need the decoupled or hybrid layout. Confirm feature parity for your specific resources with each vendor before choosing, since ingress controller behavior changes between releases.

What should we ask for in a quote?

Ask for a written scope that lists the gateways, environments, clusters, routes or services in scope, the identity provider integrations, the migration of any existing policies, and the testing and documentation deliverables. Ask which licenses are required, including any Kong Enterprise edition needed for OIDC, and who buys them. Ask for the fixed timeline, the acceptance criteria, the handover plan and what is one-time versus recurring, such as upgrades, patches and support. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for assumptions in writing so you can compare options on the same basis.

How DeployOpen helps choose, implement or migrate a gateway

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 Apache APISIX vs Kong, we start by writing down which gateway fits your traffic, identity and deployment model, then carry that decision through to a running, documented system.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We confirm which APISIX or Kong edition, deployment topology and identity provider your team has chosen before any build begins.
The written scope lists which plugins, routes, Kubernetes ingress paths and license features are in and out of the work.

How we build

We install and configure the chosen gateway in your environment, using either etcd-based or database-backed configuration as scoped.
We wire authentication, rate limiting and routing to your identity provider and upstream services, then test each path.
We run security testing on the gateway and its APIs, and record findings with fixes agreed in the scope.

How we hand over

We deliver configuration, runbooks, backup and upgrade procedures, and architecture notes written for your operations team.
We prepare the controls and evidence your compliance assessors may request, without issuing any audit report or certification.
We walk your engineers through day-two operations so the team can run and change the gateway without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainer scope covers the version and support dates of your chosen gateway, so upgrades follow the vendor timeline you confirmed.
Ask for a quote built from the written scope, since DeployOpen does not publish a price list.

Apache APISIX vs Kong