If you run anything on Kubernetes, there’s a good chance you were pulling Bitnami images without even thinking about it. bitnami/postgresql, bitnami/redis, bitnami/nginx, the whole Helm charts library sitting on top of them. For years it was just there, free, maintained, and reasonably well hardened. You built on it and moved on.

Then in 2025 that quietly stopped being true.

Broadcom, which now owns VMware and Bitnami, announced they were moving the free Bitnami catalog on Docker Hub to a bitnamilegacy tier and pushing the actively maintained, security-hardened images into a paid product called Bitnami Secure Images. In plain terms: the free images you were pulling would keep existing, but they would stop getting patched. If you wanted the hardened, CVE-managed versions going forward, you needed a subscription.

For a lot of teams that’s a genuine problem, not just an annoyance. You suddenly have production workloads sitting on a base of container images that nobody upstream is patching anymore. So I did the thing every engineer eventually does when a tool they depend on disappears. I rebuilt it.

This is the story of QuenchWorks, and how it actually works under the hood.

What actually happened to Bitnami?

Let me be precise here, because “Bitnami is dead” is not quite right and I don’t want to spread the panicky version.

The free catalog didn’t vanish. What changed is the maintenance story. The images that used to receive regular security updates for free got moved behind Bitnami Secure Images, and the free tier became a frozen legacy snapshot. A frozen container image is fine on day one and a slowly growing liability on day ninety, because CVEs get discovered in software you already shipped. An image that isn’t rebuilt is an image that only accumulates known vulnerabilities.

So the gap isn’t “there are no more Bitnami images.” The gap is “there is no more free, continuously patched, hardened catalog that a small team can just adopt.” That’s the hole QuenchWorks fills.

So what is QuenchWorks?

QuenchWorks is a security-first, from-scratch replacement for the Bitnami catalog. Right now it ships over 150 container images and more than 120 Helm charts, and it’s growing on a daily build cadence.

The rules I set for myself on day one:

1. Every image is built from source. Not repackaged, not re-tagged, not “pull the upstream binary and slap a label on it.” The source is compiled inside the build.
2. Zero fixable CVEs, enforced by the build itself. If a scan finds a vulnerability that has a fix available, the build fails. I’ll come back to the word “fixable” because it matters a lot.
3. Minimal and locked down by default. Nonroot, read-only root filesystem, no shell where one isn’t needed, multi-arch for x86_64 and arm64.
4. Signed and verifiable. Every image is cosign-signed and ships a software bill of materials and build provenance you can check yourself.
5. Clean-room. QuenchWorks does not copy Bitnami’s charts or configs. It’s an independent implementation, not a fork.

The whole thing lives at quench-works.com, the images are on GitHub Container Registry, and the charts are published to ArtifactHub as a verified publisher.

Why build on Wolfi instead of Debian or Alpine?

This is the decision everything else hangs on, so it’s worth explaining.

Most base images are general-purpose Linux distributions. Debian, Ubuntu, Alpine. They’re built to be a complete operating system you can log into and work in. That’s exactly the problem for a container. A container running Postgres does not need a package manager, a shell, curl, wget, or ninety other packages. Every one of those is more code, and more code means more CVEs that have nothing to do with the app you actually care about.

Wolfi is different. It’s a distroless-friendly, container-native Linux built by Chainguard specifically to have as little in it as possible and to get security fixes fast. Two tools go with it:

• melange builds a package from source into a signed APK.
• apko assembles a container image from a declarative list of those APKs, with no Dockerfile and no layers full of leftover build tools.

The payoff is that the final image contains the app, its runtime dependencies, and almost nothing else. There’s no apt, no busybox shell, no build toolchain hiding in a layer. A smaller image isn’t just faster to pull. It’s a smaller attack surface and a much shorter CVE scan.

Here’s the shape of the pipeline for a single app:

1
   upstream source (a specific, pinned version)
2
              │
3
              ▼
4
        melange build          ← compile from source, CGO off where possible,
5
              │                   stamp the real version, sign the APK
6
              ▼
7
         apko assemble          ← nonroot uid 1001, read-only rootfs,
