Compatibility on SILO

Migrate from MinIO to Silo

Mon, 01 Jan 0001 00:00:00 +0000

Migrating from MinIO to Silo is an in-place binary replacement, not a data migration. Nothing is exported or re-imported. In a container deployment the only required change is the image name. For RPM/DEB installations, see Native Package Migration.

What changes

In order of importance:

Container image: minio/minio, quay.io/minio/minio, and pgsty/minio are all replaced by docker.io/pgsty/silo.
Package, systemd service, and server executable: minio → silo.
Upstream services: the in-place updater and MinIO-operated callhome/SUBNET are disabled; upgrades go through packages, images, or your orchestrator.
Default OS service account: silo — fresh installations only; migrations keep running as the existing data owner.
Branding: banners, Console appearance, log wording, and product links say Silo.

What stays

Object data and the .minio.sys metadata directory — the on-disk format is unchanged and remains interoperable with MinIO in both directions.
Buckets, versions, users, access keys, policies, lifecycle rules, replication state, encryption metadata.
S3 API, SigV4 signing, SDKs, mc/mcli, presigned URL behavior.
Endpoint hostname, API port 9000, Console port, volume mounts.
MINIO_* environment variables and existing server options.
/minio/* routes, x-minio-* headers, minio_* metrics.

There is no data-conversion step. If your MinIO build is years old, validate the version distance itself in staging; it is a large software upgrade, not a format change.

Silo vs. MinIO Server Compatibility

Mon, 01 Jan 0001 00:00:00 +0000

Silo is a maintained fork of the MinIO server. It preserves MinIO’s S3-facing and on-disk compatibility, but it is not a byte-for-byte, operationally invisible rename. This page is the compatibility contract for moving from the upstream baseline to the Silo source prepared on 2026-08-06.

Read this before replacing a MinIO deployment. The binary, package, service account, systemd unit, default local configuration directory, container path, Helm resource names, embedded Console, update behavior, several authorization decisions, and some error responses changed. Data disks and the MINIO_* configuration namespace did not receive a matching rename.

MCLI Client Compatibility Notes

Mon, 01 Jan 0001 00:00:00 +0000

mcli is Silo’s build of the MinIO Client (mc). This page records where the two are interchangeable and where they differ.

pgsty/mc forked from the upstream minio/mc at its final commit, 77f82e18 (2025-11-06). The upstream repository was archived in July 2026 without ever cutting a release that contains that commit — so every mcli release is strictly newer than any official mc binary ever published. Fork releases to date: 20260313, 20260321, 20260417, 20260804, and 20260806.

Principles

The fork follows one rule: the shipped artifact and its channels are renamed; the tool you use is not.

Native Package Migration

Mon, 01 Jan 0001 00:00:00 +0000

Silo publishes silo packages for RPM, DEB, and APK on amd64/arm64 via GitHub Releases, with SHA-256 sums and build-provenance attestations. This page records what changes relative to a minio package installation: the file layout, the service account, and the caveats. General migration scope is in the migration guide.

File layout

MinIO installation	Silo package
`/usr/bin/minio`	`/usr/bin/silo` (also provides `silo healthcheck`)
`minio.service`	`/usr/lib/systemd/system/silo.service`
`/etc/default/minio`	Still read, first; `/etc/default/silo` overrides per variable (`noreplace`/conffile — upgrades never overwrite edits)
service account `minio-user` (upstream) / `minio` (Pigsty)	`silo:silo`, declared in `/usr/lib/sysusers.d/silo.conf`, created on install
—	`/usr/share/doc/silo/LICENSE`, `NOTICE` (AGPL-3.0-or-later)

Two package properties: