Repository navigation
Published image layers are uncompressed #246
Description
Description
The published bitnami/minideb images have a single layer with media type application/vnd.oci.image.layer.v1.tar, so it is uncompressed. Gzipped, the layer is about 70% smaller, so every pull downloads roughly three times the bytes it needs to.
| Tag | Arch | Published (uncompressed) |
|---|---|---|
| bookworm | amd64 | 125.0 MB |
| bookworm | arm64 | 148.3 MB |
| trixie / latest | amd64 | 133.3 MB |
| trixie / latest | arm64 | 156.8 MB |
bookworm amd64 gzipped with gzip -9 is 39.2 MB.
Images built FROM bitnami/minideb inherit the uncompressed layer as-is, so the extra size carries into every derived image. The mix of one uncompressed layer with gzip layers on top also breaks some tools. For example, Trivy (through go-containerregistry) fails to scan such images from a local archive: google/go-containerregistry#2491.
Steps to reproduce the issue:
crane manifest --platform linux/amd64 bitnami/minideb:bookworm
Describe the results you received:
"layers": [
{
"mediaType": "application/vnd.oci.image.layer.v1.tar",
"size": 125009920,
...
}
]Describe the results you expected:
A gzip layer (application/vnd.oci.image.layer.v1.tar+gzip), like most images on Docker Hub.
Additional information you deem important (e.g. issue happens only occasionally):
Not intermittent. Every tag and architecture we checked (bookworm, trixie and latest; amd64 and arm64) was uncompressed on 10/29/2026, and our images built on bookworm show the same uncompressed layer back to at least August 2026.
Version
Not applicable. This is about the published registry images, not a local Docker setup.
Activity