8
              │                   multi-arch, only the runtime deps
9
              ▼
10
      Trivy scan (the gate)      ← fail the build on ANY fixable CVE
11
              │
12
              ▼
13
   cosign sign + SBOM + SLSA      ← keyless signature, bill of materials,
14
              │                    build provenance attestation
15
              ▼
16
        GHCR, pinned by digest

The Trivy step is the one that makes the whole project mean something, so let’s talk about it honestly.

What “zero CVE” actually means (and why I refuse to fake it)

“Zero CVE” is a phrase people love to put on a marketing page, and most of the time it’s not true. Any non-trivial piece of software has open vulnerabilities somewhere in its dependency graph at any given moment. Anyone who tells you their image has literally zero known vulnerabilities is either not scanning hard enough or not telling you the whole story.

So here’s the precise claim QuenchWorks makes: zero fixable CVEs.

The scanner runs in comprehensive mode and I filter to vulnerabilities that have a fix available. If a CVE has a patched version out there, the build must include it or the build fails. No exceptions, no allowlist to sneak something past the gate. That’s the part I control, and I hold it at zero.

What I can’t control is upstream. If a project depends on a library that has a known CVE and there’s simply no patched release yet, no amount of rebuilding fixes it. The fix doesn’t exist. In that case QuenchWorks reports the unfixable count openly instead of pretending it’s zero. When upstream ships the patch, the nightly rebuild picks it up automatically and the number drops.

I think that distinction is the most important thing about the project. “Zero fixable CVEs, and here’s the honest count of what’s still unfixable upstream” is a claim you can actually trust and verify. “Zero CVEs” with no asterisk is a claim you should be suspicious of.

Signed, documented, and pinned by digest

A hardened image you can’t verify is just a hardened image you’re taking on faith. So every QuenchWorks image ships three things beyond the bits themselves:

• A cosign signature, using keyless Sigstore signing. You can verify the image was built by the QuenchWorks pipeline and not swapped out somewhere in transit.
• An SBOM, a software bill of materials in SPDX format that lists exactly what’s inside. When the next big CVE drops, you can grep your SBOMs instead of guessing which images are affected.
• SLSA provenance, an attestation of how and where the image was built.

You verify them with the GitHub CLI:

gh attestation verify \
  oci://ghcr.io/quenchworks/images/postgresql:<version> \
  --owner quenchworks

And in your charts and manifests, images are always pinned by digest, never by a floating tag. A tag like :16 can be moved to point at different bits tomorrow. A digest like @sha256:... is the content. If the digest matches, you’re running exactly what was signed. This is the difference between “probably the image I tested” and “provably the image I tested.”

The Helm charts, and the piece that keeps them consistent

Images are half the story. The other half is the 120-plus Helm charts, because that’s how most people actually deploy this stuff.

The thing I wanted to avoid was 120 charts that each reinvent the same security boilerplate slightly differently. So there’s a shared library chart called quench-common that every application chart depends on. It defines all the cross-cutting pieces in one place: the pod and container security contexts, the labels, how the image digest gets wired in, the probes, the service account handling.

An individual chart, say the one for SeaweedFS or Tempo, only has to describe what’s actually specific to that app. The hardening comes from the library, so it’s identical everywhere and I fix it in exactly one spot. Every chart is validated in a real kind cluster before release, published to ArtifactHub with verified-publisher metadata, and pinned to its image by digest.

How to actually use it

The nice part is there’s almost nothing to learn. If you were pulling Bitnami, you already know the shape of this.

Pull an image directly:

docker pull ghcr.io/quenchworks/images/postgresql:<version>

Or install a chart from the OCI registry:

helm install my-postgres \
  oci://ghcr.io/quenchworks/charts/postgresql \
  --version <chart-version>

Browse the full catalog, with the live CVE count for every image, at quench-works.com, and find the charts on ArtifactHub under the QuenchWorks publisher.

Now let’s stop talking about it and actually use it. The rest of this post is hands-on. I’ll build a full observability stack, wire up GitOps so it deploys itself, ship a real application end to end, and keep the whole thing verifiable and zero-CVE over time. Every command and manifest here is real and runs against the live catalog.

