Which MinIO RELEASE tag you suppose pin now?

Wetin MinIO RELEASE tag mean

A MinIO release tag na timestamp, no be version number like 1.2.3. minio/minio:RELEASE.2025-09-07T16-13-09Z mean the build wey comot on 7 September 2025 at 16:13:09 UTC. For MinIO, the version and the date na the same thing, so the tags sort themselves once you line dem up.

Short answer first. I open the MinIO releases page on 28 September 2026, and on that day RELEASE.2025-09-07T16-13-09Z no be the tag you suppose pin. One release dey after am, RELEASE.2025-10-15T17-29-55Z, and MinIO title that one Security/CVE. Pin the September tag and you go sidon on top one privilege escalation bug wey the project already fix.

Every date, tag and quote inside this post carry that same check date: 28 September 2026. Before you copy any tag from here into your compose file, open https://github.com/minio/minio/releases yourself and look wetin dey on top today. The mechanics no go change. The tag number fit change.

Why self-hoster dey pin instead of running :latest

:latest mean whatever build dem push last, and that one na moving target. You run docker compose pull on Tuesday and you collect one build. You run the same command on Friday and you collect another build. If the stack break on Friday, the tag no go help you find wetin change, because the tag never change.

A pinned tag solve that. When your compose file talk image: minio/minio:RELEASE.2025-10-15T17-29-55Z, the same build go land on any machine, any day, until you edit that line yourself. Your compose file turn into the written record of wetin dey run on the box. Na the same discipline wey make sense for any project wey dey move fast, and the reasoning we use for pinning llama.cpp releases on a server apply here one for one.

Object storage make the case even stronger. MinIO no dey just answer request, e dey own the way your data sit on disk. An upgrade wey you no plan for, and wey touch that layout, no dey roll back nicely. If you never put MinIO up before, start from running MinIO as your own S3 compatible object storage, then come back here for the tag question.

Why people dey go hunt old MinIO tag

Now the reason plenty people land on this exact question. On 24 May 2025 MinIO ship RELEASE.2025-05-24T17-08-30Z and title am Breaking Release. Two lines inside those release notes change how self-hosters run MinIO. I quote dem as dem write dem:

Embedded UI Console is now deprecated and moved to object-browser

External IDP logins via LDAP/OIDC are removed as well; these are now available as part of the AiStor Product

AiStor na MinIO paid product. So if your MinIO been dey use company LDAP (lightweight directory access protocol) or an OIDC (OpenID Connect) provider like Keycloak for login, that door close inside the open source build from May 2025 forward. The same notes also remove boringcrypto FIPS support, and dem point people to the GOFIPS environment variable on Go 1.24 instead. One thing survive, and the notes say am plain: STS APIs continue to work if somebody wan build UI in front. So your programmatic credential flow still dey alive.

That na why some people dey go look for a tag from before May 2025. Dem want back the feature wey comot, and that want make sense. But sabi the full price. A tag from April 2025 mean you lose every single fix wey land after April 2025, and the October 2025 security release na part of wetin you lose. Losing SSO dey pain. Running a known privilege escalation bug pain pass am.

This pattern, where feature wey dey inside the free build today land inside the paid tier tomorrow, na wetin we open up for the SSO tax wey dey hide inside self-hosted apps. MinIO na one of the clearest example wey dey around.

The security release wey dey after the September tag

So why September tag dey pass hand for hand? Because e be the newest tag for a long stretch, and plenty blog post, forum answer and copied compose file freeze am there. Then October arrive.

RELEASE.2025-10-15T17-29-55Z carry the title Security/CVE. The advisory na GHSA-jjjj-jwhf-8rgr, and MinIO describe the problem as privilege escalation through session policy bypass in service accounts and STS (security token service). The release notes tell everybody to download and upgrade immediately.

Read wetin that one mean for your box. A service account or an STS token na the low trust credential you hand to an app: a backup script, a CI runner, a photo uploader. The whole point of the session policy wey you attach na to box that credential inside one bucket and one set of action. When the policy check fail the way that advisory describe, the credential fit reach past the box you draw for am. So a token wey you share with something you no fully trust stop being small.

You fit read the advisory yourself for https://github.com/minio/minio/security/advisories/GHSA-jjjj-jwhf-8rgr. If you dey run any MinIO tag older than 15 October 2025 and you dey hand out service accounts, treat that as the thing to fix this week. The wider habit of matching wetin dey run against published advisories dey inside checking your server for known CVEs, and MinIO na exactly the kind of service wey reward that check, because e hold data and e dey talk to the internet.

Shey MinIO still dey ship release?

