Your security scanner has been yelling at you. Your compliance team has been forwarding the reports. Your platform engineers have been patching OS-level vulnerabilities in Kong's base image that never touched Kong itself.
These are the common challenges faced by enterprise customers, especially those in regulated sectors like government, finance, and healthcare, who face mounting pressure to adopt hardened, traceable software images that meet modern supply chain security standards.
[Kong Gateway 3.15](https://konghq.com/blog/product-releases/kong-api-gateway-3-15)Kong Gateway 3.15 fixes that.
Most container images ship with a full Linux distribution underneath the application — package managers, shells, system utilities, and hundreds of OS packages the application never actually uses. Those packages accumulate CVEs.
Distroless refers to a container image design pattern and packaging philosophy widely used in cloud-native systems. It focuses on minimizing the runtime environment by removing non-essential operating system components, leaving only what is strictly required to execute the application.
Its key characteristics include:
`apt`, `yum`, or `apk` are removed to prevent runtime modification of the system.Kong chose [_**Wolfi**_](https://github.com/wolfi-dev)_**Wolfi**_ as the foundation for building its distroless images.
**Why Wolfi?**
Of the available distroless approaches (Google, Wolfi), Kong selected Wolfi because it offers a unique combination of glibc compatibility, extensibility, and production-friendliness:
Kong builds Distroless image with Wolfi’s apko declarative build system. It uses a hybrid model: Declarative base system (apko) + controlled runtime compatibility layering.
**Declarative Base Layer (apko)**
Defined in apko.yaml, the base includes only what's required to run Kong - the glibc runtime, CA certificates, and core runtime libraries. There is no shell and no package manager.
**Runtime Compatibility Layer**
A controlled compatibility layer for compiled plugin dependencies, specifically aligned `libstdc++/libgcc` runtime libraries, are added at build time but not at runtime. This ensures ABI compatibility without adding packages that drift over time.
**Permissions and Runtime Initialization**
All file system permissions, user mappings, and runtime directory structures are pre-configured at build time, consistent with existing Kong operational behavior.
The key difference from traditional images: nothing is installed at runtime. The container is immutable once deployed.
Starting with Kong Gateway 3.15, the distroless image variant is available alongside the standard image. Pull it the same way you pull any Kong image, using the distroless-tagged variant.
# Standard image (existing behavior)
docker pull kong/kong-gateway:3.15.0.0
# Distroless image (new in 3.15)
docker pull kong/kong-gateway:3.15.0.0-distrolessThe distroless image is a drop-in replacement for standard Kong Gateway deployments. Configuration, plugins, and operational procedures are unchanged.
AI is not just producing different answers. It is starting to do different kinds of work. JEV introduces a different model for using AI: instead of generating text, it returns typed, probabilistic decisions that software can act on directly. By ret
When an AI application fails, knowing that an individual model call returned a 200 isn’t enough. You need to know what led to it. Kong stitches the interactions associated with an AI session together, giving developers a view across the sequence of
Consider a bank using an AI agent to investigate potentially fraudulent transactions. A transaction is processed and the bank’s fraud detection system identifies suspicious activity. That event is published to Kafka: fraud.suspected The bank’s Fraud
Most AI cost management starts with infrastructure. A provider can tell you that you consumed a certain number of input and output tokens on a particular model. An observability platform can show requests, latency, tokens, and traces. A cloud cost p
Traditional applications generally have well-defined boundaries. They interact with a known set of services using credentials provisioned specifically for those connections. Agents are different. Their value comes from their ability to work across s
