Kong Konnect cost vs self-hosted Kong Gateway OSS or APISIX

Which cost components change when you leave Konnect

This table sets each Konnect cost component against the self-run Kong Gateway OSS or APISIX equivalent and marks whether it is one-time or recurring. Use it to build a quote request, because the commercial side is priced by Kong's plan and metering terms while the self-hosted side is paid through your compute, staff and support contracts. The main takeaway is that the open-source license fee drops out, but compute, operations and upgrade work move onto your own budget.

What moves the comparison most

Six drivers decide whether Konnect or a self-run gateway costs less for your organization. Each one shifts spending between Kong's metered fees and your own infrastructure, engineering and support time, so check them against your own traffic and roadmap before you compare quotes.

Why the open-source edition changes the license line

How to build the comparison with your own numbers

This sequence turns your current Konnect contract and traffic into a three-year, side-by-side view of what stays with Konnect and what a self-run Kong Gateway OSS or APISIX deployment would cost. Each step produces an input that the next one depends on.

1. Export the Konnect configuration as your baseline

   Start with the decK export of your Konnect control plane using the deck gateway dump command, which produces a declarative YAML or JSON file of services, routes, consumers and plugins. Your platform or API team runs it with access to each control plane in scope. Save the file in Git so it becomes the fixed inventory for every later step. You know this step is done when the file loads without errors and you can count each object type from it.

2. Pull your Konnect plan terms and usage

   Ask your Kong account team or procurement contact for the plan, the metered items it covers and the billing period, and export the usage reports from the Konnect console for the same period. Confirm how Kong meters gateway services, requests, developer portals and published APIs, because each has its own quantity in your contract. Record any add-ons, support tiers and renewal dates. The output is a single table of plan line items next to the usage quantity each one drives.

3. Count services, routes, consumers and portal APIs

   Using the decK file and the portal inventory, count the services, routes, consumers, plugin instances and published portal APIs. Group them by team or business domain, since migration effort usually follows ownership more than object count. Note which plugins depend on a database, because in traditional mode Kong's cluster-strategy rate limiting and OAuth2 need one, while DB-less mode does not support them. The output is a per-domain inventory that you can use for effort estimates.

4. Size peak traffic and gateway footprint

   Pull request rates for the busiest hour, day and month from your existing monitoring, not from averages alone. Divide the peaks by the number of gateway nodes you would need to keep headroom for failover and upgrades. Add the traffic patterns that matter for cost, such as long-lived WebSocket or gRPC connections and TLS termination load. Confirm with your own load tests that the chosen Kong Gateway OSS or APISIX node size handles these peaks. The output is a node count and size per environment.

5. Price compute, storage and network at your own rates

   Apply your cloud or data center rates to the node count from the previous step, including production, staging, disaster recovery and development environments. For self-run APISIX in decoupled or traditional mode, add the etcd cluster, and for Kong in traditional mode, add the database and its backups. Include load balancers, certificates, logging and metrics storage, and egress. Mark each line as one-time (setup, hardware, certificate purchase) or recurring (monthly infrastructure). The output is a monthly infrastructure figure from your own invoices.

6. Estimate migration effort per service group

   Assign effort to each domain from the inventory, based on the number of routes, the plugin complexity and how much authentication logic must be rebuilt. For APISIX, translation of Kong objects to routes, upstreams and plugins is a separate task from the cutover. Include portal migration, client credential rotation, testing and a parallel-run period. Ask an implementation partner for a written scope if your team lacks gateway experience. The output is an effort figure per domain that your engineers have reviewed.

7. Add ongoing support, upgrades and staff time

   Estimate the recurring engineering time for patching, upgrades, certificate renewal, on-call coverage and plugin maintenance. The open-source Kong Gateway edition is published on the 3.9 release line, and Kong's version support policy covers only Enterprise, so plan your own upgrade and security review cadence. Decide whether you will buy a support contract or retainer from a vendor or partner, and if so, request its price in writing. The output is an annual staff-hour figure and any support line item.

