MinIO alternatives in 2026: self-hosted S3 after the archive

MinIO’s open-source server is no longer maintained: the minio/minio repository on GitHub was archived on 25 April 2026 and is now read-only. The realistic replacements are Silo, a community fork of the same code (AGPL-3.0); SeaweedFS and RustFS (Apache-2.0, with erasure coding); Garage (AGPL-3.0, copies spread across sites); and Ceph RGW for multi-server clusters.

The short version

In short: Silo for the smallest change from MinIO; SeaweedFS or RustFS for erasure coding on one server under a permissive license; Garage for small servers in several cities, without versioning; Ceph for many servers and a team to run them.

Is MinIO still maintained?

Not as open source. MinIO, Inc. now sells AIStor, and the repository’s README history and release notes show the AGPL server being wound down in steps:

• 24 May 2025. A “Breaking Release” deprecated the embedded web console and removed LDAP and OIDC logins, which MinIO said were “now available as part of the AiStor Product.” Blocks & Files reported in June that the community console had lost its administration features, leaving a basic object browser.
• 15 October 2025. Source-only distribution: “We will no longer provide pre-compiled binary releases for the community version.” The last community release, published on 16 October, fixed a privilege-escalation vulnerability.
• 3 December 2025. “Maintenance Mode”: no new features or pull requests, with critical security fixes “evaluated on a case-by-case basis.”
• 23 December 2025. MinIO announced three AIStor tiers: Free (single node), Enterprise Lite (multi-node, below 400 TiB) and Enterprise.
• 12 February 2026. The notice became “THIS REPOSITORY IS NO LONGER MAINTAINED,” pointing to AIStor Free and AIStor Enterprise.
• 25 April 2026. GitHub shows the repository as “archived by the owner on Apr 25, 2026. It is now read-only.”

Existing installations keep running and the code stays available under the AGPL, but no community release has shipped since October 2025, and an archived repository gets no fixes. Anything reachable from the internet should move to a maintained build or to another server.

For a single machine, MinIO’s own answer is AIStor Free: a “full-featured, single-node deployment architecture” with erasure coding, no artificial capacity limit and community support only. It costs nothing, but it is not the AGPL code: its license “limits any redistribution or resale of the AIStor software,” and running several nodes requires a paid tier.

Silo: the community fork of MinIO

Pigsty, which uses MinIO as its PostgreSQL backup repository, forked the server as pgsty/minio on 25 October 2025 and renamed it pgsty/silo on 6 August 2026. It calls Silo “an independent, community-maintained fork,” not affiliated with MinIO, Inc. It ships what upstream stopped shipping: binaries for Linux, macOS and Windows, multi-arch containers, RPM, DEB and APK packages, security fixes with published advisories, and the full web console. It keeps the S3 API and the storage format, including MINIO_* variables and .minio.sys data, and its migration guide covers taking over an existing minio.service.