How do you verify an image before you trust it?

Before we deploy anything, let’s do the step almost everyone skips: proving the image is what it claims to be. QuenchWorks signs every image with keyless cosign and attaches an SBOM and SLSA provenance, so you can check all of it in about ten seconds.

# GitHub CLI (attestations live on GHCR)
brew install gh        # macOS / Linuxbrew
# cosign for Sigstore signatures
brew install cosign

gh attestation verify \
  oci://ghcr.io/quenchworks/images/postgresql:17.5 \
  --owner quenchworks

gh attestation verify \
  oci://ghcr.io/quenchworks/images/postgresql:17.5 \
  --owner quenchworks \
  --predicate-type https://spdx.dev/Document \
  --format json | jq '.[].verificationResult.statement.predicate.name'

docker buildx imagetools inspect \
  ghcr.io/quenchworks/images/postgresql:17.5 \
  --format '{{.Manifest.Digest}}'
# sha256:... <- this is what you pin in values.yaml and manifests

Example 1: A full observability stack you can trust

Let’s start with the thing every cluster needs and nobody enjoys wiring up: observability. Metrics, logs, and traces, with dashboards on top. The classic Grafana stack is often called LGTM (Loki, Grafana, Tempo, Mimir), and QuenchWorks ships all of the pieces plus an umbrella chart that assembles them.

Here’s the data flow we’re building:

1
   your apps + kubernetes            collection            storage                    query + view
2
  ┌─────────────────────┐      ┌──────────────────┐   ┌────────────────────┐      ┌──────────────┐
3
  │  app metrics /logs   │────▶│  OTel Collector   │──▶│ VictoriaMetrics      │─┐    │              │
4
  │  traces (OTLP)       │      │  (receivers +     │   │  (metrics, TSDB)     │ │    │              │
5
  ├─────────────────────┤      │   processors +    │──▶│ Loki (logs)          │ ├──▶│   Grafana    │
6
  │  node_exporter       │────▶│   exporters)      │   │ Tempo (traces)       │ │    │  dashboards  │
7
  │  kube-state-metrics  │      │                   │──▶│                      │─┘    │              │
8
  │  Vector (log tail)   │────▶│                   │   └────────────────────┘      └──────────────┘
9
  └─────────────────────┘      └──────────────────┘
10
        all images: nonroot, read-only rootfs, 0 fixable CVEs, pinned by digest

What’s in the box

The repository layout

I’m going to do this the GitOps way from the start, so here’s the repo we’ll build up across the next two examples:

Step by step: install the stack

kubectl create namespace observability

1
# Grafana: the front end. Stateless by design; dashboards come from config.
2
grafana:
3
  enabled: true
4
  adminPassword: "" # leave empty, pull from a secret (see example 3)
5
  persistence:
6
    enabled: false # dashboards are provisioned, not hand-drawn
7
  ingress:
8
    enabled: true
9
    hostname: grafana.internal.example.com
10

11
# Metrics storage. PromQL-compatible, memory-friendly.
12
victoriametrics:
13
  enabled: true
14
  retentionPeriod: 30d
15
  persistence:
16
    enabled: true
17
    size: 50Gi
18

19
# Logs.
20
loki:
21
  enabled: true
22
  persistence:
23
    enabled: true
24
    size: 50Gi
25

26
# Traces.
27
tempo:
28
  enabled: true
29
  persistence:
30
    enabled: true
31
    size: 20Gi
32

33
# The single ingest point for OTLP metrics, logs, and traces.
34
otelCollector:
35
  enabled: true
36

37
# Log shipping from every node.
38
vector:
39
  enabled: true
40

41
# Cluster + host metrics.
42
kubeStateMetrics:
43
  enabled: true
44
nodeExporter:
45
  enabled: true
46

47
# Alert routing.
48
alertmanager:
49
  enabled: true
50

51
# Provision your own dashboards from JSON in the repo.
52
dashboards:
53
  enabled: true

