Kong vs WSO2 API Manager: which to choose

Kong vs WSO2 API Manager: which fits your API program

Choose Kong Gateway's open-source edition when your need is runtime traffic control: routing, load balancing, health checks and authentication enforced at the proxy, with your own team owning the API catalog, onboarding and consumer processes. Choose WSO2 API Manager when you must publish, secure and govern APIs for internal or partner consumers as a managed program, with a publisher, a developer portal, subscriptions and throttling tiers. Both can sit in the same estate, so the question is less which product is better and more which set of lifecycle controls your program must enforce from day one.

The decision turns on three questions. First, whether lifecycle features are required: if partners must self-register, request subscriptions, and receive throttling tiers tied to those subscriptions, a gateway alone leaves you building that workflow yourself. Second, whether your team can accept the support window on Kong's open-source line. The Kong/kong releases stay on the 3.9 line, and Kong's version support policy lists Kong Gateway 3.9 as past full support with sunset support ending December 12, 2026, so confirm with Kong and your own risk owners how you will patch and who answers for it. Third, whether one control plane must manage mixed gateways, because WSO2 states that its control plane can manage third-party gateways including Kong.

Before you commit, run a short proof of concept against your real consumer onboarding flow, not a demo route. Ask WSO2 to confirm which features each subscription level includes and what it costs, and ask Kong to confirm which plugins your policies need that sit in the Enterprise tier, such as OpenID Connect. Document the answers as a written requirement list, since changing the gateway or the management layer later means rebuilding policies, consumer credentials and portal content. WSO2 API Manager is the natural next read on the management side.

Which platform fits which API program

This table maps common API program scenarios to the platform that fits each one better, and names the condition that makes it so. Read each row for the condition first, since the same team size can point to different answers depending on whether it needs a portal, lifecycle tooling or a fixed supported version. Where the other option is still acceptable, the row says so.

Scenario	Better fit	Condition that drives the choice
A small set of services behind one gateway	Kong Gateway	A few routes, plugins and a single operations team are enough. Kong's open-source line covers routing, health checks and key-based auth. WSO2 is still acceptable if you expect the API catalog to grow into a managed lifecycle soon.
Multi-team developer portal with subscriptions	WSO2 API Manager	WSO2 includes a Publisher and Developer Portal for API lifecycle and subscriptions. Kong's open-source edition does not bundle an equivalent portal, so Kong Manager and Konnect serve operations rather than consumer onboarding. Kong is acceptable if portal needs can be met by a separate tool.
Kubernetes-only ingress	Kong Gateway	If the need is ingress controller behavior inside Kubernetes, Kong's Kubernetes ingress controller is the more direct path. Confirm which Kubernetes integration and Gateway API features your target version supports. WSO2 is acceptable if you also need publisher workflows and the separate WSO2 API Platform for Kubernetes fits your governance model.
Mixed Kong and cloud gateways under one governance model	WSO2 API Manager	WSO2 states that one control plane can manage WSO2 gateways and third-party gateways including Kong, AWS, Azure and Envoy. This matters when several gateways must share policy and catalog. Confirm the exact feature set for each third-party gateway before relying on it. Kong alone is acceptable if Konnect or a single Kong control plane is the agreed governance point.
Commercial support on a fixed version	WSO2 API Manager	WSO2 sells commercial subscriptions that provide expert support, continuous product updates and vulnerability monitoring. Kong's open-source 3.9 line is due to reach end of sunset support on December 12, 2026, so a team that must stay on a supported line will need to plan an Enterprise path. Confirm the subscription terms and support windows with each vendor.
Open-source only, no commercial subscription budget	Kong Gateway	Kong's Apache-2.0 repository offers routing and core auth, but the support gap on the 3.9 line is a planning risk. WSO2 is acceptable if you can run its Apache-2.0 components without a subscription and accept self-maintained patching.
Platform team wanting DB-less or hybrid topologies	Kong Gateway	Kong documents traditional, DB-less and hybrid self-managed modes, which suit GitOps and separated control and data planes. WSO2 is acceptable if its gateway and control plane deployment model matches your infrastructure.

How Kong Gateway and WSO2 API Manager are built and deployed

Kong Gateway and WSO2 API Manager both run as self-hosted services, but they put different numbers of moving parts and different state stores in your environment. The cards below set out each deployment model, what it means for day-two operations, and what to confirm before you size either platform.

Kong traditional and database mode

