MinIO-Repository wird nicht länger gewartet

 (github.com/minio)
2 Punkte von GN⁺ 2026-02-14 | 1 Kommentare | Auf WhatsApp teilen
  • Die Datei README.md wurde geändert und weist nun ausdrücklich darauf hin, dass das Projekt nicht länger gewartet wird
  • Die bisherige Formulierung zum „Maintenance Mode“ wurde entfernt und stattdessen die Warnung „THIS REPOSITORY IS NO LONGER MAINTAINED“ hinzugefügt
  • Am Anfang des README werden zwei alternative Optionen genannt: AIStor Free und AIStor Enterprise
  • Fehlerhafte Links in der Dokumentation wurden korrigiert, und die URL des Slack-Kanals wurde richtiggestellt
  • Durch diese Änderung wird bestätigt, dass das Open-Source-Repository von MinIO in den schreibgeschützten Archivstatus versetzt wurde

Wichtige Änderungen in README.md

  • Der bisherige Abschnitt „Maintenance Mode“ wurde vollständig entfernt und durch einen neuen Kommentarblock ersetzt

    • Der neue Block enthält die Formulierung „THIS REPOSITORY IS NO LONGER MAINTAINED“
    • Unter dem Punkt „Alternatives“ werden zwei Ersatzprodukte genannt
      • AIStor Free: kostenlose eigenständige Version für die Community
      • AIStor Enterprise: Distributionsversion mit kommerziellem Support

  • Der bisherige Link zu Hinweisen zum AIStor-Abonnement in der Dokumentation wurde entfernt und durch eine knappe Alternativbeschreibung ersetzt

Weitere Korrekturen und Bereinigungen

  • Der Slack-Link wurde von https//slack.min.io auf https://slack.min.io korrigiert
  • Im Beispiel für Umgebungsvariablen wurde der Tippfehler (GOARCh) zu GOARCH korrigiert
  • Im AGPLv3-Lizenztext wurde der Rechtschreibfehler (liabilites) zu liabilities korrigiert
  • Im Abschnitt „Legacy Binary Releases“ wurde eine Leerzeile eingefügt, um die Lesbarkeit zu verbessern

Repository-Status

  • Oben auf der GitHub-Seite erscheint der Hinweis: „This repository was archived by the owner on Feb 13, 2026. It is now read-only.“
  • Das bedeutet, dass das Repository archiviert wurde und keine Änderungen oder Beiträge mehr möglich sind

Bedeutung

  • Mit der README-Änderung wurde das Repository offiziell in den Status Wartungsende und Archivierung überführt
  • Anstelle der Open-Source-Version von MinIO wird auf die Produktfamilie AIStor Free/Enterprise verwiesen
  • Community-Support bleibt weiterhin über GitHub und Slack auf Best-Effort-Basis bestehen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-14
