MinIO is archived: self-hosted S3-compatible storage compared

Do you run MinIO as a backup target or application storage? WZ-IT reviews the estate, plans the move to an alternative such as SeaweedFS or RustFS and can provide ongoing operations. Review your setup with us

For years MinIO was the default answer to self-hosted S3-compatible storage. That answer no longer holds: the public repository is archived and the last push dates from 24 April 2026.

This affects many installations that run quietly and reliably and therefore go unnoticed. We recommended MinIO ourselves in our own articles on S3 migration to Hetzner. That recommendation no longer stands, and this article draws the conclusion.

It sets out what exactly happened, how urgent a move is and which alternatives hold up. All figures from the repositories, as of 28 August 2026.

Table of contents

• What happened to MinIO
• How urgent is a move
• The alternatives at a glance
• SeaweedFS
• Garage
• RustFS
• Ceph
• The often better answer: do not self-host
• What actually takes work in a move
• How we approach this at WZ-IT
• Further guides

What happened to MinIO

The retreat ran in three steps over roughly a year:

The last push to minio/minio dates from 24 April 2026. For comparison: SeaweedFS, RustFS and Ceph were all updated on 24 August 2026, the day this article was researched.

The company itself is active and continues to develop its commercial product AIStor. What ends is the freely available edition.

How consequential that break was for other projects shows in a decision from outside: Kubeflow Pipelines switched its default object storage to SeaweedFS after MinIO's retreat.

How urgent is a move

Archived software does not become insecure overnight. It becomes insecure with the first vulnerability nobody publishes a fix for. Urgency therefore depends on exposure, not on the date.

What applies in every case: inventory the estate. Anyone who does not know where MinIO runs cannot answer the question. In grown environments it often sits in three places, two of which nobody remembers.

The alternatives at a glance

Figures from the public repositories, as of 28 August 2026.

Garage is not developed on GitHub but on the Deuxfleurs collective's own infrastructure; the star count is therefore absent and would not be comparable anyway.

SeaweedFS

SeaweedFS is the obvious choice for most MinIO installations. It has existed for over ten years, is under Apache-2.0, has many contributors and is actively maintained.

It is designed for distributed storage with particular strength in handling many small files, a case where classic object stores often struggle. The S3 API is mature.

Kubeflow Pipelines switching to SeaweedFS as its default is the most solid viability signal a project in this position can receive: an outside decision, made under time pressure, affecting many installations.

Garage

Developed by the Deuxfleurs collective, under AGPL-3.0, deliberately lean. The target case is multiple sites holding data redundantly without needing a system of Ceph's complexity.

Strength: low resource requirements, simple commissioning, designed for geographic distribution. Limit: a smaller ecosystem, fewer published solutions for edge cases, no web interface on MinIO's scale.

RustFS

RustFS is the youngest candidate, written in Rust, under Apache-2.0 and with a built-in web interface. It positions itself explicitly as what MinIO used to be before its licence and feature trajectory.

At 31,347 stars it has drawn attention quickly. For migration it offers the most familiar interface. The limitation is age: a project that has existed for a short time has fewer production years behind it than SeaweedFS or Ceph, and that is exactly what counts in a storage system.

Anyone moving because a project was abandoned should weigh durability at the successor, not just familiarity.

Ceph

Not a lean replacement but a complete distributed storage system for block, file and object storage. S3 access runs through the RADOS Gateway.

Ceph makes sense in exactly one case: when it already runs. Anyone operating a Ceph cluster for virtual machines under Proxmox gets object storage without an additional system on top.

For pure S3 needs without an existing Ceph, the effort is disproportionate. Resource requirements are considerably higher than the lean alternatives, and operational complexity is another order of magnitude.

The often better answer: do not self-host

Part of the MinIO estate exists only because an S3 endpoint was needed and MinIO was quick to set up. For that case the most honest advice is not to replace the operation but to hand it over.

Object storage at a European provider such as Hetzner costs little, creates no operational effort and settles the update question permanently. How to set that up with Hetzner Object Storage we described for AWS S3 and Azure Blob Storage.

Self-hosting remains right when data must not leave the premises, when volumes are very large, or when storage has to sit inside an isolated environment.

What actually takes work in a move

The data has to be copied. All candidates speak S3, but none reads MinIO's storage format. The move runs through rclone or an equivalent from endpoint to endpoint. The space has to exist twice or the work has to be staged.

The edges of the S3 API are not the same everywhere. Versioning, object locking, lifecycle rules and server-side encryption are supported to differing degrees. If you use any of them, check before the selection, not after.

Credentials and policies are recreated. Users, keys and access rules do not transfer. That is manageable when there are few and tedious when years have produced many.

Backups are a special case. Where MinIO serves as the target of a backup system, for instance for Proxmox Backup Server, a restore test from the new target belongs to the move. A backup not verified after a migration is not a backup.

How we approach this at WZ-IT

We recommended MinIO in our own articles and are correcting that. Those articles get a note rather than standing as if nothing had happened.

For existing installations we ask first about exposure and purpose, not about the successor. An internal backup target has a different urgency than an endpoint at the network edge.

In selection we lean toward SeaweedFS, because production years weigh more in storage systems than interface familiarity. Where Ceph already runs we use its RADOS Gateway rather than placing a second system beside it. And in a good share of cases we recommend not operating object storage at all.

A move always includes a restore test from the new target before the old one is switched off.

Further guides

• Migrating AWS S3 to Hetzner Object Storage - the route to hosted object storage
• Migrating Azure Blob Storage to Hetzner - the same from Azure
• Proxmox Backup Server with S3 storage - object storage as a backup target
• Ceph under Proxmox - when the storage cluster already exists
• Managed operations - operations, monitoring and tested restores

Do you know everywhere MinIO runs in your estate? We inventory it, assess urgency and support the move including a restore test. Book a call

Sources

• MinIO on GitHub
• SeaweedFS on GitHub
• RustFS on GitHub
• Ceph on GitHub
• Garage: project site
• rclone: documentation