helm install lgtm \
  oci://ghcr.io/quenchworks/charts/lgtm-stack \
  --version 0.1.0 \
  --namespace observability \
  --values stacks/observability/values.yaml \
  --wait

kubectl -n observability get pods
kubectl -n observability rollout status deploy/lgtm-grafana

kubectl -n observability port-forward svc/lgtm-grafana 3000:3000
# http://localhost:3000

Sending data to the collector

Your apps point at one endpoint, the OTel Collector, using standard OTLP. Nothing app-side is QuenchWorks-specific, which is the point.

1
env:
2
  - name: OTEL_EXPORTER_OTLP_ENDPOINT
3
    value: "http://lgtm-otel-collector.observability.svc:4317"
4
  - name: OTEL_EXPORTER_OTLP_PROTOCOL
5
    value: "grpc"
6
  - name: OTEL_SERVICE_NAME
7
    value: "acme-web"
8
  - name: OTEL_RESOURCE_ATTRIBUTES
9
    value: "deployment.environment=production"

And here’s a minimal collector config that fans OTLP out to all three backends:

1
receivers:
2
  otlp:
3
    protocols:
4
      grpc: { endpoint: 0.0.0.0:4317 }
5
      http: { endpoint: 0.0.0.0:4318 }
6

7
processors:
8
  batch: {}
9
  memory_limiter:
10
    check_interval: 5s
11
    limit_percentage: 80
12

13
exporters:
14
  otlphttp/metrics:
15
    endpoint: http://lgtm-victoriametrics.observability.svc:8428/opentelemetry
16
  loki:
17
    endpoint: http://lgtm-loki.observability.svc:3100/loki/api/v1/push
18
  otlp/tempo:
19
    endpoint: lgtm-tempo.observability.svc:4317
20
    tls: { insecure: true }
21

22
service:
23
  pipelines:
24
    metrics: { receivers: [otlp], processors: [memory_limiter, batch], exporters: [otlphttp/metrics] }
25
    logs:    { receivers: [otlp], processors: [memory_limiter, batch], exporters: [loki] }
26
    traces:  { receivers: [otlp], processors: [memory_limiter, batch], exporters: [otlp/tempo] }

Common questions

Example 2: CI/CD and GitOps that deploys itself

A stack you install by hand is a stack that drifts. The fix is GitOps: your Git repo is the single source of truth, and a controller in the cluster continuously reconciles reality against what’s committed. You don’t run helm install from your laptop anymore. You open a pull request.

The difference from traditional push-based CI/CD is worth stating plainly:

1
  PUSH model (traditional)                 PULL model (GitOps)
2
  ┌──────────┐   kubectl/helm              ┌──────────┐   commit
3
  │  CI job   │ ───────────────▶ cluster   │  Git repo │ ◀─────────── you
4
  └──────────┘   (credentials                └──────────┘
5
                  live in CI)                     ▲ watches + reconciles
6
                                                  │
7
                                             ┌──────────────┐
8
                                             │ Argo CD/Flux  │ (in-cluster)
9
                                             └──────────────┘

In the pull model your CI never needs cluster credentials. The in-cluster controller pulls. That’s a real security win, and it pairs perfectly with digest-pinned, signed images.

Bootstrap the controller

kubectl create namespace argocd
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

1
apiVersion: argoproj.io/v1alpha1
2
kind: Application
3
metadata:
4
  name: observability
5
  namespace: argocd
6
spec:
7
  project: default
8
  sources:
9
    # The hardened chart, pinned to an exact version
10
    - repoURL: ghcr.io/quenchworks/charts
11
      chart: lgtm-stack
12
      targetRevision: 0.1.0
13
      helm:
14
        valueFiles:
15
          - $values/stacks/observability/values.yaml
16
    # Your Git repo, providing the values file above
17
    - repoURL: https://github.com/your-org/platform-gitops
18
      targetRevision: main
19
      ref: values
20
  destination:
21
    server: https://kubernetes.default.svc
22
    namespace: observability
23
  syncPolicy:
24
    automated:
25
      prune: true
26
      selfHeal: true
