Skip to content

Compatibility

Can SILO replace MinIO? A user-facing index of 12 compatible improvements, 4 minor differences, and 8 changes to check when their conditions apply.

Most applications using standard S3 APIs can switch from MinIO to SILO without code changes. Common S3 APIs, SigV4, SDK integration and object storage layouts carry over. Deployment, authorization and replicated state require the checks below: SILO is a conditional drop-in replacement.

Mostly presentation, UI interaction and response information; usually no application changes.

Reviewed: 2026-09-16; release status updated 2026-09-17. This index covers source and companion-component changes since the fork. The server-side changes described here shipped in Server 20260916; the component matrix records which repairs are absent from the earlier Server 20260903. The 24 entries group user scenarios; they are not API counts, compatibility percentages or failure probabilities.

🟢 Compatible improvements: 12 categories

Normal usage needs no migration work for these capabilities. Dependencies on old bugs, mixed versions or damaged historical state are covered by the orange entries.

Category and change When it applies Impact and action Details
G01 · Full Web administration
Restores full Web management of buckets, objects, users, policies and the system.
Managing a deployment in a browser. More capable administration; ordinary S3 applications need no changes. Console features
G02 · Chinese UI and text preview
Adds English/Chinese UI and bounded, safe text preview.
Switching language or previewing text objects. Changes the Console experience, not stored object content. Languages, text preview
G03 · Per-bucket CORS
The existing CORS APIs now persist and enforce per-bucket cross-origin rules.
Browser cross-origin access with bucket CORS configured. Bucket rules override global CORS; object access still requires authorization. CORS behavior
G04 · Native health checks
Adds silo healthcheck for container and operational probes.
Choosing to use the new probe command. Existing HTTP health endpoints remain available. Command and scope
G05 · Client checksum audit
Adds mcli checksum verify to read objects and verify checksums.
Explicitly running an integrity audit. Read-only checks and reports; no object modification or repair. Audit command
G06 · Upload and copy checksums
Valid uploads, multipart completion and copies compute, retain and return checksums more accurately.
Using the affected upload or copy paths. Better SDK interoperability; invalid requests are covered by O04. Multipart uploads, S3 fixes
G07 · Encryption and compression fixes
Corrects data and logical-size handling across SSE-C, KMS, compression and copying.
Using these encryption, compression or copy combinations. Improves new requests; it does not automatically repair all historical damage. SSE-C and old objects, federated copies
G08 · Concurrent bucket configuration
A shared metadata lock prevents concurrent bucket updates from overwriting each other.
Concurrent policy, lifecycle, encryption or other bucket updates. More reliable administration with the same calling pattern. Shared configuration lock
G09 · Tag and Object Lock replication
Replication preserves and orders tag, retention and lock state more accurately.
Replicating or healing tags and Object Lock metadata. Reduces lost state and stale-event overwrites; see O07 for mixed versions. Tag ordering, lock ordering
G10 · Pool migration and healing
Rebalance, decommission and recovery handle tags, versions and delete markers more accurately.
Moving pools, healing or recovering replication. Better metadata preservation and retries; historical anomalies still need inspection. Multi-pool consistency, replication recovery
G11 · Notifications and streaming
Fixes NATS/AMQP setting recognition and flushing of notification and Select streams.
Using those notification targets or streaming APIs. More accurate configuration and event output; see O03 for old database settings. Notification settings, stream flushing
G12 · Stability and resource cleanup
Fixes concurrent collection, buffer ownership and connection cleanup.
Concurrent I/O, metric collection or request cancellation. Reduces related crashes and resource problems; no universal speedup is implied. Read buffers, runtime and metrics

🔵 Minor differences: 4 categories

Ordinary applications usually need no changes. Tools that hard-code product strings, metric meanings or response fields should still be checked.

Category and change When it applies Impact and action Details
B01 · Product identity
Banners, logs, HTTP product identity and UI labels use SILO.
Reading output or matching product names. Presentation changes; adapt name-matching scripts. Installation changes are in O01. Server identity, client output
B02 · Paginated Console listings
Object listings use cursors, with sorting, filtering and selection limited to the current page.
Browsing, filtering or selecting objects in Console. UI habits change; direct S3 application access does not. Pagination boundaries
B03 · Richer monitoring and diagnostics
Adds diagnostic metrics and corrects quota, replication counters and status meanings.
Using affected metrics, dashboards or alerts. Metric namespaces remain; review the affected displays and alert rules. Metric changes, Console metrics
B04 · Additional response fields
Some copy, multipart and Console responses include checksum or session fields.
Reading those API responses. Standard clients usually handle them; parsers rejecting unknown fields belong in O05. Multipart responses, copy responses, Console API

🟠 Conditional checks: 8 categories