This one matter, because a pin only make sense if you sabi how the project dey move. Here na the gap, in days, between each MinIO release from April 2025, plus the gap wey still dey open after the last one. I count dem from the tags wey dey on the releases page on 28 September 2026.

[
  {
    "version": "2025-04-03",
    "gap_days": 22
  },
  {
    "version": "2025-04-08",
    "gap_days": 5
  },
  {
    "version": "2025-04-22",
    "gap_days": 14
  },
  {
    "version": "2025-05-24",
    "gap_days": 32
  },
  {
    "version": "2025-06-13",
    "gap_days": 20
  },
  {
    "version": "2025-07-18",
    "gap_days": 35
  },
  {
    "version": "2025-07-23",
    "gap_days": 5
  },
  {
    "version": "2025-09-06",
    "gap_days": 45
  },
  {
    "version": "2025-09-07",
    "gap_days": 1
  },
  {
    "version": "2025-10-15",
    "gap_days": 38
  },
  {
    "version": "nothing yet",
    "gap_days": 348
  }
]

The chart carry 11 rows. Ten of dem na real release. For that whole stretch the widest gap between two release na 45 days, and the jump from the September tag to the October security tag na 38 days. Normal cadence, in other words: something dey land every few weeks.

The last row no be release. Na the gap wey dey still counting after 15 October 2025, and on 28 September 2026 e reach 348 days with nothing new on top the feed. I no go tell you wetin that silence mean, because I no sabi. Wetin I go tell you na that e change your job. When a project dey ship every three weeks, your job na to follow. When the feed quiet for almost one year, your job na to watch the advisory page yourself, because nobody go push a fix into your stack for you.

How the pin look inside docker-compose.yml

A pin na one line. Everything else na the normal MinIO service.

services:
  minio:
    image: minio/minio:RELEASE.2025-10-15T17-29-55Z
    container_name: minio
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: ${MINIO_ROOT_USER}
      MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}
    volumes:
      - minio-data:/data
    ports:
      - "127.0.0.1:9000:9000"
      - "127.0.0.1:9001:9001"
    restart: unless-stopped

volumes:
  minio-data:

The ${...} values come from a .env file wey sit beside the compose file, so the root password no enter git. Both port bind to 127.0.0.1, which mean only the box itself fit reach dem. Put a reverse proxy with TLS (transport layer security) in front before you open anything to the internet: MinIO speak plain HTTP here, and the root credential go cross the network in cleartext if you expose port 9000 raw.

One honest note about --console-address. On tags from May 2025 forward, that port no longer serve the old embedded admin console. E serve the trimmed object browser instead, and the LDAP or OIDC login screen no dey there at all. If you point your browser there and the screen look smaller than wetin some tutorial show you, nothing spoil. Na the deprecation wey we quote up there.

How to check which MinIO release your container really dey run

No guess this one from your compose file. Ask the running container.

docker compose exec minio minio --version
docker inspect --format '{{.Config.Image}}' minio

The first command ask the binary itself, and e print a line wey start with minio version and carry the RELEASE string. That na the truth. The second command print the tag wey the container was created from. When the two agree, you dey fine.

When dem disagree, the binary win. A tag na just a name wey point at an image, and a name fit get re-pointed. The mc client give you a third view, from outside:

mc alias set local http://127.0.0.1:9000 "$MINIO_ROOT_USER" "$MINIO_ROOT_PASSWORD"
mc admin info local

mc admin info local print the server state plus the version per node. If you never install mc, the official binary download na this:

wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc
./mc --help

If mc admin info local answer with a connection refused, the client dey talk to the wrong port or the container no dey up. Run docker compose ps and confirm the service state before you chase the alias.

Pin the digest when you want the pin to be real

A RELEASE tag na a strong pin, no be a perfect one, because a tag na a label wey fit point somewhere else later. The digest no fit move, because e na the hash of the image content.

docker pull minio/minio:RELEASE.2025-10-15T17-29-55Z
docker image inspect --format '{{index .RepoDigests 0}}' \
  minio/minio:RELEASE.2025-10-15T17-29-55Z

That print something like minio/minio@sha256: plus a long hex string. Paste the whole thing into your compose file as image: minio/minio@sha256:... and keep the human readable tag in a comment beside am, because sha256:4f2a... no dey tell anybody which release e be. This na the tightest pin you fit write, and the cost na that the comment become the only readable label. For most home and small team stack the RELEASE tag alone dey enough. For anything wey audit go touch, use the digest.

How to move the pin forward without losing data

The rule na simple: backup first, then edit the pin, then verify. Never the other way round.

docker volume ls | grep minio
docker compose stop minio

Check the volume name first, because Compose add your project name in front, so minio-data dey show up as something like mystack_minio-data. Use the real name in the next command.

