MinIO befindet sich im Wartungsmodus. Was jetzt? Die besten selbst gehosteten S3-Alternativen im Überblick

Wer sich mit Self-Hosting beschäftigt, ist mit ziemlicher Sicherheit schon einmal auf MinIO gestoßen. Es war eine der Standardlösungen für S3-kompatiblen Objektspeicher, schlank, leistungsstark und enterprise-tauglich, im Hobby-Homelab genauso wie in ernsthaften Produktionsumgebungen. Als MinIO dann in seinem GitHub-README beiläufig die Bombe platzen ließ, dass die Open-Source-Version in den „Wartungsmodus" wechselt, kam die Reaktion sofort und laut: Frustration, Verwirrung und hektisches Umplanen.

Für die Self-Hosting-Community war das mehr als ein technischer Einschnitt, es fühlte sich wie Verrat an. Ein Projekt, das auf der Kraft und Begeisterung seiner Open-Source-Community gewachsen war, hatte genau die Menschen, die es großgemacht hatten, praktisch geghostet.

Was also jetzt?

Was genau hat MinIO gemacht?

Im letzten README-Update kündigte MinIO an, im Open-Source-Repo keine Änderungen mehr anzunehmen und keine Issues mehr zu bearbeiten. Kritische Sicherheitsfixes werden vielleicht noch geprüft, wenn man Glück hat. Wer MinIO ernsthaft einsetzt, besonders bei Workloads mit Internetanbindung, sollte bei diesem „vielleicht patchen wir das" sehr hellhörig werden.

Spontan kam der Schritt offenbar nicht. Langjährige Nutzer sahen schon länger Anzeichen, vom Entfernen der Web-GUI aus der Open-Source-Version bis zum wachsenden Fokus auf AIStor, den kommerziellen Closed-Source-Fork. Dieser Fork ist laut Nutzern in bestimmten Fehlerfällen auf subtile Weise inkompatibel mit MinIO, was die Migration chaotisch macht und das Vertrauen noch mehr beschädigt.

Kurz gesagt: Wer MinIO benutzt hat, weil es offen, transparent und von der Community getragen war, für den ist dieser Zug abgefahren.

Update: Die Situation eskalierte weiter. Am 13. Februar 2026 wurde das MinIO-Open-Source-Repository vollständig archiviert, womit auch Issues und Pull Requests endgültig vorbei sind. Wie sich das speziell für Kubernetes-Nutzer auswirkte, lesen Sie in unserem Follow-up zum Testen K8s-tauglicher S3-Alternativen nach der Archivierung.

Die Community reagiert: Wut, Enttäuschung und Migrationen

Die Reaktionen im Netz kamen sofort und waren, ehrlich gesagt, ziemlich herzzerreißend. „Wir haben für Support bezahlt, um ein großartiges Open-Source-Projekt zu unterstützen, und das ist dabei herausgekommen", schrieb ein Nutzer und verwies auf den gescheiterten Versuch seines Unternehmens, sich bei der Fehlersuche auf MinIOs Open-Source-Wurzeln zu verlassen.

Ein anderer verglich den Schritt mit Broadcoms Strategie, beliebte Tools nach einer Übernahme auszupressen: erst die Community für Goodwill und kostenlose Arbeit melken und sie dann, wenn es passt, hinter eine Paywall sperren.

Der Lichtblick ist, dass die Community nicht untätig herumsitzt. Ganz im Stil des Self-Hostings testen, migrieren und empfehlen die Leute bereits brauchbare Alternativen. Hier ein genauerer Blick darauf, was aus MinIOs Asche aufsteigt.

1. Garage, der überraschende Liebling der Migrationswelle

Garage, entwickelt vom Team bei Deuxfleurs, steht plötzlich im Rampenlicht. Die verteilte Objektspeicher-Lösung ist in Rust geschrieben (für alle Rust-Fans da draußen) und bekommt viel Zuspruch von ehemaligen MinIO-Nutzern. Sie unterstützt S3-APIs, ist ressourcenschonend und mit Docker und Traefik einfach zu deployen. Vielleicht am wichtigsten: Das Projekt wird nach wie vor stark von der Community getragen.

Wer von MinIO migriert, berichtet von solider Performance, gut dokumentiertem Setup und sogar einer sauberen Web-UI, die allerdings schlichter ist als MinIOs poliertes Dashboard. Nachteile gibt es auch: Manche tun sich mit der Zugriffskontrolle noch schwer, und Garages Nutzerbasis ist trotz schnellen Wachstums relativ überschaubar.

Eine praktische Anleitung zur Einrichtung von Garage als MinIO-Ersatz finden Sie in unserem ausführlichen Artikel zur Migration auf Garage.

2. SeaweedFS: leichtgewichtig, praxiserprobt und in Go geschrieben