In traditional mode every Kong node connects to a shared database, so the database holds the configuration and each node reads from it. That makes the PostgreSQL instance a critical dependency you must back up, patch and make highly available alongside the gateway nodes. Confirm how your team will run that database, who owns its upgrades, and how node count changes affect database connections. Kong's deployment topologies documentation sets out the mode in detail.

Kong DB-less and hybrid modes

DB-less mode keeps configuration in memory from declarative files, which removes the database from the runtime path but moves change control into your Git and CI/CD pipeline. Hybrid mode splits control plane nodes, which connect to the database, from data plane nodes, which do not. Choose hybrid when you need central administration across sites and DB-less when configuration is managed entirely as code. Confirm which Enterprise-tier features your chosen mode depends on before committing.

Kong quick start components

The Kong open-source quick start runs Kong with PostgreSQL through Docker Compose, exposing port 8000 for proxy traffic, 8001 for the Admin API and 8002 for Kong Manager. That is a useful evaluation path, but it is not a production layout: it does not show high availability, backup, TLS termination or network segmentation. Treat it as a test bed and confirm each production control separately in your own environment.

WSO2 control plane, gateway and traffic manager

WSO2 API Manager is split into a control plane, a gateway for routing, mediation and security, and a traffic manager for throttling, plus the Publisher and Developer Portal web interfaces. Each of these is a separate runtime role you must size and monitor. Ask WSO2 or your architect how many nodes each role needs for your traffic profile and where shared configuration and analytics data are stored, since those answers drive the operating footprint.

WSO2 deployment options and the Kubernetes route

WSO2 supports on-premises installs from extracted packages, a hybrid model with a SaaS control plane and on-premises gateways, and a fully managed SaaS option that WSO2 describes with a 99.95% SLA. Kubernetes deployments use the separate WSO2 API Platform for Kubernetes. Confirm which deployment model fits your data residency rules, and check whether the Kubernetes route changes the component set you planned for the on-premises install.

JDK 21 build requirement and patch ownership

WSO2 API Manager 4.7.0, released April 29, 2026, requires JDK 21 to build from source. Your platform team must therefore provide and patch a JDK 21 toolchain for any custom build, plugin or extension work, in addition to the runtime. With Kong, the operating system and database patches fall to you, while WSO2 charges for support and patches on subscription tiers. Confirm who patches each layer and how often, and ask for the patch cadence in writing.

Why one control plane across Kong and WSO2 changes the architecture

The central question is whether you want a second control plane to govern your Kong gateways, and WSO2 says its API Platform can be that control plane. WSO2 states that one control plane can manage its own gateways alongside third-party gateways, including Kong, AWS, Azure and Envoy. For a team already running Kong, this would mean keeping Kong's data plane where it is while moving publishing, subscription, throttling policy and lifecycle decisions into WSO2's Publisher and traffic manager. Kong's own answer for multi-environment management is Kong Konnect, its cloud control plane, while Kong Manager is the web interface that ships with the gateway itself. Those two are different in kind: Kong Manager administers one Kong deployment, and Konnect governs Kong gateways from Kong's hosted service. Neither is a cross-vendor governance layer.

Mixed-gateway governance is worth the extra component only when several conditions hold. You run more than one gateway product, perhaps Kong in some clusters and a cloud-native gateway elsewhere, and you need one catalog of API products, one set of access rules and one audit trail. You also need that catalog to shape how teams publish and consume APIs, not just where traffic is routed. If all your APIs run through a single Kong estate and your main need is routing, plugins and authentication, a second control plane adds a database, upgrades, certificates and an extra failure domain to operate without solving a problem you have. Kong's Enterprise-tier features, such as OpenID Connect, may also be part of the picture, so compare what each control plane needs to see on the Kong side.

Before you rely on this architecture, confirm the scope of the Kong integration in writing with WSO2 and separately with Kong. Ask WSO2 which Kong versions and deployment topologies it supports, whether it reads Kong's configuration or only routes traffic through it, which policies it can enforce on Kong gateways, and whether throttling and analytics are complete for Kong traffic. Ask Kong which management interfaces it expects to remain authoritative, and whether running a third-party control plane affects support on your Kong subscription. Test a non-production Kong cluster with a representative API and a rate limit, then verify the policy takes effect and appears in both consoles. Plan for who owns each configuration change, because two control planes writing to one gateway is the most common source of drift.

Capabilities that separate the two platforms

