Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Am 13. Februar 2026 hat MinIO Inc. die Community archiviert minio Repository. Das Projekt hatte die Marke von 59.000 Sternen und über einer Milliarde Docker-Pulls überschritten. Die installierte Basis umfasst Kubernetes-Objektspeicher, CI/CD-Artefakt-Repositorys, ML-Modell-Registries und lokale Data Lakes. All dies läuft nun auf einer Codebasis, für die keine Sicherheitspatches mehr vom Upstream bereitgestellt werden.
Für Teams, die sich für MinIO entschieden haben, um S3-kompatiblen Objektspeicher auf ihren eigenen Servern zu betreiben, stellt sich nun die praktische Frage, wo sie weiterhin Support und Sicherheitsupdates für MinIO erhalten können, da der Support durch den Upstream-Entwickler nicht mehr angeboten wird. In diesem Beitrag wird erläutert, was sich geändert hat, welche realistischen Optionen es gibt und wie sich der „Endless Lifecycle Support“ von TuxCare in dieses Bild einfügt.
Was hat sich wann geändert?
Der Wandel vollzog sich schrittweise über einen Zeitraum von etwa fünfzehn Monaten.
Anfang 2025 entfernte MinIO Inc. die meisten Verwaltungsfunktionen aus der Webkonsole der Community-Edition und behielt lediglich einen einfachen Objektbrowser bei. Die vollständigen Verwaltungsfunktionen wurden in das kommerzielle Produkt des Unternehmens verlagert. Im gleichen Zeitraum wurden die vorkompilierten Binärversionen eingestellt; die Community-Edition wurde fortan nur noch als Quellcode bereitgestellt.
Am 3. Dezember 2025 versetzte das Unternehmen das Community-Repository in den Wartungsmodus. Die Entwicklung neuer Funktionen wurde eingestellt, und Sicherheitskorrekturen wurden nicht mehr nach einem festen Zeitplan, sondern von Fall zu Fall durchgeführt.
Am 13. Februar 2026 wurde das Repository auf GitHub archiviert. Es ist nun schreibgeschützt: keine neuen Commits, keine neuen Pull-Anfragen und keine weiteren Sicherheitskorrekturen von MinIO Inc. an der Community-Codebasis. Der offizielle MinIO-Support wurde vollständig auf AIStor, den kommerziellen Nachfolger, verlagert.
Für die letzte Community-Version wurden bereits mehrere CVEs bekannt gegeben, darunter CVE-2026-39414, CVE-2026-34204, GHSA-9c4q-hq6p-c237 und GHSA-hv4r-mvr4-25vw. MinIO Inc. hat für einige dieser Probleme Korrekturen in AIStor bereitgestellt, doch es gelangen keine Patches in die archivierte Community-Codebasis, auf der die bestehenden Installationen laufen. Für Teams, die ihre bestehende Bereitstellung beibehalten möchten, stellt dies eine klare Lücke im MinIO-Support dar.
Warum dies für Betreiber wichtig ist
Jedes Team, das MinIO im Produktivbetrieb einsetzt, sieht sich zwei Herausforderungen gegenüber.
An erster Stelle steht die Einhaltung gesetzlicher Vorschriften. PCI DSS, HIPAA, SOC 2 und FedRAMP schreiben alle Fristen für die Behebung bekannter Schwachstellen vor – in der Regel 30 Tage für Befunde mit hohem Schweregrad, manchmal auch weniger. Eine „fallbezogene“ Vorgehensweise im Vorfeld war für diese Fristen bereits eine knappe Angelegenheit. Ein archiviertes Repository ohne weitere Korrekturen ist von vornherein zum Scheitern verurteilt. Sobald eine neue CVE-Kennung vorliegt und die Frist zu laufen beginnt, häufen sich die Prüfungsfeststellungen.
Der zweite Punkt ist die Risikoeskalation. Jede neue CVE, die nach der letzten Community-Version bekannt wird, erschwert es, die Betriebslage intern zu verteidigen. Sicherheitsteams eskalieren das Problem. Die Risikoregister wachsen. Auch Untätigkeit hat ihre eigene Frist, die durch das nächste Audit vorgegeben wird.
Die zur Debatte stehenden Optionen
Betreibern, die derzeit MinIO einsetzen, stehen vier realistische Wege offen.
| Option | Kosten | Was dafür erforderlich ist | Abwägung |
|---|---|---|---|
| Bleiben Sie bei der archivierten Version | $0 | Nichts | Die Gefahr von CVE-Schwachstellen nimmt zu; unter den meisten Compliance-Regelungen nicht tragbar |
| Auf AIStor umsteigen | Angaben ab ca. 96.000 $/Jahr für ≤ 400 TiB nutzbaren Speicherplatz + Migrationskosten | Produktmigration, neue Lizenzierung, Umschulung | Anderes Produkt, anderes Geschäftsmodell |
| Auf eine Open-Source-Alternative umsteigen | Entwicklungszeit | Datenübertragung, Überprüfung der S3-Kompatibilität, Rezertifizierung | Großprojekt; eine Eins-zu-eins-Ersetzung ist keine Alternative |
| Ein Wartungsprogramm eines Drittanbieters abonnieren | Abonnementgebühr | Das bestehende MinIO weiter ausführen | Das hängt vom Umfang des Programms und vom Durchführungsmodell ab |
Zu den Open-Source-Alternativen, die eine engere Auswahl wert sind, gehören SeaweedFS, Garage, RustFS und Ceph RGW. Bei jedem handelt es sich um ein echtes Projekt mit aktiven Betreuern und einer anderen Architektur als MinIO. Keines davon ist ein direkter Ersatz.
Die vierte Option – MinIO-Support durch Drittanbieter – umfasst Programme, die auf dem Community-Quellcode aufbauen und diesen weiterentwickeln. Ihr Umfang, ihr Bereitstellungsformat und ihre Leistungen variieren. Der „Endless Lifecycle Support“ (ELS) von TuxCare für MinIO ist ein solches Programm. Im weiteren Verlauf dieses Beitrags wird erläutert, was es bietet und wie es sich von den Alternativen unterscheidet.
Was ELS für MinIO bietet
Der „Endless Lifecycle Support“ von TuxCare für MinIO ermöglicht es Kunden, weiterhin die MinIO-Codebasis zu nutzen, die sie bereits einsetzen. Patches werden als Binärpakete (RPM-, DEB- und Go-Binärdateien) bereitgestellt, die sich nahtlos in bestehende VM-, Bare-Metal- und On-Prem-Bereitstellungen integrieren lassen, ohne dass die Laufzeitumgebung neu gestaltet werden muss.
Jedes Abonnement umfasst:
- Schnelle SLA-gestützte Reaktion auf CVEs, solange der Kunde die unterstützte Version benötigt
- Umfassende Abdeckung sowohl direkter als auch transitiver Abhängigkeiten ohne zusätzliche Kosten
- Getestete Updates, die die Kompatibilität mit bestehenden Installationen gewährleisten
- Plug-and-Play-Integration in bestehende Arbeitsabläufe und CI/CD-Pipelines
- Signierte, manipulationssichere Updates aus von TuxCare gehosteten Repositorys
- Mit jeder aktualisierten Version wird eine Software-Stückliste (SBOM) ausgeliefert. Da MinIO eine Go-Binärdatei mit eingebundenen Abhängigkeiten ist, bietet die SBOM Betreibern und Prüfern ein einheitliches, verbindliches Verzeichnis dessen, was tatsächlich in jeder Version enthalten ist.
- Der „Vulnerability Exploitability eXchange“ (VEX)-Kontext zeigt an, welche CVEs in der SBOM bereits behoben wurden, sodass sich Sicherheitsteams auf die Bereiche konzentrieren können, in denen noch Handlungsbedarf besteht
- Rund-um-die-Uhr-Support durch Experten, einschließlich CVE-Triage, Anfragen nach benutzerdefinierten Patches und Fehlerbehebung
Die Patches werden von den Ingenieuren von TuxCare bereitgestellt und im Rahmen eines SLA-gestützten Zeitplans ausgeliefert. Der Kunde nutzt weiterhin die von ihm validierte Codebasis, wobei der Support für MinIO von einem Anbieter übernommen wird, der die Arbeit kommerziell unterstützt.
Inwiefern sich ELS von anderen MinIO-Supportoptionen unterscheidet
Drei Merkmale bestimmen den Ansatz von ELS bei der Wartung von MinIO.
- Der erste Punkt betrifft das Bereitstellungsmodell. ELS wird als Binärpakete ausgeliefert. Alternative Wartungsprogramme werden ausschließlich als gehärtete Container-Images bereitgestellt, was für Kubernetes-native Umgebungen geeignet ist, jedoch nicht für Bereitstellungen, bei denen MinIO auf VMs, Bare-Metal-Systemen oder vor Ort (On-Prem) ausgeführt wird. Ein Kunde, der MinIO außerhalb von Containern betreibt, kann keine reine Container-Lösung einsetzen, ohne die Bereitstellung neu zu gestalten.
- Der zweite Punkt betrifft den Umfang der Abdeckung. ELS verpflichtet sich, im Rahmen des Standardabonnements Korrekturen sowohl für direkte als auch für transitive Abhängigkeiten zurückzuportieren. MinIO bündelt einen umfangreichen Baum von Go-Abhängigkeiten, und CVEs, die diese eingebundenen Abhängigkeiten betreffen, erfordern regelmäßig nicht unerhebliche Rückportierungen. Diese Arbeit ist Teil der Standardverpflichtung von ELS und stellt keinen kostenpflichtigen Zusatz dar.
- Der dritte Punkt ist die Lieferverpflichtung. Patches werden in einem veröffentlichten, durch eine SLA abgesicherten Rhythmus bereitgestellt, wobei die Reaktionszeiten vom Schweregrad abhängen. Compliance-Rahmenwerke wie PCI DSS, HIPAA, SOC 2 und FedRAMP legen feste Fristen für die Behebung von Mängeln fest, und nur durch einen vorhersehbaren Lieferplan können Betreiber diese Fristen einhalten.
Diese Eigenschaften sind für Betreiber, die MinIO außerhalb von Containern einsetzen, besonders wichtig – vor allem angesichts der Anforderungen an die Compliance.
Was nun?
Wenn Sie MinIO in der Produktion einsetzen und über die Archivierung durch den Upstream-Entwickler hinaus laufenden MinIO-Support benötigen, steht Ihnen ab sofort der „Endless Lifecycle Support“ von TuxCare zur Verfügung.
Erfahren Sie mehr oder wenden Sie sich an unser Team, um Ihre Anforderungen an die Umgebung zu besprechen: https://tuxcare.com/endless-lifecycle-support/minio-eol-support/.