27
    syncOptions:
28
      - CreateNamespace=true

flux bootstrap github \
  --owner=your-org \
  --repository=platform-gitops \
  --branch=main \
  --path=clusters/production

1
apiVersion: source.toolkit.fluxcd.io/v1beta2
2
kind: OCIRepository
3
metadata:
4
  name: lgtm-stack
5
  namespace: flux-system
6
spec:
7
  interval: 10m
8
  url: oci://ghcr.io/quenchworks/charts/lgtm-stack
9
  ref:
10
    tag: 0.1.0
11
---
12
apiVersion: helm.toolkit.fluxcd.io/v2beta2
13
kind: HelmRelease
14
metadata:
15
  name: observability
16
  namespace: observability
17
spec:
18
  interval: 10m
19
  chartRef:
20
    kind: OCIRepository
21
    name: lgtm-stack
22
    namespace: flux-system
23
  valuesFrom:
24
    - kind: ConfigMap
25
      name: observability-values
26
  install:
27
    createNamespace: true

The CI half: verify before you promote

GitOps handles deployment. CI’s job shrinks to something healthier: lint the manifests, render them, and above all verify the image signature before letting a digest into the repo. Here’s a GitHub Actions workflow that does exactly that.

1
name: verify-and-render
2
on:
3
  pull_request:
4
    paths: ["stacks/**", "apps/**", "clusters/**"]
5

6
jobs:
7
  verify:
8
    runs-on: ubuntu-latest
9
    permissions:
10
      contents: read
11
      id-token: write # for keyless verification
12
    steps:
13
      - uses: actions/checkout@v4
14

15
      - name: Install tooling
16
        run: |
17
          curl -sSfL https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64 \
18
            -o /usr/local/bin/cosign && chmod +x /usr/local/bin/cosign
19
          curl -sL https://get.helm.sh/helm-v3.16.0-linux-amd64.tar.gz | tar xz
20
          sudo mv linux-amd64/helm /usr/local/bin/
21

22
      - name: Verify every QuenchWorks image referenced in this PR
23
        run: |
24
          # pull the digests out of the values and prove each one is signed
25
          grep -rhoE 'ghcr.io/quenchworks/images/[a-z0-9-]+@sha256:[a-f0-9]+' stacks apps \
26
            | sort -u \
27
            | while read -r ref; do
28
                echo "Verifying $ref"
29
                gh attestation verify "oci://$ref" --owner quenchworks
30
              done
31
        env:
32
          GH_TOKEN: ${{ github.token }}
33

34
      - name: Render the charts (catch template errors before merge)
35
        run: |
36
          helm template observability \
37
            oci://ghcr.io/quenchworks/charts/lgtm-stack --version 0.1.0 \
38
            --values stacks/observability/values.yaml > /dev/null

Keeping digests fresh automatically

Pinning by digest is great for reproducibility and terrible for staying current, unless you automate the bumps. Renovate does this. It watches the registry, opens a pull request when a new digest ships, and your CI verifies the signature on that new digest before you merge. QuenchWorks has a hardened Renovate image in the catalog, so you can even run the bot on your own hardened base.

1
{
2
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
3
  "extends": ["config:recommended"],
4
  "helm-values": { "managerFilePatterns": ["/values\\.yaml$/"] },
5
  "packageRules": [
6
    {
7
      "matchDatasources": ["docker"],
8
      "matchPackagePatterns": ["^ghcr.io/quenchworks/"],
9
      "pinDigests": true,
10
      "groupName": "quenchworks images"
11
    }
12
  ]
13
}

GitOps questions people actually ask

Example 3: Shipping a real application end to end

Enough infrastructure. Let’s deploy an actual app with a database, a cache, TLS, and network isolation, using QuenchWorks charts for every piece. Call it acme-web.

The moving parts:

1
apiVersion: networking.k8s.io/v1
2
kind: NetworkPolicy
3
metadata:
4
  name: default-deny
5
  namespace: acme
6
spec:
7
  podSelector: {}
8
  policyTypes: [Ingress, Egress]