This table sets Kong Gateway's open-source edition against WSO2 API Manager on the capabilities that decide fit: licensing, gateway scope, authentication, extensibility, API types and deployment. Read the Kong column with the 3.9 line and Enterprise tier in mind, and confirm WSO2 identity integration against your own identity provider before you rely on any row.

Capability	Kong Gateway (open source)	WSO2 API Manager
License	Apache-2.0 for the open-source Kong/kong repository, with releases on the 3.9 line	Apache-2.0 for API Manager; commercial subscriptions add support and updates
Gateway core	NGINX-based gateway for routing, load balancing and health checks	Gateway for routing, mediation and security, paired with a traffic manager for throttling
Authentication options	JWT, basic auth, OAuth and ACL in the open-source README; OpenID Connect is Enterprise-tier	Custom authenticators can be added; confirm the built-in options for your IdP
OpenID Connect	Enterprise-tier plugin, not part of the open-source gateway	Confirm integration with your specific identity provider before relying on it
Plugin model and languages	Plugins written in Lua, Go or JavaScript	Extensible with custom authenticators, policies and workflows
API types supported	Gateway proxying with plugins; API design artifacts are not a core open-source feature	REST, GraphQL and AsyncAPI APIs
Publisher and developer portal	Kong Manager web interface for the gateway; no open-source publisher or developer portal listed	Publisher and Developer Portal web interfaces included in the project
Traffic management	Routing, load balancing and health checking	Dedicated traffic manager for throttling
Kubernetes	Kubernetes ingress controller	Runs on Kubernetes through the separate WSO2 API Platform for Kubernetes
Multi-gateway control	Kong Konnect cloud control plane manages gateways across environments	One control plane can manage WSO2 gateways and third-party gateways including Kong
Deployment modes	Traditional (database), DB-less and hybrid self-managed topologies	On premises from packages, managed cloud, and hybrid with SaaS control plane and on-premises gateways

What is open source, what is licensed, and what is supported

Kong Gateway's open-source line is licensed under Apache-2.0 in the Kong/kong repository, and its releases stay on the 3.9 line. The most recent release in the supplied record is 3.9.4, released October 12, 2026. The open-source edition covers core gateway work such as routing, load balancing and health checking, plus several authentication methods, but it does not include Enterprise-tier plugins.

License: Apache-2.0 covers the gateway code in the repository, so your engineers can read, build and modify it without a license purchase.
Release line: Open-source releases remain on 3.9, so newer Kong Gateway versions do not arrive through this repository.
Authentication: The README lists JWT, basic auth, OAuth and ACL, which covers many API key and token patterns.
Excluded features: OpenID Connect is an Enterprise-tier plugin, so teams that need OIDC login flows must plan for an Enterprise license or another component.
Management interface: Kong Manager is the gateway's web interface. Confirm which Manager features you need and whether they are available on your 3.9.x build.

Before you commit, confirm which 3.9.x patch you will run, who will deliver fixes for it and how you will track security advisories.

What drives the running cost of each platform

Running cost for Kong and WSO2 API Manager comes from the infrastructure each topology needs, the skills your team must hold, and the support and upgrade work you choose to buy or carry yourself. The cards below separate those drivers so you can ask each vendor and DeployOpen for the same line items in a quote.

Database and node footprint

Kong's traditional mode needs every node connected to a shared database, while DB-less and hybrid modes change where that state lives. WSO2 API Manager runs as a control plane with a gateway and traffic manager, so its footprint depends on how many components you separate. Count the database instances, data plane nodes and control plane hosts for your target topology, including non-production and disaster recovery copies. Ask each vendor which components must run per environment and how they scale.

Control plane hosting

Kong offers Konnect as a hosted control plane, while open-source Kong manages gateways through its own Admin API and Kong Manager. WSO2 offers self-hosted, hybrid with a SaaS control plane and fully managed deployments. Each option moves operating effort and recurring fees differently. Ask whether a hosted control plane is billed per gateway, per API or per environment, and who patches and backs up the self-hosted parts.

Lua and plugin skills

Kong plugins are written in Lua, Go or JavaScript, so custom authentication, transformation or logging work needs engineers who can build, test and upgrade that code against each Kong release. Budget for the people who own that code after go-live, not only the initial build. Ask DeployOpen to state in the written scope which plugins it will build, how they are tested, and who maintains them after handover.

Java and JDK 21 skills

