Kong Support Options: Kong Inc., Open Source or Independent

Kong support comes from Kong Inc. for Kong Gateway Enterprise and Kong Konnect customers, from the community for open-source Kong Gateway, and from independent providers for versions outside Kong's support window and for the API gateway operations around the product. Kong's standard support window is one year per version, which catches many teams out.

How long Kong supports a version

Under Kong's Kong Gateway Enterprise version support policy, every minor version is supported for one year from its release date. Long-term support (LTS) versions are supported for three years. Since March 2025 Kong ships four minor versions a year, in March, June, September and December, and the first release of the year becomes the LTS. After full support ends there is a sunset period of up to 12 months in which Kong gives limited support to help the customer upgrade to a supported version.

At the time of writing that makes 3.10 LTS supported to 31 March 2028 and 3.14 LTS to 7 April 2029, with the standard versions 3.12 to 3.16 each on a one-year clock. If you are not on an LTS line, you are upgrading every year to stay supported.

LTS is not new. Kong Gateway Enterprise 2.8 was the first LTS version, and Kong supported it up to 25 March 2025, so any estate still on 2.8 is now past full support. Within a supported version, bug fixes and security fixes arrive as patch releases, and Kong's policy limits which fixes are backported to older supported versions.

Kong Konnect changes the picture for the control plane. Konnect is Kong's hosted API platform, so Kong runs and updates the management layer, while the data plane gateways still run in your own infrastructure, usually on Kubernetes or virtual machines, and still need to stay on a supported version.

Open-source Kong Gateway

The enterprise policy does not cover the open-source gateway. Kong Gateway OSS is supported by the community through Kong Nation and GitHub. It runs a great deal of production API traffic with no support contract behind it. The question comes up often enough on Kong's GitHub discussions: the supported versions table applies to Kong Gateway Enterprise, and the community edition has no equivalent commitment or technical support.

Where independent Kong support fits

• Versions past the one-year window or in sunset, including Kong 2.x estates that never moved to 3.x.
• Open-source Kong Gateway in production.
• Operations: rate limiting that is inconsistent across nodes, 502s from upstream health checks, plugin ordering and custom Lua plugins that add latency, the PostgreSQL database behind a traditional deployment, DB-less and hybrid mode configuration drift, the Kubernetes ingress controller.
• Upgrades and migrations, including the 2.x to 3.x jump and moves to or from Konnect.
• The platform around the API gateway: the Kubernetes deployment, the load balancer, DNS and certificates, and the upstream APIs themselves, which is where an outage or a slow degradation usually turns out to live.

AceMQ provides 24/7 Kong support for Kong Gateway Enterprise and open-source Kong, with a 15-minute emergency SLA and named senior engineers. Examples: rate limiting consistency support and an upstream health check 502 remediation.

The Kong incidents that actually page people

• Rate limits that differ by node. With the local policy each gateway node counts on its own, so a limit of 100 becomes 100 per node. The cluster and Redis policies fix consistency and add a dependency, with their own latency and failure modes to design for.
• 502 and 503 responses from healthy upstreams. Active or passive health checks mark targets unhealthy because of a timeout that is too tight or a health endpoint that returns the wrong status. Kong then sends traffic nowhere. The upstream health API shows the state. Knowing why it got there is the work.
• Latency added by plugins. A logging plugin that blocks on a slow collector, a custom Lua plugin that makes a network call per request, or plugin ordering that runs expensive work before cheap rejection. Kong reports its own latency separately from upstream latency, which is where to start.
• The database behind a traditional deployment. PostgreSQL connection limits, slow migrations during an upgrade, or a failover that every Kong node notices at once. DB-less and hybrid modes remove the database from the data path and bring configuration drift problems of their own.
• Declarative config drift. Changes made through the Admin API or Kong Manager in an emergency are overwritten by the next decK sync, or the reverse. The fix is process as much as tooling.

Upgrading from Kong 2.x to 3.x

Kong 2.8 LTS is past full support, so this is the upgrade most older estates face. Kong 3.0 changed the router, and route paths that relied on the old regex behaviour need a prefix to be treated as regular expressions. Several plugins changed their defaults or schema, some deprecated fields and the old Nginx template overrides were removed, and custom plugins need testing against the new plugin development kit. With a database-backed deployment the supported approach is a blue-green upgrade with migrations run in two phases so that old and new nodes can run side by side. Export the configuration with decK first, and validate it against the new version before any production node is touched.