Files
minio/docs/upgrade/single-node-from-archived-minio.md
T
Paris Yu fec1e0804a docs: add field-validated single-node upgrade guide from archived MinIO community edition
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).
2026-09-26 19:41:43 +08:00

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 /data in 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 ReadMultiple storage 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

  1. 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.
  2. Pin the exact target image tag in your deployment tooling. Floating tags make both upgrades and rollbacks ambiguous.
  3. Stop dependent services before swapping the storage container, so no writes race the restart.
  4. 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/live inside 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.
  5. 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/live and /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-Match on DeleteObject was ignored in 20260903 and is enforced in 20260916.
  • Multipart listing is capped at 1,000 entries per request in newer releases.
  • MINIO_API_TRUSTED_PROXIES still defaults to trusting every proxy header; set it explicitly if the node sits behind a proxy.