WSO2 API Manager requires JDK 21 to build from source, and its extensions for custom authenticators, policies and workflows are written against that platform. Teams without Java operations experience will need either internal hires or external support to patch the JVM, tune the runtime and review each upgrade. Confirm the JDK version each WSO2 release expects before you size the platform team.

Support subscriptions and unsupported lines

Kong's version support policy applies to Kong Gateway Enterprise, and Kong's open-source repository stays on the 3.9 line. WSO2 sells commercial subscriptions that include expert support, continuous product updates and vulnerability monitoring. Staying on an unsupported line can leave you carrying security fixes yourself, so ask each vendor which releases receive fixes, for how long, and what a subscription covers in writing.

Enterprise tier features and upgrades

Kong's OpenID Connect plugin is an Enterprise tier plugin, so an identity integration that depends on it adds a license cost to the open-source baseline. Each upgrade also carries testing and regression effort. Ask Kong which plugins your authentication design requires and whether they are Enterprise-only, and ask WSO2 which features sit behind its commercial subscriptions. Request a quote from each vendor and a fixed-scope estimate from DeployOpen that names upgrade testing, support hours and handover, because no price is published here.

Moving from Kong to WSO2 API Manager, or the reverse

This sequence turns an inventory of existing routes, plugins and consumers into a tested parallel run and a controlled cutover, so the team knows what moved, what was rebuilt and what still needs a decision before traffic changes hands.

Inventory routes, plugins and consumers
The platform owner exports the current gateway configuration from the source system, including services, routes, upstreams, plugins with their settings, consumers and credentials metadata. For Kong, this usually means reading the declarative configuration or Admin API output for the topology in use. Record which plugins are in use, which ones are Enterprise-tier, and which custom Lua, Go or JavaScript plugins exist. Done means every route and plugin has a row in a shared inventory with an owner and a target.
Map plugins to WSO2 policies and authenticators
The architect builds a mapping table from each Kong plugin to a WSO2 API Manager equivalent, such as a built-in policy, an authenticator, a throttling policy or a custom extension. Some plugins will not have a one-to-one match, and those need a decision: rebuild as a WSO2 extension, move the logic to a backend service, or drop it. Confirm each mapping against the WSO2 API Manager documentation for your release and against your own test results, not against names alone. Done means every row has a mapped target or a recorded decision signed off by the security owner.
Rebuild API definitions in the Publisher
The API owner imports or recreates each API in the WSO2 Publisher, supported by the OpenAPI, GraphQL or AsyncAPI definitions that already exist. Attach the mapped policies, resource-level settings and backend endpoints. Standard artifacts such as API specifications transfer, while the Publisher configuration, policy attachments and any gateway-specific tuning are rebuilt by hand. Done means each API is in a staging environment with a reviewed definition and a test suite that exercises every route.
Migrate identity configuration, certificates and subscriptions
The identity team moves the trust relationship between the gateway and the identity provider, which means reconfiguring issuers, audiences, JWKS endpoints and client registrations on the WSO2 side. TLS certificates and keys are re-issued or copied under your key management policy. Consumers are recreated as WSO2 applications and subscriptions, and client credentials are reissued through a controlled process rather than exported from the old system. Done means a test client can obtain a token, call a staged API and receive the expected response.
Rebuild the developer portal content
The developer relations or API product owner rebuilds the portal content in the WSO2 Developer Portal, including documentation, sample requests, onboarding pages and any terms of use. Portal content generally does not carry over from the source system, so plan for manual rewriting and review. Confirm the subscription workflow your organization needs, including any approval steps, against the WSO2 documentation for your edition. Done means each published API has reviewed documentation and a working sample request in staging.
Run both gateways in parallel
Operations deploys the WSO2 gateway alongside the existing Kong deployment and routes a controlled share of test or low-risk traffic to it, comparing responses, latency, error rates and logs from both. Throttling and rate limits are checked under realistic load in a non-production environment before any production shadowing. Monitoring and alerting cover both paths during this stage. Done means the comparison report shows matching behavior for agreed test cases and the rollback path has been exercised.
Cut over and decommission the source gateway
The change owner moves production traffic to the WSO2 gateway in agreed windows, one API group at a time, keeping the Kong route available for rollback until the monitoring period closes. Once traffic is stable and the rollback window ends, the Kong configuration, secrets and nodes are retired according to your retention rules. Confirm the retention and evidence requirements with your compliance team before deleting anything. Done means production traffic runs on WSO2, the change record is complete and the source system is decommissioned with its data handled as agreed.