8. Build the three-year side-by-side view

   Place Konnect and the self-run option in one table with three yearly columns. Keep one-time costs (migration, setup, training) separate from recurring costs (subscription or infrastructure, staff time and support). Show your assumptions next to each number and test the sensitivity of the result to traffic growth and the migration timeline. Review the totals with finance and the platform owner. You know this step is done when every figure traces to a source document or a named assumption.

Costs teams forget on each side

The Konnect invoice shows the plan fee, but usage and add-ons drive much of the total over time. On the self-hosted side, the gateway itself is free, while the team carries the infrastructure, operations and security work that Kong's cloud previously absorbed. Each card below names one cost that is easy to miss, who pays for it, and what to check before comparing totals.

Which self-run path costs less to operate: Kong OSS or APISIX

Questions buyers ask before comparing Konnect with self-hosting

How a fixed-scope comparison and migration is scoped

The sequence turns the cost model into a written, fixed scope with agreed deliverables and confirmed timelines, so the quote reflects the work your environment actually needs before anything changes in production.

1. Confirm the current Konnect footprint

   Start by listing what you pay for in Konnect today: plan tier, metered gateway services and requests, developer portals, published APIs, Dedicated Cloud Gateways if used, and any Enterprise plugins. Ask your Kong account team or procurement contact for the current invoice line items and the metering definitions behind them. DeployOpen reviews this with you so the cost model uses your actual billing, not assumptions. Done when every billed component is named and mapped to an owner.

2. Inventory services, routes and plugins from decK exports

   Run decK's gateway dump against each Konnect control plane to produce declarative YAML or JSON files, then review them for services, routes, consumers, plugins and any Konnect-only features. DeployOpen counts the objects, flags plugins that need database-backed mode or have no open-source equivalent, and notes which portal, analytics or Enterprise functions would have to be replaced. Done when the inventory file set is versioned in your repository and the gap list is signed off by your team.

3. Size the self-run target architecture

   Choose the candidate target, either self-run Kong Gateway OSS in DB-less or traditional mode or Apache APISIX in traditional, decoupled or standalone mode, based on the inventory and your hosting constraints. The cost model then lists the infrastructure, load balancing, observability, identity, backup and operations components for that target. Confirm the Kong OSS line with the vendor, since the open-source edition stays on the 3.9 series. Done when the architecture diagram and component list are agreed.

4. Agree deliverables and assumptions in writing

   DeployOpen drafts the fixed-scope document: the in-scope environments, the deliverables (cost model, architecture, migration runbook, cutover plan, documentation and handover), the assumptions about your hosting and identity providers, and the items out of scope such as Konnect licensing negotiations. Your technical and procurement leads review and sign off the document before work begins. Done when both parties have approved the written scope.

5. Confirm timelines and dependencies before work starts

   Timelines are set only after the written scope is accepted. The plan lists dependencies that could move dates, such as access to Konnect exports, change windows, security review of the new gateway and availability of your platform team. Ask for the timeline in writing and check which milestones depend on your side. Done when the schedule is attached to the scope and the dependency owners are named.

6. Deliver the comparison and quote

   DeployOpen delivers the cost comparison by component: Konnect fees and metered usage on one side, and infrastructure, implementation, support and engineering time for the self-run option on the other. Each line shows what is one-time and what recurs, and what drives it up or down. DeployOpen does not publish prices, so a quote follows from this written scope and is issued separately. Done when you can compare the quote against your renewal terms line by line.

7. Retain support after handover if needed

   Once the self-run deployment is accepted, ongoing support, upgrades and testing can be covered by a retainer rather than a new fixed scope. Agree in advance what the retainer includes, such as patching the gateway, reviewing new open-source releases and maintaining declarative configuration in Git. Done when the retainer scope is either signed or your team has confirmed it will run the platform without external support.