When Bitnami moved its long-trusted catalog behind a paid tier, thousands of teams woke up to a supply-chain problem they didn’t choose. The free images they had pinned in production would stop getting updates, and the migration clock started that morning. QuenchWorks is my answer to that: a from-scratch, security-first catalog of container images and Helm charts, built entirely from source, hardened under a strict zero-CVE build gate, signed, and free. This is how it’s put together and why each decision earns its place.

The problem

The Bitnami catalog was popular for good reasons. It was broad, it was versioned, and it was maintained well enough that most teams never thought about it. Its weaknesses only became obvious once access changed: you didn’t control the build, you couldn’t prove what was inside a given image, and continued free access was never actually guaranteed.

That last point is the one that bites. When an upstream catalog changes its terms, every image: line you pinned becomes a liability at once. You either pay, fork, or scramble. And even before that day comes, an opaque image is its own quiet risk. If you can’t see how a layer was produced, you can’t reason about what a scanner finds inside it, and you can’t answer a security review with anything better than “we trust the vendor.”

Most hardened-image alternatives fix one slice of this and charge for the rest. I wanted the whole thing: a catalog broad enough to actually replace Bitnami for common workloads, provable rather than “trust us,” and free with no pull limits and no lock-in. If it couldn’t be all three, it wasn’t worth building.

Constraints

A handful of hard limits shaped every later decision.

• Zero fixable CVEs, enforced by the build. Not a nightly report someone reads later. A gate that fails the build so a vulnerable image never ships in the first place.
• Built from source. No repackaging of someone else’s opaque binary layers. If it’s in the image, we produced it.
• Provable. Every image needs a bill of materials and build provenance that a consumer can verify without trusting me.
• Free to run and maintain. The whole system builds on free CI, so cost can never be the reason it slips behind a paywall later.
• Multi-arch. amd64 and arm64, because production is both now, not one or the other.

Those constraints pull against each other. Zero fixable CVEs across 150+ images sounds impossible if you picture a fat base image. Building everything from source sounds slow. The architecture is what makes them coexist.

Architecture

The catalog is a pipeline, not a pile of Dockerfiles. Each image is declared as an apko plus melange spec, built from source on Wolfi, scanned against a zero-fixable-CVE gate, signed, and only then published pinned by digest. Charts sit on a shared library chart and reference those images by digest.

The single decision that makes the zero-CVE gate realistic is the base. QuenchWorks builds on Wolfi, a glibc Linux undistro designed for containers. Most images start with no shell, no package manager, and a tiny set of packages. There’s simply very little in the image that can be vulnerable, so keeping the gate green is a fight you can actually win instead of an endless race against a bloated base.

The image itself is assembled declaratively. melange builds signed APK packages from source, and apko composes those packages plus the Wolfi base into an OCI image with no Dockerfile involved. Because the whole thing is declared, the contents are known, reproducible, and easy to record as a bill of materials.

A catalog is never done, though, because CVEs are disclosed against packages long after an image ships. So the pipeline runs in reverse on a schedule. A nightly Trivy rescan checks every published image, and when a fix lands upstream the affected image rebuilds, re-enters the gate, gets re-signed, and republishes under a new digest. The catalog trends toward zero drift without anyone babysitting it.

Implementation

Each image is a pair of specs. melange describes how to build the package from source, and apko describes how to assemble the final image. Here’s the shape of both, trimmed for clarity.

1
package:
2
  name: my-app
3
  version: 1.2.3
4
environment:
5
  contents:
6
    packages:
7
      - build-base
8
pipeline:
9
  - uses: fetch
10
    with:
11
      uri: https://example.com/my-app-${{package.version}}.tar.gz
12
      expected-sha256: '...'
13
  - uses: autoconf/configure
14
  - uses: autoconf/make
15
  - uses: autoconf/make-install

1
contents:
2
  repositories:
3
    - https://packages.wolfi.dev/os
4
  packages:
5
    - my-app
6
    - ca-certificates-bundle
7
accounts:
8
  users:
9
    - username: nonroot
10
      uid: 65532
11
  run-as: 65532
12
archs:
13
  - x86_64
14
  - aarch64
15
entrypoint:
16
  command: /usr/bin/my-app

The gate is one Trivy call, and it’s deliberately strict about what counts. It only fails on CVEs that have a fix available, because a vulnerability with no upstream patch isn’t something a rebuild can clear. Everything fixable has to be at zero before the image is allowed out.

# Fail the build if any FIXABLE HIGH/CRITICAL vulnerability is present
trivy image --ignore-unfixed --severity HIGH,CRITICAL \
  --exit-code 1 ghcr.io/quenchworks/my-app:latest

Once an image passes, it gets signed and attested before it’s pushed for real. Signing is keyless with Cosign, so there’s no long-lived private key to leak, and the SBOM and SLSA provenance ride along as attestations.

On the delivery side, charts are the second half of the story. Every chart builds on a shared quench-common library chart, so common concerns like security context, probes, and labels live in one place instead of being copy-pasted 120 times. Each chart pins its image by digest.

Pinning by digest instead of tag is what makes the catalog trustworthy in practice. A tag can be moved; a digest can’t. When a consumer pins a QuenchWorks chart, they get exactly the bytes that passed the gate.

1
image:
2
  repository: ghcr.io/quenchworks/postgresql
3
  # Pinned by digest, not tag. This is the exact image that passed the gate.
4
  digest: 'sha256:abc123...'

The proof only matters if consumers can check it, so verification is a first-class step, not an afterthought. Anyone can verify an image’s signature and attestations before it runs, and an admission policy can enforce that in the cluster so unsigned or unverifiable images never schedule.

cosign verify \
  --certificate-identity-regexp '^https://github.com/quenchworks/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/quenchworks/postgresql@sha256:abc123...

Results

The catalog is real and in use, not a proof of concept.

• 150+ container images built from source on Wolfi, each gated to zero fixable CVEs.
• 120+ production Helm charts on the shared quench-common library, every one pinned to its image by digest.
• Every image cosign-signed with an SPDX SBOM and SLSA provenance, published under an ArtifactHub verified-publisher organization.
• Multi-arch (amd64 and arm64), nonroot, and read-only root filesystem by default.
• A nightly rescan and self-heal rebuild loop that keeps the catalog current as upstream ships fixes.
• Free and independent. No subscription, no registry pull limits, no lock-in.

The counts above are current catalog figures. Per-image build times and scan times vary by package, so I’d treat any single number there as indicative rather than a benchmark.

Lessons

The biggest lesson is that the base image choice decides everything downstream. Trying to reach zero CVEs on a fat base is a treadmill; starting from Wolfi’s minimal surface turns the gate into something you can keep green for months. If I’d started anywhere else, the self-heal loop would be firing constantly and the whole thing would feel like bailing water.

The second lesson is that provenance costs far less than it’s worth. Signing and generating SBOMs added very little build time, but they change the catalog’s whole posture. It stops being “trust me” and becomes “verify it yourself,” which is the entire point of replacing an opaque upstream. If I were doing it again, I’d wire verification into the consumer docs even earlier, because an unverified signed image is only half the value.

The one thing I’d watch more carefully next time is chart sprawl. The quench-common library chart paid for itself immediately, but library conventions need to be locked down early. Once a few charts drift from the shared patterns, every future change gets more expensive.

Frequently Asked Questions

References

• QuenchWorks catalog and website
• QuenchWorks on GitHub
• Wolfi undistro
• apko and melange
• Trivy vulnerability scanner
• Sigstore Cosign
• SPDX and SLSA provenance
• ArtifactHub