SeaweedFS taucht ebenfalls immer häufiger auf. Es ist in Go geschrieben, bekannt für seine Skalierbarkeit und kombiniert einen eher traditionellen Dateisystem-Ansatz mit einer robusten S3-kompatiblen Schnittstelle. Ein echtes „Drop-in-Replacement" ist es nicht ganz, kommt aber nah heran, und anders als MinIO wirkt das Team weiterhin dem Open-Source-Modell verpflichtet.

Chunking beherrscht es gut: Große Dateien werden über mehrere Volumes verteilt, und für besonders große Anwendungsfälle gibt es sogar einen eigenen „Large Disk"-Build (bis zu 8 TB pro Volume). Für alle, die mit Mediendateien, Backups oder Machine-Learning-Datensätzen arbeiten, ist das besonders attraktiv.

Die Dokumentation ist stellenweise allerdings dünn, und im Vergleich zu Garage braucht es etwas mehr Tuning. Für alle, die mehr Kontrolle und Flexibilität wollen, ist es trotzdem eine solide Wahl.

3. RustFS: vielversprechend, aber noch nicht ganz produktionsreif

Einige abenteuerlustige Nutzer experimentieren mit RustFS, einer weiteren S3-kompatiblen Storage-Lösung in Rust. Die ersten Eindrücke sind gut: Die Architektur ergibt Sinn, die Performance wirkt solide, und es passt zu der minimalistischen Eleganz, die Rust-Fans schätzen.

Der Haken ist, dass selbst die Entwickler es noch nicht für ganz produktionsreif halten. Wer geschäftskritische Workloads oder großangelegte Backups betreibt, wartet besser, bis sich die Dinge stabilisieren.

Im Auge behalten sollte man RustFS trotzdem, vor allem als Self-Hoster, der gern am Limit lebt und zu Projekten in einer frühen Phase beiträgt.

4. Ceph mit RadosGW für die Hardcore-Storage-Nerds

Wer vor Komplexität nicht zurückschreckt und etwas Bombenfestes will, hat mit Ceph und seinem S3-kompatiblen Rados Gateway (RadosGW) weiterhin eine starke Option. Für schwache Nerven ist das nichts, die Einrichtung von Ceph kann einschüchternd sein. Mit dem nötigen Know-how (oder einem Team, das es hat) bekommt man aber absolut soliden Cluster-Storage mit exzellenter Skalierbarkeit und Redundanz.

Nutzer, die es in Produktion einsetzen, loben Flexibilität und Resilienz. Ceph ist das bevorzugte Backend für Unternehmen und Plattformen, die enterprise-tauglichen Objektspeicher ohne Vendor-Lock-in brauchen. Plug-and-Play ist es allerdings auch hier nicht.

Warum passiert das immer wieder?

Neu ist das, was mit MinIO passiert ist, nicht. Wir haben es schon bei Redis, Terraform, MongoDB und anderen Open-Source-Lieblingen gesehen. Ein Projekt sammelt Goodwill in der Community, wird breit eingesetzt und vollzieht, sobald es enterprise-tauglich ist, eine harte Kehrtwende, um den kommerziellen Umsatz zu schützen.

Frustrierend ist dabei weniger, dass der Code Closed Source wurde. Nutzer haben Zeit, Code und Vertrauen in etwas gesteckt, das sie für einen Teil des offenen Web hielten. Wird das abgeschaltet, fühlt es sich weniger nach einer Repo-Änderung an als danach, ausgenutzt worden zu sein.

Trotzdem machen wir weiter, denn vollständiger Lock-in ohne Transparenz und ohne Kontrolle wäre noch schlimmer.

Wie geht es weiter: Was sollten Sie tun?

Wenn MinIO in Ihrem Homelab noch läuft und tut, was Sie brauchen, besteht kein Grund zur Panik, es funktioniert ja weiterhin. Machen Sie sich aber klar, dass es für die Open-Source-Community eine Sackgasse ist, mit keinen neuen Features, fragwürdigen Sicherheitsfixes und einer Zukunft hinter einer kommerziellen Paywall.

Für neue Deployments und alle, die langfristig planen, ist es Zeit weiterzuziehen. Ob Sie Garage wegen der Einfachheit wählen, SeaweedFS wegen der Leistung oder Ceph wegen des Enterprise-Maßstabs: Behalten Sie die Hoheit über Ihren Stack und halten Sie sich Optionen offen. Das Beste am Self-Hosting ist am Ende weniger die Technik als die Freiheit.

MinIOs Geschichte ist noch nicht zu Ende, aber die Community hat bereits begonnen, das nächste Kapitel zu schreiben, und nach allem, was wir sehen, könnte es ein besseres werden: leichter, schneller und offener. Was mit MinIO passiert ist, wissen wir inzwischen. Spannender ist die Frage, was wir als Nächstes bauen.