Kong API Gateway: What It Does and When to Use It

Kong is an open-source API gateway built on top of nginx (and, in newer versions, on its own high-performance core) that sits in front of your services to handle routing, authentication, rate limiting, and observability. If you're evaluating it, you're probably trying to decide between self-hosting Kong, paying for Kong Konnect (the managed cloud version), or using a different gateway entirely.

The short answer: Kong is a solid choice if you need a vendor-neutral, highly extensible gateway and you're comfortable running and operating infrastructure — or paying Kong Inc. to do it for you. It's overkill if you just need to expose one or two APIs with auth and rate limiting; for that, a lighter managed layer or even a well-configured reverse proxy will get you there faster.

What Kong Actually Does

At its core, Kong is a reverse proxy with a plugin system. Requests hit Kong first, Kong applies whatever plugins are configured (auth, logging, transformation, rate limiting), then forwards the request to the upstream service. The plugin architecture is the main reason people choose Kong over rolling their own nginx config — you get authentication schemes, request/response transformation, circuit breaking, and traffic control as configuration rather than code.

Kong ships in two main flavors:

• Kong Gateway (OSS/Enterprise) — self-hosted, deployed as Docker containers or on Kubernetes, configured via a declarative YAML file or a database (Postgres/Cassandra) plus an admin API.
• Kong Konnect — Kong's managed control plane. You still run data planes (the actual proxy instances) but the control, analytics, and developer portal are hosted by Kong.

There's also Kong Ingress Controller for Kubernetes, which lets you configure Kong using native Kubernetes CRDs instead of the standalone admin API.

Core Building Blocks

Understanding four concepts gets you most of the way to using Kong effectively:

• Services — represent an upstream API or microservice (a URL Kong forwards requests to).
• Routes — define how incoming requests are matched (by path, host, method) and mapped to a Service.
• Consumers — represent an API client/user, used for auth and per-consumer rate limits.
• Plugins — attach behavior (auth, rate limiting, logging, transformation) to Services, Routes, or globally.

A minimal declarative config looks like this:

_format_version: "3.0"
services:
  - name: orders-service
    url: http://orders.internal:8080
    routes:
      - name: orders-route
        paths:
          - /orders
    plugins:
      - name: rate-limiting
        config:
          minute: 100
          policy: local
      - name: key-auth

Load that with deck sync (Kong's declarative config tool) or via the admin API, and you have a routed, authenticated, rate-limited endpoint.

Deployment Options and Tradeoffs

Self-hosted OSS Kong is free and fully under your control, but you own everything: upgrades, database maintenance (if using DB-backed mode), scaling the data plane, and securing the admin API — which, if left exposed, gives full read/write access to your entire gateway config.

DB-less / declarative mode removes the Postgres dependency and works well with GitOps workflows — you version your kong.yml and deploy it like any other config. This is the recommended mode for most new setups.

Kong Konnect removes the operational burden of the control plane but you're paying for it, and pricing scales with usage tiers that aren't always transparent until you're deep in a sales conversation.

Kong Ingress Controller makes sense if you're already Kubernetes-native and want gateway config to live alongside your Deployment and Service manifests rather than in a separate system.

When Kong Is the Right Call

Kong makes sense when you have multiple backend services, need consistent auth and rate limiting across all of them, and want plugin-level control over transformations, logging, and traffic shaping — without being locked into a single cloud vendor's gateway (unlike AWS API Gateway or Azure API Management). It's also a reasonable choice if your team already runs Kubernetes and wants the ingress controller to double as the API gateway.

When It's Overkill

If your actual problem is narrower — for example, you have a single upstream (like an LLM provider) and you just need clean API keys, usage tracking, and streaming support for your team — standing up Kong, a Postgres instance, and plugin configuration is a lot of infrastructure for a small surface area. In that case a purpose-built layer is usually faster to ship.

This is the gap tools like SubToAPI fill for a specific use case: turning a Claude subscription into an HTTPS API with per-application sub_live_... keys, streaming, tool use, and usage metadata, without running a gateway at all. You get the key-management and observability piece that Kong would otherwise provide, scoped to one job, with a dashboard instead of YAML files. Check the pricing and quickstart if that's closer to what you need than a general-purpose gateway.

Getting Started With Kong

If Kong is genuinely the right fit, the fastest path is:

1. Run it in DB-less mode with Docker Compose to avoid the Postgres dependency initially.
2. Define one Service and Route in a kong.yml file and load it with deck sync.
3. Add key-auth or jwt plugin for authentication before exposing anything publicly.
4. Add rate-limiting scoped per Consumer, not globally, so one bad actor doesn't throttle everyone.
5. Only move to Konnect or a database-backed setup once you need multi-node consistency or a developer portal.

Most teams over-engineer step one by jumping straight to Kubernetes and Konnect before validating that Kong solves their actual routing and auth problem.

FAQs

Is Kong API Gateway free? The open-source version (Kong Gateway OSS) is free to self-host. Kong Enterprise and Kong Konnect (the managed cloud offering) are paid products with additional plugins, support, and a hosted control plane.

Kong vs Nginx: what's the difference? Nginx is a general-purpose web server and reverse proxy; Kong is built on top of nginx (or its own core in newer versions) and adds a plugin system, declarative configuration, and API-specific features like consumer management and rate limiting out of the box.

Do I need Kong for a small number of APIs? Usually not. Kong's value comes from managing many services and routes consistently. For one or two APIs, a lighter reverse proxy, your cloud provider's managed gateway, or a purpose-built API layer is often faster to set up and cheaper to run.