Its compatibility audit lists the differences. The executable is now silo; twelve bucket-level actions, policy, versioning, Object Lock and lifecycle writes among them, no longer match an object-only resource such as bucket/*; OIDC tokens signed with shared secrets are rejected; and in-place self-updates are disabled. Silo is less than a year old and run by one organization: pin versions and keep a rollback path.

Garage vs SeaweedFS vs RustFS vs Ceph RGW

Garage

Garage is “a lightweight geo-distributed data store that implements the Amazon S3 object storage protocol.” It keeps whole copies; erasure coding is one of its stated non-goals. The replication_factor can’t exceed the number of nodes: with 1, “there is no redundancy,” and the documentation reserves it for tests; with 3, each object sits on three nodes, in different zones where possible, and survives the loss of two of them.

The price of that simplicity is S3 coverage: no versioning, no Object Lock, and no bucket policies or ACLs, which Garage replaces with per-key, per-bucket permissions. Lifecycle rules handle only expiration and incomplete multipart uploads. If your backup tool depends on versioning or immutability, look elsewhere.

SeaweedFS

SeaweedFS runs a master, volume servers, a filer and an S3 gateway. Replication is set per volume with a three-digit code for extra copies in other data centers, racks and servers; 000 keeps a single copy. Erasure coding uses 10 data and 4 parity shards: 1.4 times the data size, surviving the loss of any 4 shards, with custom ratios reserved for the Enterprise version. It applies to warm data: writes land in normal volumes, and a background worker, on by default, encodes a volume once it is 80% full and has been quiet for five minutes. With fewer than four servers, erasure coding protects against drive failures; with four or more, against server failures.

The S3 gateway supports versioning, Object Lock, bucket policies, lifecycle expiration without storage-class transitions, SSE-S3, SSE-KMS, SSE-C, IAM and STS, but not bucket replication, website or notification configuration. SeaweedFS has been developed in the open since 2014.

RustFS

RustFS is the closest to MinIO in design: a Rust server that groups drives into erasure sets and pools following MinIO’s topology rules, with a web console, under Apache-2.0 instead of the AGPL. Its feature table lists versioning, Object Lock, server-side encryption, lifecycle management, bucket and site replication, IAM and OIDC as available. Its documentation describes three modes: one node with one disk (“rely on backups”), one node with several disks (survives up to M failed parity disks), and four or more nodes for production workloads.

Maturity is the real question in any RustFS vs MinIO comparison. RustFS reached 1.0.0 on 16 September 2026, after beta and release-candidate builds, and 1.0.1 on 3 October. Reading MinIO’s on-disk format is still a preview behind a build feature that is off by default, and objects MinIO encrypted can’t be read, so leaving MinIO means copying through the S3 API. Test a release this young with your own workload before it holds the only copy of anything.

Ceph RGW

Ceph’s Object Gateway (RGW) adds an S3 API to a Ceph cluster, which can also serve block and file storage; the code is licensed under LGPL-2.1 or LGPL-3. Objects live in replicated or erasure-coded pools with the host as the default failure domain. The default erasure-code profile is 2+2, and most erasure-coded pools need at least k+m hosts or racks. cephadm’s --single-host-defaults builds a one-machine cluster with two replicas on separate disks, but the documentation calls such clusters “generally not suitable for production.” RGW’s S3 support is extensive, Object Lock included, though bucket replication works only across zones.

S3 features side by side

Replication, erasure coding or RAID on one server

All three spend raw capacity on redundancy, in different proportions:

• Replication keeps whole copies: 2 TB of raw disk per usable terabyte with two copies, 3 TB with three.
• Erasure coding splits each object into k data and m parity shards and survives the loss of any m: (k+m)/k of raw disk per usable terabyte, so 1.5 for 8+4 and 1.4 for 10+4.
• RAID 6 or ZFS RAIDZ2 keeps two parity blocks per group of disks and survives two failed disks per group: n/(n−2) for a group of n disks, so 1.5 for six disks and 1.2 for twelve.

On one machine, copies and shards must land on different drives. Silo, AIStor Free and RustFS stripe every object across an erasure set of drives from the first write: a 12-drive set with 4 parity shards loses nothing with any 4 drives gone. SeaweedFS erasure-codes full volumes, but recent writes wait in ordinary volumes, protected only by their replication setting. Garage counts copies per node, so a one-node Garage keeps a single copy: put its data on RAIDZ2 or RAID 6, or add nodes. Ceph needs the single-host defaults described above. None of them survives the loss of the server itself.

Usable capacity on 88, 264 and 528 TB servers

Our three storage servers use 22 TB hard drives, four, twelve or twenty-four of them, plus two NVMe drives each for the system and metadata:

Decimal terabytes, before filesystem overhead; Linux reports a 22 TB drive as about 20 TiB. Note: on four drives, SeaweedFS’s 14 shards put three or four on each drive, so a second failed drive loses data.

Cost per usable terabyte is the monthly price divided by the usable figure. On the 264 TB server at $469 a month, a usable terabyte costs 2.5 times more with three copies (88 TB) than with 12-disk RAIDZ2 (220 TB), and 8+4 erasure coding makes it 25% cheaper than two copies. Drive count matters as much as raw size: at two-drive fault tolerance, four drives leave half their capacity usable, twelve or more leave two-thirds or more. Rebuilds matter too: refilling a 22 TB drive at an assumed 200 MB/s takes about 30 hours, so we would not run drives this size with less than two-drive fault tolerance.

Self-hosted versus S3, R2 and B2

Public list prices as of October 2026, excluding taxes:

Take 176 TB stored and 50 TB served each month, the usable space of the 264 TB server with 8+4 erasure coding, counting 1 TB as 1,000 GB:

• AWS S3: about $3,920 for storage and $4,300 for data transfer, so about $8,200 a month before requests.
• Cloudflare R2: about $2,640 a month plus operations, with no egress fees.
• Backblaze B2: about $1,220 a month; 50 TB of egress is inside the free allowance.
• One 264 TB server: $469 a month, whatever the traffic.

This is not like for like: AWS says S3 “stores data redundantly across a minimum of 3 Availability Zones by default,” while one server is one machine in one building. For data you can’t lose, compare against two servers in two cities, which on these numbers still costs less than B2. With only a few terabytes and little traffic, B2 or R2 costs less than any dedicated storage server. Our guide to bandwidth billing shows how egress charges grow with volume.

Migrating from MinIO with rclone

If you stay on MinIO’s format, Silo can take over the existing data in place, following its migration guide. For any other server, copy the objects through the S3 API with rclone.

1. Note what won’t be copied. Users, access keys, bucket policies, lifecycle rules and replication settings must be recreated on the new server. In versioned buckets, rclone copies the current version of each object; older versions only appear, as renamed files, with --s3-versions. Object Lock retention can follow with --metadata and the value copy, if the destination supports it.

2. Define both endpoints in ~/.config/rclone/rclone.conf. The source follows rclone’s MinIO example; the destination here is Garage, which takes provider = Other, path-style requests and its own region name. For SeaweedFS use provider = SeaweedFS, and for Ceph provider = Ceph with an empty region.

[old]
type = s3
provider = Minio
env_auth = false
access_key_id = OLD_ACCESS_KEY
secret_access_key = OLD_SECRET_KEY
region = us-east-1
endpoint = http://minio.example.net:9000

[new]
type = s3
provider = Other
env_auth = false
access_key_id = NEW_ACCESS_KEY
secret_access_key = NEW_SECRET_KEY
region = garage
endpoint = http://storage.example.net:3900
force_path_style = true

3. Preview, copy and verify one bucket at a time. With S3 on both sides, rclone’s documentation recommends --checksum.

# buckets on each side
rclone lsd old:
rclone lsd new:

# preview, then copy one bucket
rclone sync old:backups new:backups --checksum --fast-list --transfers 32 --checkers 64 -P --dry-run
rclone sync old:backups new:backups --checksum --fast-list --transfers 32 --checkers 64 -P

# compare sizes and hashes on both sides
rclone check old:backups new:backups

4. Tune and cut over. rclone’s defaults are conservative, so raise --transfers and --checkers and experiment; --fast-list costs about 1 GiB of RAM per million objects. Repeat the sync until little is left, stop writes, run it once more and switch the endpoint. sync deletes destination objects that are missing from the source, so check bucket names twice.

5. Budget the time. Between two different servers, every object is downloaded and re-uploaded by the machine running rclone. At an effective 1 Gbps, 100 TB takes about nine days; at 5 Gbps, under two. The old server’s disks or uplink usually set the pace, not a 10 Gbps destination port.

What one storage server can’t do

• One server is one failure domain. Erasure coding and RAID survive failed drives, not a failed motherboard, power supply or building, or an administrator’s mistake. RustFS’s documentation is blunt about single-node setups: “if the entire server fails or more than M disks are damaged, data will be lost.”
• Redundancy is not a backup. A deleted bucket disappears from every drive at once. Versioning and Object Lock help; an independent copy elsewhere is what makes mistakes recoverable.
• Critical data needs a second site. That can be a second storage server in another city, Amsterdam and Frankfurt for example, filled by a scheduled rclone copy, which never deletes, or by bucket replication. Or a Garage cluster of three 88 TB servers in Amsterdam, Frankfurt and Zürich with replication_factor = 3: one copy per city and about 88 TB usable.

Which server for self-hosted S3 storage

The 88 TB storage server costs $149 a month and is delivered in about 15 minutes in Amsterdam, Frankfurt, Zürich and New York. It suits a Garage node or a backup target, with 44 TB usable at two-drive fault tolerance. The 264 TB server, $469 a month and built within 24 hours in Amsterdam, Frankfurt and New York, has enough drives for 8+4 erasure coding or 12-disk RAIDZ2 on one machine. The 528 TB server, $999 a month and built within 72 hours in Amsterdam and Frankfurt, adds a 24-core EPYC and 256 GB of ECC memory for larger erasure sets.

All three have ECC memory, two NVMe drives, IPMI access and a 10 Gbps unmetered port, so a 100 TB restore costs the same as an idle month. For ZFS or mdadm layouts, see our software RAID guide; for backup designs, storage and backup servers. We are not the right fit for a few terabytes, where B2 or R2 costs less, or for durability across several facilities without operating anything yourself: that is a managed object store’s job.

Sources

• minio/minio, its README history and Releases · minio/minio — MinIO on GitHub
• Introducing New Subscription Tiers for MinIO AIStor: Free, Enterprise Lite, and Enterprise — MinIO, 23 December 2025
• MinIO users complain after admin UI removed from Community Edition — Blocks & Files, 19 June 2025
• pgsty/silo and Silo vs. MinIO Server Compatibility — PGSTY
• Configuration file format, S3 Compatibility status and Goals and use cases — Garage documentation; Deuxfleurs/garage — Forge Deuxfleurs
• Erasure Coding for warm storage, Replication and Amazon S3 API — SeaweedFS wiki; seaweedfs/seaweedfs — GitHub
• rustfs/rustfs — GitHub; Installation — RustFS documentation
• Erasure code, Using Cephadm to Deploy a New Ceph Cluster, Ceph Object Gateway S3 API, Bucket Operations and Ceph Releases (index) — Ceph documentation; COPYING — ceph/ceph on GitHub
• Amazon S3 and rclone sync — rclone documentation
• AWS Price List: Amazon S3, US East (N. Virginia), published 14 October 2026; AWS Price List: data transfer, US East (N. Virginia), published 16 September 2026; Object Storage Classes — Amazon Web Services
• Pricing — Cloudflare R2 docs, last updated 1 October 2026
• B2 Cloud Storage Pricing — Backblaze, checked October 2026