Build on the base images
Alongside the datastores and apps, QuenchWorks ships a set of base images you build your own apps on: hardened language runtimes, slim runtime bases for the final stage, and build-tool images. They are the same kind of artifact as everything else in the catalog. 0-CVE, cosign-signed, built nonroot on a read-only root filesystem, multi-arch, with an SBOM and SLSA provenance attached. You just FROM them in your Dockerfile instead of pulling them as a server.
Three families
Interpreters and SDKs you build with: Python, Node, Go, Rust, .NET, the JDK, Ruby, PHP, Bun, Deno, Erlang, Elixir, and Perl. Each ships its latest stable lines, no :latest.
The slim final stage you copy a built app onto: static for self-contained binaries, jre for jars, and dotnet-runtime / aspnet for .NET.
Language bases with a package or build tool preinstalled: pnpm, Yarn, Composer, Maven, Gradle, uv, and Poetry.
The full catalog, with the version tags, license, and digest for each image.
The multi-stage idea
The pattern that gets you a small, clean production image is the same everywhere: build in one stage, run in another.
- Build stage. Start FROM the SDK or build-tool image (
node,go,maven, and so on). Install every dependency, including the dev and build ones, and produce your artifact: a compiled binary, a builtdist/, a jar, a published folder. - Runtime stage. Start FROM a slim base (
static,jre,python,dotnet-runtime). Copy over only the built output and the production dependencies. Leave the compiler, the dev dependencies, and the package caches behind in the build stage.
The result ships only what runs in production. The toolchain stays out of the image you deploy, which means a smaller image and a smaller attack surface.
Two hardening rules
These images are not the usual Debian-slim bases, so two habits from ordinary Dockerfiles will trip you up. Both have a clean fix.
Per-ecosystem guides
Each guide leads with a full, copy-able multi-stage Dockerfile that already reflects the shell-less, nonroot reality.
Multi-stage with a prod-deps stage; pnpm, npm, and Yarn variants.
Build a venv in one stage, run it on the slim python base; pip, uv, and Poetry.
The classic two-stage build onto static for a tiny final image.
Build the jar with Maven or Gradle, run it on jre.
dotnet publish on the SDK, run on aspnet or dotnet-runtime.