Docker base image for the v12.1.0 pin (nightly-2dfaae752) is un-pullable — Docker Hub purged it; can the archived image get a public home (GHCR / HF Hub)?

[jsboige]

Hi 👋 — first, thanks for v12. The sndr-platform tree + the 7-model fleet validation in v12.1.0 are great, and the release-notes transparency about the Docker Hub purge is appreciated.

I'm hitting the purge from the adoption side and wanted to surface a concrete request.

Context

We run a Docker-based deployment (not the bare-metal install.sh / venv path) on 3× RTX 4090 (sm_89), serving Qwen3.6-35B-A3B-AWQ + TurboQuant k8v4 (TP=2, EP=2). We've been on Genesis v7.72.5 (fbecee31) layered on the pinned nightly vllm/vllm-openai:nightly-01d4d1ad3 (May 4) since 2026-05-17 — that base is still pullable, so our Dockerfile.qwen36-genesis-tq (clone → cp vllm/_genesis → pip install -e tools/genesis_vllm_plugin → transformers>=5.0 + shm patch) has worked cleanly.

We'd like to move to v12.1.0 for MTP + the P28/P72 buffer work, mirroring the same Docker-layered approach on top of the new sndr package + sndr.apply flow.

The blocker

The v12.1.0 base image is gone from Docker Hub:

$ docker pull vllm/vllm-openai:nightly-2dfaae752b4db0d43cfc0715c780e33be030d0f1
Error response from daemon: ... not found

Same for the v12.0.0 pins (nightly-3f5a1e173…, nightly-04c2a8dea…) — both not found.

I know this is expected (the v12.1.0 notes already call it out), but to quantify the window for anyone landing here: querying Docker Hub today, only the last ~5 days of nightly-* tags are pullable (c71a583a Jul-18 → 94c0ef30 Jul-14). The v12.1.0 pin is Jul-4 (15 days old), so it's permanently purged — and any future Genesis release older than ~5 days will be in the same state. The v7.72.5 pin (May-4) only survived for us because it was pulled and cached locally 2 months ago.

Your release notes already document the archive:

file: vllm-nightly-2dfaae752_dev748.tar (8.8 GB) — "Stored on the reference rig at /home/sander/releases/ … Too large for GitHub release assets — mirror it to your own storage."

That archive is exactly what we need — but /home/sander/releases/ is a personal rig, not publicly reachable, and GitHub's 2 GB asset cap rules out attaching the tar to the release directly.

Ask (whichever is least effort for you)

1. Publish the archived image somewhere pullable. Cheapest options that handle 8.8 GB cleanly:
   • GHCR — ghcr.io/sandermage/vllm-nightly-2dfaae752:dev748 (free, native GH integration, no per-asset size issue; one docker push from the reference rig).
   • Hugging Face Hub — upload the tar as an LFS file under e.g. Sandermage/vllm-nightly-2dfaae752; HF allows multi-GB, free for public repos, and is already the vLLM-community norm for model/engine artifacts.
   • A release-backed mirror (R2/S3 presigned) would also work.
2. Or, if publishing the image isn't on the table: bless/document a wheel-overlay path for Docker adopters, e.g. FROM vllm/vllm-openai:nightly-<recent-pullable> then pip install --force-reinstall --no-deps vllm==0.23.1rc1.dev748+g2dfaae752 --extra-index-url https://wheels.vllm.ai/nightly, with GENESIS_VLLM_PIN_POLICY=warn. The open question there is whether anchor drift on a newer base silently no-ops P22/P38 (the _continuation_prefill workspace fix we depend on) — i.e. does warn + drifted anchors leave the crash-fix un-applied without a loud signal? If you can confirm the wheel path is sound (or won't be), that's enough for us to proceed.

For context, our current v7.72 Dockerfile layering (the v12 equivalent would swap in the sndr package + python3 -m sndr.apply):

FROM vllm/vllm-openai:nightly-01d4d1ad375dc5854779c593eee093bcebb0cada
RUN pip install --no-cache-dir "transformers>=5.0" "tokenizers>=0.21" "huggingface_hub>=0.30"
RUN pip install --no-cache-dir pandas scipy xxhash
RUN apt-get update && apt-get install -y --no-install-recommends git ca-certificates && rm -rf /var/lib/apt/lists/*
ARG GENESIS_COMMIT=fbecee31fd42fa7de9c2e2e8d780a28c01f46abb
RUN git clone https://github.com/Sandermage/sndr_core_engine.git /opt/genesis \
 && git -C /opt/genesis checkout ${GENESIS_COMMIT} \
 && cp -r /opt/genesis/vllm/_genesis /usr/local/lib/python3.12/dist-packages/vllm/_genesis \
 && pip install --no-cache-dir --no-deps -e /opt/genesis/tools/genesis_vllm_plugin
# ... shm_broadcast.py patch, entrypoint apply_all, etc.

Happy to test any path you can unblock (GHCR pull, HF download, or the wheel-overlay) on our 4090 rig and report back. Thanks again for the work on this tree — it's the only thing that made TurboQuant k8v4 viable on Ada for us.