Image Roadmap — the road to 100 (demand-ranked)

Why demand, not stars#

For a hardened-container catalog, the metric that matters is "how often is this run as a container," not GitHub stars. They diverge sharply:

So popular-but-local tools (k9s, stern, dive, age) are deprioritized, and high-pull proxies/apps (oauth2-proxy, pomerium, …) are promoted.

* Docker pull counts are noisy — cumulative since inception, inflated by CI/bot pulls, and some namespaces (bitnami/*) are being deprecated. Treat as order-of-magnitude, not precise.

License lens: 🟢 permissive (MIT/BSD/Apache/MPL/ISC) add freely · 🟡 AGPL/GPL ok (precedent: loki/tempo/mimir/minio/trufflehog) · 🔴 SSPL/BUSL/EULA avoid or fork.

Build effort: Go single-binary = the proven Batch-B crank (fast). C/Rust/C++ = heavier. Node/frontend = the bwrap frontend quagmire (defer, own effort). Controllers = multi-image, run in-cluster (high demand, more work).

Tier 1 — high demand × easy Go build (do next)#

Single static Go binaries and genuinely run as containers. Best impact-per-effort.

Reclassified out of Tier 1 (not clean Go single-binaries — moved to "deferred"):

• pomerium — huge demand (1.6B pulls) but //go:embeds an arch-specific Envoy binary as its data plane → Tier-3-complexity build, own effort.
• cmctl — cert-manager's makefile-modules/klone build, no clean -X version injection → needs its own investigation.

Tier 2 — solid demand, easy Go CLIs#

Tier 3 — high demand, heavier builds (deliberate; fills thin DB/proxy/app categories)#

Real container demand, but C/Rust/C++/Node — each is its own effort, not a crank. Sequence by effort. Fills the catalog's thinnest categories (databases, proxies, apps).

Deferred / heavier efforts (own project, not a batch)#

Deprioritized — popular but low container demand (laptop / CLI / embedded)#

k9s (terminal UI) · dive (image inspector) · age (local crypto CLI) · duckdb (embedded lib, not a server) · zig/erlang/lua (languages — official base images exist). Add later only on explicit demand.

Avoided — non-OSS licenses (🔴)#

MongoDB / Elasticsearch (SSPL) · CockroachDB / Dragonfly (BSL). Use permissive forks if a real need appears (e.g. kvrocks/valkey cover the Redis/BSL gap).

Existing 🔴 exposures to resolve (pre-existing, tracked separately)#

• redis-slim declares SSPL-1.0 but 8.x is tri-licensed → re-declare AGPL-3.0-only.
• consul 2.0.0 = BUSL-1.1 (no OSS fork) → keep-vs-drop decision pending.

Road to 100 — remaining batches (F–K), policy × usage × license#

Ordered by our proven build templates first (fastest impact-per-effort), then demand. Policy filter = buildable under the shell-less/minimal thesis: ✅ static-Go binary · clean C daemon (no runtime compiler — the varnish lesson) · JVM-jlink · interpreter · binary-repackage. Excluded from the 100-path: frontend-in-bwrap (grafana/argocd/uptime-kuma), runtime-compiler (varnish), tangled force-bump graphs, huge-disk C++ (clickhouse), and 🔴 SSPL/BUSL/EULA. This section is a completed build log — the 100 target was reached and the catalog now stands at 108.

Batch F — static Go (the crank) → 88 [DONE]#

Batch G — clean C daemon (pgbouncer/unbound template) → 93 [DONE]#

Fills thin Infrastructure.

Batch H — JVM-jlink (kafka/zookeeper template)#

cassandra (🟢 wide-column DB, Java-17 + jamm agent) · solr (🟢 search, Java-21) · pulsar (🟢 messaging, Java-21) · flink (🟢 stream processing, Java-21) — all DONE. All Apache. Fills thin DB/search/messaging.

Batch I — Rust (qdrant/vector precedent, own effort each)#

vector (🟢 MPL-2.0, observability pipeline) · vaultwarden (🟡 AGPL-3.0, Bitwarden server; ~304M pulls) — both DONE.

Batch J — Erlang / Python#

patroni (🟢 MIT, Postgres HA — new Python-daemon pattern) — DONE. couchdb (🟢 Apache, Erlang — rabbitmq precedent) remaining.

Batch K — own-effort revisit#

cmctl (🟢 Apache — revisit klone build) · + one of {cert-manager core (multi-image) / pomerium (Envoy fetch) / apisix (OpenResty)}.

Batches H–K name more candidates than the 4 slots left to 100; the last slots go to whichever land first.

Beyond the 100-path (deliberate exceptions, not scheduled): varnish (runtime cc), grafana/argocd/uptime-kuma (frontend-in-bwrap), clickhouse/kubescape (disk-cap). See the deferred table above.

Wave 2 — beyond 108 (demand-ranked, re-surveyed 2026-08-30)#

Candidate survey after the 100 target was met. Same lens as above (license · container demand · use case), with one new input: many of these already have a Wolfi package, which moves them from "own effort" into the cheapest bucket we have (apko-only, dnsmasq/vector precedent — no melange recipe, no versions.yaml row, just an autoupdate-coverage.yaml classification).

Pull counts are Docker Hub pull_count read on 2026-08-30; treat as order-of-magnitude (cumulative, CI/bot-inflated).

Tier W1 — apko-only from an existing Wolfi package (cheapest crank)#

Verified present in the Wolfi x86_64 APKINDEX on 2026-08-30. (v) = versioned package ⇒ wolfi-versioned; (r) = unversioned/rolling ⇒ wolfi-rolling.

Also packaged in Wolfi, parked deliberately: argo-workflows (🟢 Apache — take with argo-cd or not at all), harbor-2.14-* (🟢 Apache, but 5+ images — own effort like cert-manager), mattermost-11.4 (⚠️ mixed AGPL + Mattermost Source Available License in the same tree — needs a license read before onboarding), apisix-ingress-controller (🟢 Apache — note Wolfi packages the controller, not apisix itself, so the Tier-3 apisix entry above is unchanged).

Wave 3 survey — verified 2026-09-07#

Re-checked every W1/W2 candidate against the live Wolfi APKINDEX (120,016 packages) and a Chainguard free-tier probe, after the W1 table was found wrong twice: it listed a gitlab-runner-18.11 package that was actually gitlab-agent-* (a different product), and a bare-name APKINDEX grep misses versioned packages entirely. Method that actually works — check three things, not one:

grep -x  "P:<name>"        APKINDEX   # exact package name
grep -E  "^P:<name>-[0-9]"  APKINDEX   # versioned package (gitlab-runner-19.3)
grep -E  "^p:(.* )?<name>=" APKINDEX   # a DIFFERENT package that provides the name

The Chainguard probe (validated against known-free nginx/python/static, which all return 200) is an anonymous pull-token request against cgr.dev/v2/chainguard/<name>/manifests/latest.

Already free from Chainguard — dropped from the plan. These were the roadmap's "near-zero effort, very high demand" picks, and there is no reason to publish a second free hardened build of something already free elsewhere:

Gated on Chainguard and packaged in Wolfi — the cheap, high-demand bucket. Pull counts read from Docker Hub on 2026-09-07:

The finding that shapes the next wave: the source-built well has run dry at the top of the demand curve. Every remaining high-demand candidate is either Wolfi-packaged (so apko-only), blocked by a frontend build (alloy, authelia, woodpecker), or already free from Chainguard. What is left to build from source is genuinely hard and much lower demand: influxdb (1.2B, but that number is v1/v2 — current upstream is a Rust rewrite), kvrocks (3.5M, C++), apisix (37M, OpenResty), emqx (Erlang, licence read needed), timescaledb (split licence), pgadmin4 (Python + prebuilt frontend), fluentd (Ruby).

So Wave 3 is a decision, not a queue: continue insisting on source builds and accept far lower demand per unit of effort, or take the apko-only route for things Chainguard gates. Note that apko-only is not a weaker product here — the Wolfi package is free, Chainguard's image is not, so a hardened signed SBOM-attested rebuild of a gated image is exactly the gap this catalogue exists to fill. It also keeps full auto-update coverage via autoupdate-coverage.yaml, which check-autoupdate enforces.

Tier W2 — source-built Go (the proven crank; no Wolfi package)#

Tier W3 — heavier / needs a decision#

Confirmed avoid (🔴 non-OSS) — checked in this survey#

terraform (492M) · vault (554M) · nomad · boundary · waypoint — all BUSL-1.1; already covered by our opentofu and openbao. elasticsearch / kibana / logstash — Elastic License; covered by opensearch. redpanda (35M) — BSL. n8n — Sustainable Use License. No change to the policy.

Suggested first PR out of this survey#

Six images, all W1, no new build template, spanning four categories: gitlab-runner · wordpress · maven · gradle · kong · perl — the two largest demand numbers we're missing, the two cheapest Languages entries, and the first addition to Web Servers & Proxies since oauth2-proxy.

Execution model#

• One PR per tier group (~6–8 images). Each image: 10 registration points (see docs/onboarding.md) incl. a validated cron-enabled versions.yaml row — the check-autoupdate gate blocks the PR otherwise.
• Build and prod+dev smoke-test every image locally before push (make <img>, make test-<img>, and assemble+test the -dev variant). Never push a failing image.
• Registration inserts use Python (newline-safe), not bash $(...) (which strips newlines and glues YAML lines — same failure family as the batch-b dropped paren).