If the condition applies, check the entry. These are not necessarily rare: deployment naming affects migrating administrators, while custom signing mainly affects custom clients.

Category and change When it applies Impact and action Details
O01 · Installation and startup
Artifacts become silo / mcli; verify services, images, directories and permissions.
Migrating MinIO packages, containers, systemd or Helm. Administrators perform a deployment migration check; application code usually stays the same. Containers, packages and accounts, client configuration
O02 · Custom authorization policies
Password changes, permanent version deletion and some bucket operations use corrected authorization rules.
Custom Allow/Deny rules, object ARNs granting bucket operations, or source-IP conditions. Effective permissions may change; verify policies and proxy trust. Passwords, version deletion, bucket authorization, proxy trust
O03 · Older auth and notification settings
Legacy authentication, database notifications and some TLS/environment-file usage need adjustment or validation.
OIDC HMAC tokens, discrete legacy database settings, old proxies/TLS or unusual environment files. Login, notifications or startup may fail; migrate the relevant configuration. OIDC algorithms, database connections, TLS, environment files
O04 · Programs relying on old bugs
Validation, conditions, errors, exit codes and listing limits change on affected paths.
Expecting invalid requests to succeed, If-Match to be ignored, or more than 1,000 multipart uploads per page. Check error handling, retries, pagination and final batch exit codes. Checksum errors, conditional deletion, multipart listing, CLI exit codes
O05 · Custom clients and administration tools
Private APIs, signed-header coverage, Console automation and Go package paths have changed.
Using ReadMultiple, custom signing, strict parsing, Go embedding or customized Console clients. Verify custom integrations and builds separately; ordinary S3 SDKs do not use the private storage API. Private APIs, signing, Console API, Go modules
O06 · Multi-pool conditions and strict multipart listing
Multi-pool writes/deletes verify metadata more strictly; strict multipart listing needs upgrade preparation.
Multi-pool conditional writes, specific-version deletion or explicitly enabling strict listing. Failures can return 503 while GET still works; strict needs all writers upgraded and old uploads drained. The default remains legacy. Multi-pool conditions, strict-mode contract
O07 · Replication, mixed versions and rollback
IAM revocations and bucket-configuration deletion state require coordinated upgrades and recovery.
Multiple sites, shared IAM, mixed versions or downgrades. Preserve a complete recovery point and test all peers; replacing the binary alone is not a rollback guarantee. IAM upgrades, configuration convergence, rollback scope
O08 · Self-update and upstream online services
In-place updates, SUBNET and upstream hosted-support integrations are disabled.
Using admin update, mcli update or MinIO online support workflows. Upgrade through packages, images or orchestration; ordinary S3 access is unaffected by this change. Server updates, client updates, SUBNET

Comparison scope and release boundaries

The server comparison starts at upstream source 27742d469462, dated 2025-12-03. The commonly referenced final upstream release tag is dated 2025-10-15; these are different comparison points. See the Console and client pages for their separate baselines. This index covers APIs, capabilities, observable behavior and operations; one fix can affect several scenarios.

Upstream MinIO/MC compatibility is best effort. The supported, release-tested combination is SILO + SILO Console + mcli + silo-pkg. Retained protocols, environment variables and storage layouts do not guarantee arbitrary upstream mixed-version operation or downgrades. The detailed server audit retains historical baselines and individual findings; the component matrix separates published components from unreleased source.

The experimental access-frequency pool tiering that was added and later withdrawn is outside these 24 categories: it was not an upstream feature at the fork and never shipped in a public Server release: 20260903 predates it, and it was removed before 20260916. Ordinary lifecycle expiration, remote tiering, rebalance and pool decommission remain available.

For migration, select the relevant O01–O08 conditions, then follow the migration guide.

Component Versions

Published SILO releases, source fixes verified on September 16, and coordinated upgrade requirements.

Password Permissions

Version boundaries and migration for the ChangeMyPassword and CreateUser policy split.

Access-Tiering Removal

Why the opt-in GET-frequency pool-tiering feature was removed, how to migrate builds that contained it, and what the upgrade acceptance did and did not prove.

Migrate from MinIO to Silo

What changes, what stays, and how to switch a container deployment. Package installations are covered in Native Package Migration.

Silo vs. MinIO Server Compatibility

A code-verified compatibility audit of the Silo server fork: binaries, configuration, S3 and admin behavior, storage internals, packaging, containers, and Helm.

MCLI Client Compatibility Notes

Compatibility, behavior changes, installation, and the current pgsty/mc release

Native Package Migration

How the silo RPM/DEB packages differ from the minio packages: file layout, service account, takeover semantics, and caveats.

Console Compatibility Notes

Differences between SILO Console and the upstream MinIO Console

Feature Notes

Design notes for capabilities Silo adds beyond upstream MinIO — written down before they ship.