The compatibility audit does not cover the single-node/single-drive (FS mode) case explicitly. This documents a production upgrade from the final community release (RELEASE.2025-10-15T17-29-55Z) to Silo RELEASE.2026-09-16T00-00-00Z: why standalone deployments are low-risk (schema retention, no multi-node REST concern, IAM tightening not applicable), the validated procedure with layered verification, field results (~5.9k objects, zero migration, zero hardening rejections, full app regression passed), and the post-upgrade behavior changes to review per client (TLS defaults, If-Match on DeleteObject, multipart listing cap, TRUSTED_PROXIES default).
4.5 KiB
Upgrading a Single-Node Deployment from the Archived MinIO Community Edition
The MinIO community edition repository was archived on 2026-04-25 and its binary
distribution channels (dl.min.io, the Docker Hub tags, quay.io) were withdrawn
afterwards. Operators still running the final community release need a documented,
validated path forward. This guide records a real-world, single-node upgrade from
RELEASE.2025-10-15T17-29-55Z (the last community release) to Silo
RELEASE.2026-09-16T00-00-00Z, performed in production on 2026-09-26.
The compatibility audit covers the server behavior changes but does not specifically address the single-node/single-drive (FS mode) case. This document fills that gap with field data.
Validated environment
- Single node, single drive:
server /datain FS mode, running under Docker Compose - Root credentials only — no IAM sub-users, no OIDC, no notification targets, no reverse proxy
- ~5,900 objects / ~34,000 stored chunks accumulated over 15 months on the source version
- Source:
RELEASE.2025-10-15T17-29-55Z→ target:RELEASE.2026-09-16T00-00-00Z
Why this is a low-risk swap for standalone deployments
- Zero data migration.
.minio.sys, erasure metadata, bucket/object layout and encryption formats keep their names and schemas; the existing data volume is opened in place, with no copy and no metadata rewrite. - Single nodes are unaffected by the removed private
ReadMultiplestorage REST call — that only constrains mixed-version multi-node clusters. - The IAM/password-policy tightening does not apply to plain root-credential standalone setups (no sub-users, no OIDC, no bucket policies in use).
Procedure
- Back up the data volume first (tar the volume or snapshot the disk). Even with a compatible format, an upgrade window is the worst time to discover your only copy is damaged.
- Pin the exact target image tag in your deployment tooling. Floating tags make both upgrades and rollbacks ambiguous.
- Stop dependent services before swapping the storage container, so no writes race the restart.
- Recreate the storage container with the Silo image, keeping the data volume
unchanged. Compatibility notes:
minio server …invocations translate transparently; the official container entrypoint handles the rename.- Healthchecks that run
curl -f /minio/health/liveinside the container work out of the box with the official images (curl is bundled). If you build custom images, remember to include curl — the upstream release images shipped a static curl, minimal bases may not have one.
- Verify in layers:
- Startup log: expect zero errors. Watch specifically for hardening rejections — Silo refuses malformed historical objects (poisoned metadata, invalid erasure geometry) that older code tolerated; such objects need manual remediation before they will serve again.
GET /minio/health/liveand/minio/health/ready→ 200.- Application-level S3 smoke: upload → read back → delete, through the real client.
Observed results (2026-09-26 field run)
- In-place upgrade with zero migration steps; the 15-month-old data volume opened with no errors and no objects were rejected by the new hardening.
- A full application regression against the storage (multipart upload, object read by a parser service, listing, deletion) passed end to end.
- Rollback path is image-swap only (same on-disk schema), but note we did not
exercise a reverse downgrade in production. Our evidence is a staged forward
migration — the same data volume was opened read-write by three engine builds
in sequence (
2025-09→2025-10→2026-09) with no format intervention — plus the documented schema retention. Keep the previous image available locally: registry tags you depend on may disappear, as the community tags already have.
Post-upgrade behavior changes to check
These did not affect the validated standalone setup, but review them against your own clients before upgrading:
- TLS defaults changed across 20260903/20260916 — verify clients if you serve TLS directly from the storage node or front it with older proxies/identity providers.
If-MatchonDeleteObjectwas ignored in 20260903 and is enforced in 20260916.- Multipart listing is capped at 1,000 entries per request in newer releases.
MINIO_API_TRUSTED_PROXIESstill defaults to trusting every proxy header; set it explicitly if the node sits behind a proxy.