Skip to main content
MinIO Community Edition entered maintenance/source-only distribution in late 2025 and its upstream community repository was archived in 2026. Existing servers may continue to run, but upstream community binaries and normal patch delivery are no longer a dependable production lifecycle. This upstream status does not create a CaseBender commitment to operate, patch, redistribute, or support MinIO. Consult MinIO’s current official notices and your supplier contract for authoritative third-party lifecycle terms.

​
CaseBender policy

  • New production installations cannot select a native minio provider.
  • Production bundles and installers do not embed a MinIO service, root credential, volume, or native MinIO SDK.
  • CaseBender does not create a new MinIO bucket at runtime.
  • Historical database enum values and migration history remain so upgrades do not destroy or reinterpret existing records.
  • A legacy MinIO service may be used only as a read source during an approved migration window.
  • No retirement date or long-term support promise is made beyond the current implementation. Customer-specific dates belong in an approved change plan.
Do not configure a legacy endpoint as a new generic S3 production backend without exact-product live certification under the current release matrix.

​
Migration window

Define a bounded window with:
  • owner and approver;
  • last supported source image/version and vulnerability review;
  • write-freeze and rollback decision times;
  • source retention deadline;
  • tested PostgreSQL plus exact-object-version recovery set;
  • destination live qualification;
  • RPO/RTO targets and measured rehearsal evidence; and
  • legal-hold/retention approval before any source disposal.

​
Preserve before changing anything

Keep both:
  1. a storage-level snapshot/archive of the original miniodata layout for disaster recovery; and
  2. an object-level export through the S3 API preserving keys, metadata where supported, object versions, sizes, and independently calculated SHA-256.
MinIO’s internal filesystem layout is not a valid import format for another provider. Never copy internal volume files directly into local or cloud object storage. Back up PostgreSQL at the same consistency point and preserve .env, encryption keys, AUDIT_INTEGRITY_SECRET, release image digests, TLS trust, and source credentials in the approved secret/recovery systems.

​
Copy-first migration

Use Storage Migration:
  1. inventory PostgreSQL object references and exact source versions;
  2. copy without deleting or overwriting the source;
  3. verify destination size and downloaded SHA-256;
  4. record each item in StorageMigrationLedger;
  5. quiesce writes and copy the final delta;
  6. switch reads only after verification;
  7. keep legacy/dual reads available only for the documented compatibility window; and
  8. retain the source read-only until rollback approval expires.
Do not use sync, delete the source, rotate away required credentials, or change object keys during initial copy.

​
Rollback

Rollback requires the original source and matching database recovery point. Quiesce writes, copy destination-only changes back non-destructively, verify SHA-256, then restore the prior profile configuration. If reverse copy cannot be proven, restore the complete PostgreSQL-plus-object consistency set. Never point an older application at a database schema it does not support.

​
Validation and closeout

Run destination live qualification, application upload/scan/promote/download/ delete tests, scripts/storage/verify-backup-restore.ts, and a rollback rehearsal. Retain sanitized evidence, ledger status, counts, hashes, RPO/RTO, approvals, and source-disposal authorization.