docker run --rm -v mystack_minio-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/minio-data-2026-09-28.tgz -C /data .
cp docker-compose.yml docker-compose.yml.before-upgrade

Copying the compose file matter as much as copying the data, because that file hold the old pin. If the new release misbehave, the old pin na your way back, and you no go dey try remember which tag been dey there. A second, data level copy with mc mirror local/mybucket /srv/backup/mybucket give you plain files wey you fit read without MinIO, which dey useful when the reason you dey rolling back na that MinIO no start at all.

Now edit the image: line to the tag you choose, then bring am up and look:

docker compose pull minio
docker compose up -d minio
docker compose exec minio minio --version
docker compose logs --tail 50 minio
curl -I http://127.0.0.1:9000/minio/health/live

A healthy result na four things wey you fit see. minio --version print the new RELEASE string. The logs show the startup banner with no repeated error line. curl -I on the health endpoint return HTTP/1.1 200 OK. And mc ls local list your buckets with the same names and the same object count as before. If the health endpoint return nothing and docker compose ps show the container dey restart in a loop, read the logs from the top: MinIO dey refuse to start with a clear message when e no like the data directory or the root credential, and that message dey name the problem.

The full routine for taking a snapshot, moving one pin and coming back when e fail dey inside backing up and upgrading a Docker Compose stack. Same steps, any service.

Wetin you suppose watch once you pin

A pin na a decision to stop collecting fix. That trade fine, as long as you sabi you make am. So somebody get to do the watching, and that somebody na you.

• Subscribe to https://github.com/minio/minio/releases.atom inside any feed reader. E na plain Atom, so you no need account.
• Check https://github.com/minio/minio/security/advisories when a release land, because the title na where MinIO mark a release as Security/CVE.
• Write your current pin somewhere you go see am, no be only inside the compose file. A one line note per service, with the date you pin am, answer the question "how old is this?" in two seconds.
• Treat a quiet feed as information, no be as safety. Nothing new on top the feed no mean nothing new dey wrong.

Admin work now dey inside mc, no be the old console

One last thing wey catch people after dem pin a 2025 tag. The old embedded admin console no dey come back, so the admin work move into two place. The mc client handle am from the command line, and the object browser, wey live in the minio/object-browser repo, handle the file side in a browser.

The everyday work translate cleanly, and na the same commands wey the project README show:

mc mb local/mybucket
mc cp ~/report.pdf local/mybucket/
mc ls local/mybucket
mc mirror local/mybucket /srv/backup/mybucket

User, policy and service account work sit under mc admin. The exact subcommand differ between mc versions, so run mc admin --help on the client you actually install instead of copying a command from an old post. That habit save you plenty time, because a command wey no exist fail with a usage dump wey look like a bug and na just a version gap.

So, to close the question you came with. As of 28 September 2026, pin RELEASE.2025-10-15T17-29-55Z, no be RELEASE.2025-09-07T16-13-09Z, because the October tag carry the fix for GHSA-jjjj-jwhf-8rgr. Then go confirm on the releases page whether anything land after am, because that page dey correct and this post dey frozen.

FAQ

Shey minio/minio:RELEASE.2025-09-07T16-13-09Z na the tag I suppose pin?

No, not when I check the releases page on 28 September 2026. RELEASE.2025-10-15T17-29-55Z come after am and MinIO title that one Security/CVE, for a privilege escalation through session policy bypass in service accounts and STS, advisory GHSA-jjjj-jwhf-8rgr. Pinning the September tag mean you dey keep a bug wey already get a fix. Check https://github.com/minio/minio/releases for yourself before you copy any tag, because a newer one fit dey there by the time you read this.

Wetin the May 2025 breaking release remove from MinIO?

RELEASE.2025-05-24T17-08-30Z notes say the embedded UI Console dey deprecated and move to object-browser, and that external IDP login through LDAP and OIDC dey removed and now dey inside the AiStor product. The same release remove boringcrypto FIPS support and point to the GOFIPS environment variable on Go 1.24. The notes also confirm say STS APIs still work, so programmatic credential flow no break.

How I go know which MinIO release my container really dey run?

Run docker compose exec minio minio --version and read the RELEASE string wey the binary print. Then run docker inspect --format '{{.Config.Image}}' minio to see which tag the container was created from. When the two no match, believe the binary, because a tag na a movable label. From outside, mc admin info local report the version per node.

If I pin one tag, how I go hear when something wrong?

Nobody go tell you, so set the watching up yourself. Subscribe to https://github.com/minio/minio/releases.atom in a feed reader, and check https://github.com/minio/minio/security/advisories whenever a new release land. Keep a one line note of your current pin and the date you set am, so you always sabi how old the running build be.