Kong Gateway (OSS) 2.4 has arrived with a release focused on two practical areas: broader plugin development options and a more flexible upgrade path for hybrid deployments. It also includes several platform and observability updates.
JavaScript plugin support enters beta
One of the biggest changes in 2.4 is the introduction of beta support for building Kong plugins with JavaScript. With JavaScript remaining one of the most widely used languages thanks to its large ecosystem of frameworks, libraries, and tooling, this opens Kong plugin development to a much broader group of developers.
The new JavaScript PDK gives developers a way to add custom logic at different stages of the request lifecycle. This capability is enabled through the Node.js runtime working alongside Kong Gateway. The goal is to make it easier to design new and more creative extensions without being limited to the existing plugin development path.
Kong also continues to maintain a plugin hub that includes plugins built both by Kong and by the wider community, giving developers a place to publish and share their work more broadly.
Logs can now be reshaped more freely
Another notable addition in 2.4 is a new approach to log formatting. Teams using Kong often need logs to fit the expectations of downstream systems for collection, indexing, and correlation, and getting logs into the right format usually requires extra transformation work elsewhere.
This release adds the ability to transform Kong Gateway logs into whatever structure is needed before they leave the gateway. Developers can now:
- remove fields
- create new fields with specific timestamps or unique IDs
- rearrange the log structure to match the requirements of a particular tool
By handling these transformations directly in Kong, organizations can reduce or eliminate the need for separate log-processing tools.
There is also support for dynamically modifying fields with Lua code during log formatting, which makes it possible to shape logs according to very specific administrative or operational requirements.
This feature is built on the kong.log.set_serialize_value PDK method and sandboxing capabilities introduced in Kong Gateway 2.3. It is supported by the following plugins:
- file-log
- Loggly
- Syslog
- tcp-log
- udp-log
- http-log
Hybrid mode compatibility is less restrictive
Hybrid mode, introduced in Kong Gateway 2.0, separates the control plane (CP) from the data plane (DP). One of its main advantages is simpler operations: administrators can manage and monitor the entire Kong cluster by interacting only with the control plane.
In 2.4, the version compatibility checks for hybrid deployments have been relaxed, giving administrators more room to upgrade on a schedule that is easier to manage and better tested.
The updated rules are:
- A DP can now connect to a CP that is up to two minor versions ahead.
- A DP connection is still rejected if any of the following is true: 1. the major versions do not match 2. the DP is newer than the CP 3. the CP is missing plugins
These safeguards remain in place to avoid backward-incompatible situations and other upgrade-related breakages.
Other changes in 2.4
Several additional updates are included in this release:
- Kong Gateway (OSS) 2.4 requires OpenResty 1.19.3.1. The bundled patch set has also changed, including the latest release of
lua-kong-nginx-module. Users installing Kong from the official distribution packages are not affected by this change. - A beta Protobuf-based plugin communication protocol is now available as an alternative to MessagePack for communication with non-Lua plugins. Developers using Go plugins should see performance improvements.
- The Zipkin plugin now supports Jaeger-style
uber-trace-idand OT header types, and it also allows custom tags to be added to Zipkin request tracing. - As part of routine maintenance, OpenSSL has been upgraded to 1.1.1k, Postgres 13 is now supported, and the minimum TLS version is v1.2.
The release also acknowledges contributions from community members, with special thanks given to @nvx, @pariviere, @ishg, @Asafb26, @WALL-E, and @jeremyjpj0916 for their pull requests.