Hacker-News-Kommentare

  • Ich finde es nicht problematisch, dass MinIO Open Source aufgegeben hat.
    Weltweit gibt es einfach zu viele Nutzer, die es nur kostenlos verwenden.
    Ich habe seit einigen Monaten Alternativen getestet und denke, dass nach MinIO RustFS gewinnen wird.
    Ich habe Garage, SeaweedFS, Ceph und RustFS verglichen; RustFS und SeaweedFS waren am schnellsten, und bei RustFS waren Installation und Konsole am bequemsten.
    Ceph ist so komplex, dass es schwer bereitzustellen ist, wenn man den Quellcode nicht tiefgehend versteht.
    Es gibt auch Kritik, dass die CLA von RustFS ein „Köder“ sei, aber ich halte sie nicht für überzogen, da sie ein Mittel ist, rechtliche Risiken zu verringern.
    Auch bei Milvus wurde RustFS hoch bewertet, und anhand technischer Kennzahlen glaube ich, dass RustFS am Ende gewinnen wird.
    Bewertung von RustFS durch Milvus

    • Als Maintainer von Milvus möchte ich ein paar Gedanken teilen.
      Das Problem mit kostenlosen Nutzern existiert tatsächlich und wird im KI-Zeitalter noch gravierender.
      Viele Nutzer verwenden ein Projekt kostenlos, aber nur ein sehr kleiner Anteil wird zu zahlenden Kunden.
      Milvus braucht für Stabilität und Performance besseren Object Storage, und RustFS ist ein aussichtsreicher Kandidat.
      Langfristig müssen wir aber auch in Erwägung ziehen, selbst etwas zu bauen, falls das Ökosystem das nicht erfüllen kann.
      Es braucht eine Nachhaltigkeitsdebatte über Open-Source-Lizenzmodelle.
      Das Modell aus der Apache-2.0-Ära zeigt Grenzen, und der Ansatz, einfach darauf zu hoffen, dass Unternehmen Unterstützung leisten, funktioniert nicht mehr.
      Die Entscheidung von MinIO ist als Signal dieses Wandels bemerkenswert.
    • Ich betreibe Ceph in einem k8s-Cluster mit vier Nodes, jeweils mit zwei 4-TB-SSDs.
      Die Einrichtung war komplex, aber jetzt ist es sehr stabil.
      Claude Code ist hervorragend für die Ceph-Verwaltung und erledigt auch Recovery oder Anpassungen an der CRUSH-Map einfach.
      Die Aussage „Ohne tiefes Verständnis des Quellcodes kann man es nicht deployen“ halte ich für übertrieben.
      Wenn Ceph zum Einsatzzweck passt, würde ich es auf jeden Fall empfehlen.
    • Die Installation von Garage ist sehr einfach.
      Man installiert ein einzelnes Binary und schreibt nur die Konfigurationsdatei /etc/garage.toml.
      Man kann es mit garage server starten oder eine KI ein Init-Skript schreiben lassen.
      Auch AIStore von NVIDIA ist ein hervorragendes S3-kompatibles System, siehe offizielle AIStore-Website.
      Es ist schneller als MinIO, aber bei der Platzeffizienz etwas schwächer.
      SeaweedFS wirkt stark wie ein persönliches Projekt, und wenn man nicht häufig Backups macht, ist es riskant.
      RustFS möchte ich wegen des CLA-Themas meiden, weil es wie eine Wiederholung der MinIO-Situation wirkt.
    • SeaweedFS basiert auf dem Haystack-Design von Facebook und ist auf einen speziellen Zweck zugeschnitten, bei dem Metadatenabfragen minimiert werden.
      Es arbeitet volumenbasiert, und auch Updates werden pro Volume durchgeführt.
      Allgemeiner Object Storage wird dagegen auch als Analytics-Backend verwendet und braucht deshalb schnelle Scans.
      SeaweedFS hat daher andere Trade-offs als universeller Object Storage.
    • Es wurde gesagt, die CLA von RustFS reduziere rechtliche Risiken; mich würde interessieren, welche rechtlichen Risiken damit konkret gemeint sind.

  • Als ich einen Open-Source-Service betrieben und dann eingestellt habe, verschwand die chronische Erschöpfung.
    Kostenlos zu arbeiten machte keinen Spaß, und es war auch anstrengend, eine kostenpflichtige Version und eine Community-Version parallel zu pflegen.
    Die Beziehung zu Nutzern, die nicht zahlen, war letztlich nur Stress.
    Es scheint, als habe das MinIO-Team dieselbe Lektion gelernt.

    • Das MinIO-Team hat nicht kostenlos gearbeitet.
      Es ist ein COSS-Modell (Commercial Open Source Software), bei dem die Basisversion kostenlos ist und zahlungspflichtige Funktionen an Unternehmenskunden verkauft werden.
      Der Wechsel zu Closed Source ist einfach eine geschäftliche Entscheidung.
      Ich habe SeaweedFS lange in Production genutzt und betreibe es jetzt zusammen mit Wasabi.
      Für schnellen lokalen Storage ist SeaweedFS weiterhin hervorragend.
    • Es ist selbstverständlich, Geld für ein Produkt zu verlangen, aber es ist problematisch, etwas zuerst als FOSS zu vermarkten und später die Lizenz zu ändern.
      Man hätte den Plan von Anfang an klar kommunizieren sollen.
      Wenn nicht, dann wäre es richtig, die ursprüngliche Zusage einzuhalten.
    • Ich pflege seit Jahren ein Open-Source-Storage-System und mache das immer noch gern.
      Ich betreue eine Storage-Engine namens TidesDB und mache trotz Rückenschmerzen weiter, weil es mir gefällt.
    • Wer ein populäres Open-Source-Projekt nur gründet, um damit Geld zu verdienen, hat den Geist von Open Source nicht wirklich verstanden.
    • Ich bin seit fast 30 Jahren an freier Software beteiligt, und die Erfahrung, mit der Community zusammenzuarbeiten, war sehr erfüllend.
      Das ist zwar subjektiv, aber es kann definitiv Freude machen.

  • Ich bin erfolgreich von MinIO zu Ceph migriert.
    Ich habe auch SeaweedFS getestet, aber mithilfe von Claude bei der Bug-Analyse zeigte sich, dass die Code-Struktur chaotisch war.
    SeaweedFS sollte man niemals für etwas anderes als Tests verwenden. Das Risiko von Datenverlust ist groß.

    • SeaweedFS ist ein altes Projekt; vielleicht hast du einfach nur Spuren einer Legacy-Codebasis gesehen.
    • Ceph ist das OG unter den Object-Storage-Systemen.
      Es gab viele Versuche für Alternativen, aber letztlich löst Ceph die Komplexität des Problems am besten.

  • Ich migriere MinIO derzeit auf Ceph.
    Ich habe mit cephadm einen Ceph-Cluster aus drei Servern aufgebaut und repliziere 120 TB Daten mit 420 MB/s.
    Ceph ist komplexer als MinIO, aber skalierbar und stabil.
    Schade ist, dass die Konsole von MinIO verschwunden ist.
    Ich habe mich für Ceph entschieden, weil Elasticsearch die S3-Snapshots von Garage nicht mag.

    • Ceph ist komplex, aber die Konsensschicht ist sehr robust.
      Man muss nur darauf achten, dass die Festplatten der Nodes nicht volllaufen.

  • Es ist bemerkenswert, wie viele Leute jetzt hektisch Alternativen testen, die sich in Production noch nicht bewährt haben.
    Das eigentliche Risiko bei Infrastrukturabhängigkeiten ist nicht Closed Source, sondern die Wechselkosten.
    Selbst bei S3-Kompatibilität dauert eine echte Migration wegen kleiner Unterschiede Wochen bis Monate.
    Ich frage mich, wie viele MinIO-Nutzer tatsächlich einen Migrationsplan dokumentiert haben.

  • Als Alternative zu MinIO wurde AIStore genannt.
    Daneben gibt es noch mehrere Open-Source-Alternativen:
    Garage, RustFS, SeaweedFS, Supabase Storage, Scality Cloudserver, Ceph

    • Ich bin der Autor von Filestash.
      Es bietet ein S3-Gateway und proxyt S3-Aufrufe zu SFTP, FTP, NFS, SMB, IPFS, Dropbox, Google Drive usw.
      Es ist vollständig stateless und kann mit verschiedenen Backends verbunden werden.
    • RustFS hat viele Funktionen und kann auch eigenes Key-Management bereitstellen, ist aber noch in Entwicklung.
      Im Code sind bereits Vorbereitungen für einen späteren Lizenzwechsel vorhanden.
      Ceph kommt dem S3-Funktionsumfang am nächsten, ist aber komplex einzurichten und empfindlich bei Latenz.
      Garage eignet sich gut für einfache Speicherung, aber es fehlen erweiterte S3-Funktionen wie ACLs oder Einschränkungen auf Pfadebene.
      Das Clustering ist WAN-freundlich und braucht im Gegensatz zu Ceph keine rackbasierte Konfiguration.
    • Ich habe außer MinIO auch Garage und Ceph verwendet, brauche aber einfach nur ein simples S3-Dateisystem für lokale Tests.
      So eine einfache Alternative scheint es bisher nicht zu geben.
    • Ich nutze SeaweedFS auf einer einzelnen Maschine als S3-kompatiblen Storage.
      Die Management-Funktionen sind schwach, aber bei der Datenintegrität vertraue ich Ceph mehr.
      Ceph wirkt wie etwas, das von Leuten gebaut wurde, die verteilte Systeme wirklich verstehen.
    • Ich habe die obige Alternativliste als Pull Request zum MinIO-Repository hinzugefügt.
      PR-Link

  • Wenn man sich den früheren HN-Thread ansieht, konnte man bereits erkennen, dass MinIO in den Maintenance-Modus gewechselt war.
    Damit war der Übergang zu Closed Source im Grunde schon angekündigt.

    • Maintenance-Modus und „wird nicht mehr gewartet“ sind aber nicht dasselbe.

  • MinIO war schon vorher nicht besonders transparent und stand dem Open-Source-Geist fern, etwa durch das Löschen kritischer Issues oder das Sperren von Kommentaren.
    Deshalb bin ich sofort zu Garage gewechselt, als es in den Maintenance-Modus ging.
    Ich bereite einen PR vor, habe ihn aber noch nicht eingereicht.

    • Solche Projekte erfordern fortgeschrittenes Know-how, deshalb sehe ich keinen Grund, sich mit kostenlosen Nutzern zu befassen.
      Die meisten ernsthaften Open-Source-Projekte werden von der Industrie unterstützt, und für normale Webentwickler ist es schwer, dazu beizutragen.

  • Es ist ratsam, für den Fall einer Löschung des MinIO-Repositories einen Fork anzulegen und lokal aufzubewahren.
    Öffentliche Repositories auf GitHub lassen Forks bestehen, wenn sie gelöscht werden; werden sie aber privat geschaltet, verschwinden auch die Forks.
    Im Ruby-Ökosystem gab es mit dem Gem prawn_plus einen ähnlichen Fall.
    Siehe dazu die Dokumentation zur GitHub-Fork-Policy.
    Für Leute, die MinIO nur für lokale Tests nutzten, könnte das zu einer sich langsam schließenden Falle werden.

  • Wer Observability-Lösungen wie Thanos, Loki, Mimir oder Tempo betreibt, die Object Storage benötigen,
    sollte stattdessen VictoriaMetrics, VictoriaLogs und VictoriaTraces in Betracht ziehen.
    Diese basieren auf Block Storage, skalieren bis in den Petabyte-Bereich und bieten hohe Performance und Verfügbarkeit ohne Bedarf an manueller Verwaltung.