9
---
10
apiVersion: networking.k8s.io/v1
11
kind: NetworkPolicy
12
metadata:
13
  name: web-to-db
14
  namespace: acme
15
spec:
16
  podSelector:
17
    matchLabels: { app.kubernetes.io/name: postgresql }
18
  ingress:
19
    - from:
20
        - podSelector:
21
            matchLabels: { app.kubernetes.io/name: acme-web }
22
      ports:
23
        - port: 5432

1
apiVersion: external-secrets.io/v1beta1
2
kind: ExternalSecret
3
metadata:
4
  name: acme-db
5
  namespace: acme
6
spec:
7
  refreshInterval: 1h
8
  secretStoreRef:
9
    name: vault-backend
10
    kind: ClusterSecretStore
11
  target:
12
    name: acme-db-credentials
13
  data:
14
    - secretKey: password
15
      remoteRef:
16
        key: secret/acme/db
17
        property: password

helm install acme-db \
  oci://ghcr.io/quenchworks/charts/postgresql \
  --namespace acme --create-namespace \
  --set auth.existingSecret=acme-db-credentials \
  --set primary.persistence.size=20Gi \
  --wait

helm install acme-cache \
  oci://ghcr.io/quenchworks/charts/redis \
  --namespace acme \
  --set auth.enabled=true \
  --set master.persistence.size=8Gi \
  --wait

1
image:
2
  repository: ghcr.io/your-org/acme-web
3
  # your app's own digest; the QuenchWorks charts pin theirs the same way
4
  digest: "sha256:..."
5

6
replicaCount: 3
7

8
extraEnvVars:
9
  - name: DATABASE_HOST
10
    value: acme-db-postgresql.acme.svc
11
  - name: DATABASE_PASSWORD
12
    valueFrom:
13
      secretKeyRef:
14
        name: acme-db-credentials
15
        key: password
16
  - name: REDIS_HOST
17
    value: acme-cache-redis-master.acme.svc
18

19
# QuenchWorks charts default to a locked-down security context.
20
# You inherit nonroot + read-only rootfs; declare writable scratch explicitly.
21
extraVolumes:
22
  - name: tmp
23
    emptyDir: {}
24
extraVolumeMounts:
25
  - name: tmp
26
    mountPath: /tmp

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: acme-web
5
  namespace: acme
6
  annotations:
7
    cert-manager.io/cluster-issuer: letsencrypt-prod
8
spec:
9
  ingressClassName: nginx
10
  tls:
11
    - hosts: [app.example.com]
12
      secretName: acme-web-tls
13
  rules:
14
    - host: app.example.com
15
      http:
16
        paths:
17
          - path: /
18
            pathType: Prefix
19
            backend:
20
              service:
21
                name: acme-web
22
                port: { number: 8080 }

Example 4: Staying zero-CVE after day one

The hard part of a secure catalog isn’t launch day. It’s day ninety, when new CVEs have been found in software you already deployed. Here’s how the whole system stays honest without you babysitting it.

That loop is the actual product. Not any single image, but a pipeline where a security fix flows from upstream to your running pods through a chain that’s signed and checked at every hop.

Browse the full QuenchWorks catalog

150+ images · 120+ charts · verified publisher

Every image with its live CVE count, plus install commands for each chart.

Where it stands, honestly

I’ll close the way I started, without the marketing gloss.

QuenchWorks is real and it’s running. The daily cadence keeps adding apps, the nightly rebuild keeps the CVE counts honest, and the whole supply chain is signed and verifiable today. It is not a company and it is not trying to sell you a subscription. It exists because a useful free thing got taken away and rebuilding it turned out to be a genuinely interesting engineering problem in supply-chain security.

A few things are still upstream-blocked, where a project ships a dependency that nobody has patched yet. Those show up in the catalog with their real numbers rather than hidden. When upstream moves, the rebuild catches up on its own.

If you lost your Bitnami images and you’ve been putting off dealing with it, this is a drop-in place to land. And if you just care about how you build a container catalog that can prove what’s inside it, that’s the part I’d love to talk about.

You can find everything at quench-works.com.