Where Kong and WSO2 implementations usually run long

Kong implementations usually run long at the topology decision and at the plugin layer. Traditional mode puts every node on a shared database, DB-less mode holds declarative configuration in memory, and hybrid mode separates control plane nodes that sit on the database from data plane nodes that do not. Choosing among them early matters because plugins that need a database, CI/CD pipelines that push declarative files, and the hosted Konnect control plane all depend on that choice. Plugin work is the second source of effort. Custom plugins are written in Lua, Go or JavaScript, and automating routes, consumers and plugins through the Admin API adds scripting and test work that is easy to underestimate. Confirm which plugins your policies need, and whether any of them is an Enterprise-tier plugin such as OpenID Connect, before you commit to an open-source design.

The 3.9 support window adds a roadmap constraint that often surprises teams. Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026, so an open-source 3.9 deployment needs a dated plan for upgrades or a move to a supported line. Ask whether your roadmap has a budgeted upgrade window before the sunset date, and whether your internal change process can absorb a version move during the same period as the cutover. Kong's version support policy sets out the support windows for Enterprise releases and should be read alongside your vendor terms.

WSO2 implementations usually run long because the component set is larger and identity is central. A full API Manager deployment includes the control plane, gateway, traffic manager, Publisher and Developer Portal, and each needs sizing, hosting and upgrade planning. Identity provider integration is the most common delay point, since token issuance, scopes and role mapping must match the existing directory before any API goes live. Portal customization and custom authenticators, policies or workflows add build and review cycles. Policy mapping (translating existing rate limits, access rules and approval paths into WSO2 policies) and cutover approvals from security and change boards often take longer than the technical build. Ask your implementation partner to name each identity dependency and approval gate in the written scope.

Questions teams ask before choosing Kong or WSO2 API Manager

Is Kong open source still supported, and for how long?

Kong's open-source repository is Apache-2.0 licensed, but its releases stay on the 3.9 line, with 3.9.4 released on October 12, 2026. Kong's version support policy applies to Kong Gateway Enterprise, and it places Kong Gateway 3.9 past full support, with end of sunset support on December 12, 2026. Open-source users should not assume vendor support for this line beyond that date. Confirm with Kong what support, if any, covers the open-source edition you run, and plan an upgrade path to a supported Enterprise release such as 3.14 or 3.16 if you need one. Check the Kong releases page and the version support policy before setting a timeline.

Is WSO2 API Manager free to run in production?

WSO2 API Manager is licensed under Apache-2.0, so the open-source code can be downloaded and run without a license fee. Cost comes from the rest of the operating model: the infrastructure to host it, the staff who run and upgrade it, and any commercial subscription you choose. WSO2 sells subscriptions that include expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Ask WSO2 which of these your use case requires, whether a subscription is mandatory for your deployment, and how renewals are priced. Confirm all commercial terms directly with WSO2, because the repository describes subscription features but does not set prices.

What does a migration from Kong to WSO2 API Manager require from the team?

A migration needs an inventory of routes, consumers, authentication settings and plugins, then a mapping of each one to the target platform. Kong configuration lives in traditional, DB-less or hybrid topologies, so teams must document which mode they run and how configuration is deployed. WSO2 API Manager adds a publisher, developer portal and traffic manager, so existing consumers may need onboarding, subscriptions and throttling policies defined. Plan parallel running, rollback and a cutover window for each API. Because WSO2 can manage third-party gateways, including Kong, some teams may phase the change rather than replace the gateway at once. Confirm the plugin mapping and the Kong version you run before estimating effort.

Do I need a developer portal to start with WSO2 API Manager or Kong?

No. A developer portal is useful once you have external or partner consumers who need to discover, subscribe to and test APIs. Kong Gateway can run without a portal, managed through its Admin API and Kong Manager, and its quick start exposes Kong Manager on port 8002. WSO2 API Manager includes Developer Portal and Publisher web interfaces, so the portal is part of the product rather than a separate install. Teams with only internal services can start with the gateway and add the portal later. Teams publishing APIs to many consumers should scope the portal early, because it affects onboarding, documentation and access workflows.

How long does an implementation take, and what drives the effort?

