Starting with [Kong CE 0.13](https://konghq.com/blog/kong-ce-0-13-0-released)Kong CE 0.13 and the upcoming EE 0.32, it is possible to separate control and data planes in a Kong cluster.
So what are those planes? The control plane is how we instrument the system (pushing configs, fetching logs), whereas the data plane is the traffic that is actually being proxied by the system.
Consider a factory. The factory has a conveyor belt, and on this belt the parts are added, the products assembled and finally packed and shipped. But to run this factory we need a lot more: logistics, work schedules, maintenance, quality reports, and what not. In this example the conveyor belt would be the data plane, where all the auxiliary stuff to enable the belt to deliver the products would be the control plane.
Kong works as a cluster of independent, stateless, nodes. All the Kong nodes in a given cluster are connected to the same database, from which the nodes get their configuration information. Up till now each Kong node would expose a port where it would serve traffic for the proxy (data plane), and another for configuration (the RESTful management API, the control plane).
With the new release we have refactored the way the ports are configured which allows for greater flexibility in infrastructure architecture and system control. This will enable the following uses:
This now opens up the possibility to proxy API traffic through Kong via one network segment, while administering Kong via a different network segment, which provides better isolation of the components, without risking accidentally opening up the Kong admin API to the whole internet.
To achieve this we removed the following (default) settings:
# Proxy
proxy_listen = 0.0.0.0:8000
proxy_listen_ssl = 0.0.0.0:8443
ssl = on
http2 = off
# Admin API
admin_listen = 127.0.0.1:8001
admin_listen_ssl = 127.0.0.1:8444
admin_ssl = on
admin_http2 = off
The format changed into a comma separated list of addresses with flags:
proxy_listen = [off] | <ip>:<port> [ssl] [http2] [proxy_protocol], ...
admin_listen = [off] | <ip>:<port> [ssl] [http2] [proxy_protocol], ... This format allows for multiple address/port combinations and flags to configure each of those. The new defaults, mimicking the exact same behavior of the old settings are:
proxy_listen = 0.0.0.0:8000, 0.0.0.0:8443 ssl
admin_listen = 127.0.0.1:8000, 127.0.0.1:8443 ssl
Given the new configuration properties we can now simply create a data-plane node by starting Kong with the `admin_listen` setting disabled:
$ KONG_ADMIN_LISTEN=off && kong start
Similarly for a control-plane node we can disable the `proxy_listen` setting:
$ KONG_PROXY_LISTEN=off && kong start
Stop me if you’ve heard this one before, but there’s a lot of data out there — and the amount is only growing. Estimates typically show persistent data growth roughly at a 20% annual compounded rate. Capturing, storing, analyzing, and actioning data
[](https://konghq.com/blog/engineering/decentralized-apis)
Imagine you have a single Service, order-api . You want to apply a strict rate limit to most traffic, but you want to bypass that limit—or apply a different one—if the request contains a specific X-App-Priority: High header. Previously, you had t
[](https://konghq.com/blog/engineering/conditional-policy-execution)
How OAuth 2.0 Token Exchange Reshapes Trust Between Services — and Why the API Gateway Is Exactly the Right Place to Enforce It Modern applications don’t run as a single monolithic. They are composed of services — frontend APIs, backend microservi
[](https://konghq.com/blog/engineering/token-exchange-at-the-gateway)
Traditional APIs are, in a word, predictable. You know what you're getting: Compute costs that don't surprise you Traffic patterns that behave themselves Clean, well-defined request and response cycles AI APIs, especially anything that runs on LLMs
[](https://konghq.com/blog/engineering/monetize-ai-apis)
Running Kong in front of your Solace Broker adds real benefits: Authentication & Access Control – protect your broker from unauthorized publishers. Validation & Transformation – enforce schemas, sanitize data, and map REST calls into event topics.
[](https://konghq.com/blog/engineering/smarter-event-driven-apis-kong-solace)
Architecture Overview A multicloud DCGW architecture typically contains three main layers. 1\. Konnect Control Plane The SaaS control plane manages configuration, plugins, and policies. All gateways connect securely to this layer. 2\. Dedicated C
[](https://konghq.com/blog/engineering/dedicated-cloud-gateways-managed-redis-multi-cloud)
The example below shows how an AI agent can be built using Volcano SDK with minimal code, while still interacting with backend services in a controlled way. The agent is created by first configuring an LLM, then defining an MCP (Model Context Prot
[](https://konghq.com/blog/engineering/secure-ai-agents-volcano-sdk-kong-mcp-proxy)