Record — Moodle images after the Bitnami catalog change
Following the standard recipe for a local Moodle (needed to test SCORM course packages), the image pull fails:
$ docker pull bitnami/moodle:latest
# Error response from daemon: failed to resolve reference
# "docker.io/bitnami/moodle:latest": not found
$ docker pull bitnami/moodle:4.5 # same: not found
$ docker pull bitnami/moodle:4 # same: not foundMost older tutorials and even recent blog posts still point at bitnami/moodle.
| Repository | Tags | Notes |
|---|---|---|
bitnami/moodle | empty | Repo page resolves, tag list returns zero entries |
bitnamilegacy/moodle | exists — e.g. 5.0.2-debian-12-r2 | All tags last updated 2025-08-23, frozen since; compressed size ≈219 MB |
elestio/moodle | exists — latest = v5.2.2 | Last updated 2026-08-18, ≈512 MB compressed; actively maintained |
postgres:16-alpine | exists | Pulls and runs fine on colima/ARM — the DB half of every recipe still works |
Effective 2026-08-28 → actually announced for 2025-08-28: as part of Broadcom's
shift to “Bitnami Secure Images”, most free Debian-based Bitnami images were moved to the
bitnamilegacy org on Docker Hub and frozen (no further updates). Primary sources:
If your tutorial predates August 2025, its bitnami/* image references are now dead
even though the text looks current.
bitnamilegacy/moodle — the same images as before, moved and frozen. Swap the org name in old recipes.elestio/moodle (v5.2.2 as of Aug 2026) — third-party, so pin the tag and read their Dockerfile.The Bitnami announcement tells you the catalog moved; it doesn't tell you which Moodle
images exist where today, with which dates and sizes — and most Moodle tutorials haven't been
updated. This record gives dated tag-existence checks for the three likely repos, exact failing and
working commands on colima/ARM, and the DB-half confirmation (postgres:16-alpine is
unaffected).
Two pull attempts of elestio/moodle:latest failed with different symptoms,
and a control test explained why:
| Attempt | Symptom |
|---|---|
| Pull #1 (≈512 MB image) | Layer download truncated: “short read: expected 98,181,747 bytes but got 88,157,711 — unexpected EOF” |
| Pull #2 (retry) | Failed earlier — manifest HEAD request to registry-1.docker.io returned EOF |
Control: alpine:latest (≈3 MB) | Same manifest EOF — so this is not about image size |
| Endpoint check | hub.docker.com API and registry-1.docker.io both unreachable (000) at that moment — though the Hub API had worked minutes earlier for the tag checks above |
Practical read: the failures hit large and small images alike within the same session, and both
endpoints (hub.docker.com API and registry-1.docker.io) became unreachable
at the same time — consistent with a shared transport-path problem on this machine or
network. The root cause is not located: local proxy state and routing were
not examined, so this record does not attribute the outage to Docker Hub itself.
What remains useful regardless of root cause: tag metadata
(hub.docker.com/v2/repositories/.../tags) was reachable minutes before the registry
wasn't — so metadata checks and image pulls can fail independently. If your pulls die with manifest
EOF even on tiny images, check the endpoints separately before blaming the image. A proxy that
covers your browser but not your terminal is one common cause worth ruling out first.
Runtime verification of elestio/moodle therefore remains open: the
image exists and is maintained, but “boots and serves on colima/ARM” is still unverified from here.