Duration depends on the number of APIs, the authentication model, the number of environments and how much lifecycle management you need. A gateway-only deployment of Kong has fewer components than WSO2 API Manager, which runs a control plane, gateway, traffic manager and portal. Effort rises with custom plugins or authenticators, integrations with identity providers, high-availability design, CI/CD automation and the number of teams publishing APIs. DeployOpen plans and delivers implementations under a written, fixed scope, so the timeline comes from the agreed deliverables. Ask for a scope that lists each API, environment, integration and handover item before accepting a date.

Can our team run either platform without outside help?

A team with platform engineering skills can run either platform, but the required depth differs. Kong's gateway-first model is smaller to operate, especially in DB-less or hybrid mode, though plugin development and upgrades still need planning. WSO2 API Manager asks for more operational knowledge because it has more components, JDK 21 build requirements noted in its repository, and lifecycle workflows that need governance. Ongoing upgrades, security testing and 24-hour response needs are separate decisions. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so you can choose between in-house operation and a retainer based on your staffing and risk tolerance.

What should we ask a consultant before signing a scope?

Ask for the scope, deliverables and timeline in writing before work begins, since DeployOpen agrees these in advance for most engagements. Request a list of the platform versions and editions in scope, the topology to be built, the APIs and plugins to be migrated, and the security hardening and backup steps. Ask which items are out of scope, how upgrades after go-live are handled, and what documentation and evidence you receive. DeployOpen does not publish a price list, so ask for a quote that follows from the written scope. Confirm commercial terms of any vendor subscription with the vendor directly.

Which official sources to check before deciding

Start with the Kong version support policy, because it decides whether an open-source Kong line can carry a production commitment on its own. The policy lists Kong Gateway (Enterprise) 3.16 as the latest version, with 3.10 and 3.14 as LTS releases, and states that Kong Gateway 3.9 reached end of full support on December 12, 2025 and reaches end of sunset support on December 12, 2026. Read that alongside the open-source Kong/kong repository, whose releases stay on the 3.9 line (3.9.4 is the latest supplied release). Confirm with Kong, in writing, what security fixes, if any, will be issued to the open-source line after its support ends, and who will issue them. Also check the Kong deployment topologies documentation to confirm which of the traditional, DB-less and hybrid modes your architecture needs, because some features depend on the mode you choose.

Next, read the WSO2 API Manager repository and the WSO2 API Manager product page together. The repository confirms the Apache-2.0 license, the control plane, gateway, traffic manager, Publisher and Developer Portal, the JDK 21 build requirement, and the existence of commercial subscriptions. The product page describes self-hosted, hybrid and fully managed SaaS deployment and cites a 99.95% SLA for SaaS. Use the 4.7.0 release notes to confirm the version you would deploy and the upgrade notes that apply to it. Then take the questions the public sources cannot answer directly to WSO2: what a commercial subscription covers for your deployment model, whether the Kong gateway management through one control plane is supported at your Kong version, the exact SaaS SLA terms, service credits, and any support limits on the open-source distribution.

Finally, write the answers into your evaluation record with the date you checked each source, because the Kong and WSO2 release lines both move quickly. Ask both vendors for a written statement of supported versions, end-of-life dates and fix policy for the exact components in your design. Treat a verbal answer from a sales contact as unconfirmed until it appears in the contract or the support terms. Where a source is silent, record the gap as an open item with an owner, rather than assuming the capability exists.

How DeployOpen helps choose, implement or migrate an API platform

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 WSO2 API Manager, we start by agreeing which gateway topology, control plane and portal your team actually needs, then write that scope down before any work begins.

How we scope

Written scope names which Kong edition or WSO2 components are in and out of the engagement
Scope records the target deployment model: self-hosted, hybrid or Kubernetes, as your environment requires
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts

How we build

We implement the chosen gateway or API manager in your infrastructure, including routing, authentication and throttling policies
Custom authenticators, policies or plugins are built only where the written scope calls for them
Testing covers API and infrastructure security, and results are reviewed with your security team before sign-off

How we hand over

Deliverables include configuration, architecture documentation and runbooks for your operations staff
Backup, upgrade and rollback procedures are documented so your team can run the platform after handover
Compliance evidence is prepared for your independent auditors, since DeployOpen does not issue attestations

How we support

Ongoing support, version upgrades and continuous testing are available as retainers after handover
Retainer scope is agreed in writing, covering the release lines and support windows you confirm with the vendor
Quotes follow from the written scope, so ask for line items covering licensing, implementation and support

Kong vs WSO2 API Manager