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:

• - **No package manager**: Tools such as `apt`, `yum`, or `apk` are removed to prevent runtime modification of the system.
• - **Minimal runtime utilities**: Production variants typically exclude shells and common debugging tools to reduce attack surface.
• - **Reduced system surface area**: Only runtime libraries required by the application are included.
• - **Immutable runtime model**: The image is intended to be fully assembled at build time, without runtime installation capabilities.

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:

• - **Glibc Compatible:** Wolfi uses the same core system library Kong is built on, ensuring that Kong and its plugins run unchanged.
• - **Extensible:** The image is composed of small, individual packages, allowing us to include exactly what is required rather than inheriting a full operating system.
• - **Production Friendly:** Wolfi strikes a balance between extreme minimalism and operational utility, retaining essential Linux semantics that SRE teams rely on for observability and health checks while minimizing the attack surface.

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.

• - **Significantly Fewer CVEs — **By removing OS packages your workload never uses, the baseline CVE count drops substantially. Fewer findings means fewer false positives to triage, fewer tickets to close, and faster security reviews.
• - **Smaller Attack Surface — **A post-compromise attacker inside a traditional container has a full toolkit: package managers to download tools, shells to run commands, curl to exfiltrate data. In a distroless container, that toolkit is gone. Post-compromise capability is severely limited.
• - **Compatible With Your Existing Workflows — **Kong's full functionality is unchanged — routing, TLS termination, authentication, rate limiting, plugins, the Admin API, and /status metrics all behave exactly as they do today. Your logging integrations and observability tooling continue to work, because Kong emits the same logs and metrics. The one difference: because there's no shell, *docker exec … sh* style interactive debugging isn't available in the distroless image. For those cases, attach an ephemeral debug container or run the standard image.

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-distroless

The distroless image is a drop-in replacement for standard Kong Gateway deployments. Configuration, plugins, and operational procedures are unchanged.