Kong Gateway: what the Apache-2.0 API gateway actually installs and does

The problem Kong Gateway solves, and who ends up running it

Every service that faces the internet needs the same handful of things: routing, TLS termination, authentication, rate limiting and logging. Kong's answer is to put those in one layer that sits in front of everything, configured through a RESTful admin API or a declarative file rather than through per-service code. The README describes the project as a "cloud-native, platform-agnostic, scalable API 𖧹 LLM 𖧹 MCP Gateway" and lists proxying, routing, load balancing, health checking and authentication as its core jobs.

The audience is narrower than the tagline suggests. Kong suits platform teams that already run several backends and want one place to attach JWT validation, ACLs or OAuth, and teams that want to route LLM traffic across providers such as OpenAI, Anthropic, GCP Gemini, AWS Bedrock, Azure AI, Databricks, Mistral and Huggingface through a single API. It is a poor fit for a single service behind a single hostname, where the configuration surface costs more than it returns.

How Kong routes traffic: plugins, the admin API and the data plane

Kong is written in Lua and works as a proxy that executes a plugin chain on each request. The README states that plugins provide the advanced functionality, and that developers can build them in Lua, Go or JavaScript. That last point matters: Go and JavaScript plugins run as external processes rather than inside the Lua VM, so plugin language is also a deployment decision.

Configuration reaches the gateway by one of two paths. The first is the Admin API on port 8001, a RESTful interface that decK can drive, which means a database holds the routes, services and plugin config. The second is declarative configuration, which the README calls Declarative Databaseless Deployment; here the config file is the source of truth and there is no database to reconcile. The README also names Hybrid Deployment, a control plane and data plane split, as a supported model. Those three modes have different operational failure modes, and the README does not pick one for you.

Traffic itself arrives on port 8000 and is forwarded to your upstream. Kong Manager, the management web UI, is served on port 8002. Those three ports are the whole surface a first-time user touches.

Installing Kong with docker-compose and sending the first request

The README recommends the docker-compose distribution, and the steps are short. Clone the Docker repository and move into its compose folder:

git clone https://github.com/Kong/docker-kong
cd docker-kong/compose/

Then start the stack. The KONG_DATABASE variable selects the database-backed profile, and the README's command pairs it with the database profile flag:

KONG_DATABASE=postgres docker-compose --profile database up

After the containers come up, the Gateway is listening on localhost. Port 8000 carries service traffic, 8001 is the Admin API (and the port decK targets), and 8002 serves Kong Manager. The README points to a quick start guide for configuring a service, which is where you define an upstream and a route before any request can be proxied. If you would rather not run Postgres at all, the README links a separate Docker procedure for running the Gateway in DB-less mode.

The README does not document rollback for a failed upgrade, and it does not give a single command that both installs and configures a service. Expect to read the quick start guide before port 8000 returns anything useful.

Where Kong Gateway gets in the way

The database decision is the sharpest edge. Running with KONG_DATABASE=postgres means a Postgres instance is part of your critical path, and its availability is now a gateway concern. DB-less mode removes that dependency but moves the problem to configuration distribution: the config has to reach every node, and the README does not describe how that propagation is coordinated.

Upgrades are a second constraint. The repository carries an UPGRADE.md and a changelog directory, and the release history shows a gap: 3.9.3 and 3.9.2 landed in June 2026, while 3.9.1 is dated June 2025. Anyone tracking patch releases should read the changelog rather than assume a steady cadence. The README states that SemVer is followed, which tells you a patch release should not break config, but it says nothing about schema migrations between minor versions.

Plugin development is the third cost. Writing a plugin means Lua plus the Plugin Development Kit, and the README links a PDK reference rather than summarising it. Teams without Lua experience will find the external Go and JavaScript paths easier, at the price of running extra processes alongside the gateway.

Kong Gateway versus a plain reverse proxy

The obvious alternative is a general-purpose reverse proxy such as nginx or Envoy configured directly. The difference is where the logic lives. A plain proxy gives you routing rules in a config file and expects you to add auth, rate limiting and logging yourself, often as separate sidecars or modules. Kong ships those as plugins with a defined execution order and a shared configuration store.

That trade runs both ways. A plain proxy has no database, no plugin runtime and no admin API to secure, so it starts faster and has fewer moving parts. Kong is the better choice when the number of services and the number of cross-cutting policies both grow, because the plugin chain is configured once instead of per service. For a single backend with a single certificate, Kong adds a Postgres dependency and a plugin model to solve a problem that a few nginx location blocks already solve.

Licence, release cadence and what an upgrade costs

Kong is licensed under Apache-2.0, which permits commercial use and modification. The README also promotes Kong Konnect, a cloud-hosted offering, and an AI Gateway product, so the open source repository and the commercial products share a name and a documentation site. Nothing in the repository requires you to buy anything, but some documentation links land on commercial pages, and the AI Gateway documentation is hosted separately from the main docs. Check which edition a given feature belongs to before designing around it.

The upgrade cost is mostly the database schema if you run Postgres, plus plugin compatibility. The repository ships UPGRADE.md, a CHANGELOG.md and a changelog directory, and the README directs readers to the changelog for release details. There is no documented automated migration command in the repository's own instructions, so treat an upgrade as a staged operation with a rollback plan you build yourself.

Editorial conclusion

Adopt Kong if you need routing, auth and rate limiting in one layer, and you accept a Postgres-backed control plane or a declarative config file as the price. Skip it if a single upstream needs a reverse proxy and nothing else, because the plugin and database model is more machinery than that job requires. Verify first that your chosen distribution is on the official install page, that you know whether you are running with KONG_DATABASE=postgres or DB-less, and that your team can write or review Lua before committing to a custom plugin.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes