minio-build

Docker images of the MinIO server and the MinIO client (mc), community edition, rebuilt from the last upstream source releases and published as dokjolly/minio and dokjolly/mc.

Why

In October 2025 MinIO Inc. stopped publishing the community edition's images, later removed them from Docker Hub (docker pull minio/minio now fails with "pull access denied") and closed anonymous pulls on quay.io; the upstream repository is archived and no longer maintained. Existing deployments keep working only while their host still has the image cached.

This repository keeps a copy of the source and builds the images itself, so deployments do not depend on anyone else's registry, and the images can be rebuilt with a current Go toolchain and base image.

What is inside

Path	Content
minio/	Unmodified source of minio/minio at RELEASE.2025-10-15T17-29-55Z (commit 9e49d5e7a648), the last upstream release
mc/	Unmodified source of minio/mc at RELEASE.2025-08-13T08-35-41Z (commit 7394ce0dd2a8), the last upstream release
docker/minio.Dockerfile, docker/mc.Dockerfile	Build from the snapshots
versions.env	Releases, commits, our revision numbers, Go and base images
scripts/build.sh	Local build for the current architecture
.github/workflows/release.yml	Builds on every push, publishes on tags

The snapshots are the upstream release tarballs (https://github.com/minio/<repo>/archive/refs/tags/<tag>.tar.gz), without git history. Changes made here are separate commits, so git log -- minio/ lists every deviation from upstream.

The images

• Binaries compiled with the same flags as upstream (CGO_ENABLED=0, -tags kqueue, -trimpath, version, release tag and commit in -ldflags), so minio --version reports the upstream release.
• Compiled with the Go version in versions.env (currently 1.27.3) rather than the 1.24 upstream used, for the current standard library security fixes.
• Runtime on Alpine (currently 3.24.3) instead of Red Hat UBI. The minio image keeps upstream's entrypoint (docker-entrypoint.sh), environment variables and /data volume, plus curl for health checks: it is a drop-in replacement for minio/minio. The mc image has mc as entrypoint, like upstream, and also a shell, so scripts can run several mc commands in one container with --entrypoint sh.
• linux/amd64 and linux/arm64.
• Licenses in /licenses inside each image.

Tags:

Tag	Meaning
RELEASE.2025-10-15T17-29-55Z-r1	Upstream release + our build revision. Never changes once published: pin this one.
RELEASE.2025-10-15T17-29-55Z	Newest revision of that release
latest	Newest revision of the newest release

services:
  object-storage:
    image: dokjolly/minio:RELEASE.2025-10-15T17-29-55Z-r1
    command: server /data

Coming from minio/minio:RELEASE.2025-09-07T16-13-09Z (the last image on Docker Hub) the data directory is used as is: same on-disk format, no migration.

Building locally

Needs Docker with buildx.

./scripts/build.sh          # both images
./scripts/build.sh minio    # one
docker run --rm dokjolly/minio:RELEASE.2025-10-15T17-29-55Z-r1 --version
docker run --rm dokjolly/mc:RELEASE.2025-08-13T08-35-41Z-r1 --version

Publishing a release

Publishing runs on GitHub Actions; nothing is pushed from a PC.

One-time setup:

1. on Docker Hub, create the public repositories dokjolly/minio and dokjolly/mc (or let the first push create them), and an access token with Read & Write permission (Account settings → Personal access tokens);
2. on GitHub, in the repository's Settings → Secrets and variables → Actions, add DOCKERHUB_USERNAME (dokjolly, the Docker Hub username — not the email) and DOCKERHUB_TOKEN.

Each release:

1. change what is needed and bump the revision in versions.env;
2. commit and push to main: the workflow builds both images for both architectures without publishing. Wait for it to pass;
3. tag with the name the workflow expects and push the tag:

   git tag minio-RELEASE.2025-10-15T17-29-55Z-r2
   git push origin minio-RELEASE.2025-10-15T17-29-55Z-r2
   

   (mc-<MC_RELEASE>-r<MC_REVISION> for the client.) The workflow refuses a tag that does not match versions.env.

Keeping the images current

There will be no new upstream releases. What can still be updated here:

• Go toolchain: change GO_IMAGE in versions.env to a newer golang:<version>-alpine<version> tag. Go's compatibility promise means the code keeps compiling; check that the build passes.
• Base image: change BASE_IMAGE to a newer alpine:<version>.
• Dependencies with security fixes: in minio/ (or mc/) run go get <module>@<fixed version> && go mod tidy with the Go version of the build, build, run the tests of the touched packages (go test ./cmd/... is long; at least the packages that use the module), commit with the advisory in the message.
• Fixes in MinIO's own code: only small, targeted patches, each in its own commit. Nobody maintains this code any more, so check advisories for MinIO before relying on it for anything exposed to the internet.

Then bump MINIO_REVISION / MC_REVISION and publish as above. Useful checks: govulncheck ./... inside minio/ or mc/, and docker scout cves / trivy image on the built image.

The images are meant for MinIO on a private network (for example only reachable by an application's backend). For anything public, consider an actively maintained S3-compatible server.

Remotes

The repository is pushed to two remotes, so the source survives either one going away:

git remote add origin https://github.com/Dokjolly0/minio.git
git remote add nas https://git.alexviolatto.dev/Dokjolly/minio.git
git push origin main --tags
git push nas main --tags

Only GitHub runs the release workflow.

License

MinIO and mc are licensed under the GNU AGPL v3 (minio/LICENSE, mc/LICENSE), and so are these images. Publishing the images together with this repository, which holds the complete corresponding source and build instructions, is what the AGPL asks of a redistributor. MinIO is a trademark of MinIO Inc.; this project is not affiliated with or endorsed by MinIO Inc. The build files written here (docker/, scripts/, .github/, versions.env) are under the same license.