El repositorio de MinIO ya no recibe mantenimiento

• Se modificó el archivo README.md para dejar explícito que el proyecto ya no recibe mantenimiento
• Se eliminó la frase anterior de “modo de mantenimiento” y, en su lugar, se agregó la advertencia "THIS REPOSITORY IS NO LONGER MAINTAINED"
• En la parte superior del README se presentan dos opciones alternativas: AIStor Free y AIStor Enterprise
• Se corrigieron errores de enlaces en la documentación y se ajustó correctamente la URL del canal de Slack
• Con este cambio, se confirma que el repositorio open source de MinIO pasó a estado de solo lectura (archivo)

---

Cambios principales en README.md

• La sección anterior “Maintenance Mode” fue eliminada por completo y reemplazada por un nuevo bloque de comentario

  • El nuevo bloque incluye la frase "THIS REPOSITORY IS NO LONGER MAINTAINED"
  • Debajo del apartado "Alternatives" se indican dos productos alternativos
    • AIStor Free: versión independiente gratuita para la comunidad
    • AIStor Enterprise: versión distribuida con soporte comercial

• Se eliminó el enlace de guía de suscripción relacionado con AIStor que estaba en la documentación anterior y se reorganizó con una explicación alternativa más breve

Otras correcciones y ajustes

• El enlace de Slack se corrigió de https//slack.min.io a https://slack.min.io
• En el ejemplo de variable de entorno, el error tipográfico (GOARCh) fue corregido a GOARCH
• En el texto de la licencia AGPLv3, el error ortográfico (liabilites) fue corregido a liabilities
• En la sección “Legacy Binary Releases” se añadió una línea en blanco para mejorar la legibilidad

Estado del repositorio

• En la parte superior de la página de GitHub aparece el texto: "This repository was archived by the owner on Feb 13, 2026. It is now read-only."
• Esto significa que el repositorio fue archivado y ya no es posible hacer cambios ni contribuciones

Significado

• Junto con la modificación del README, el repositorio pasó oficialmente a estado de fin de mantenimiento y archivado
• En lugar de la versión open source de MinIO, se orienta a migrar a la línea de productos AIStor Free/Enterprise
• El soporte de la comunidad sigue disponible mediante GitHub y Slack bajo un esquema de best-effort

[GN⁺]

Comentarios en Hacker News

• No creo que haya problema con que MinIO haya cerrado el código abierto.
  En todo el mundo hay demasiada gente que solo lo usa gratis.
  Llevo meses probando alternativas y creo que, después de MinIO, RustFS será el ganador.
  Comparé Garage, SeaweedFS, Ceph y RustFS; RustFS y SeaweedFS fueron los más rápidos, y la instalación y la consola de RustFS fueron las más cómodas.
  Ceph es demasiado complejo, así que es difícil desplegarlo si no entiendes el código fuente a fondo.
  También hay críticas de que el CLA de RustFS es un “anzuelo”, pero no me parece excesivo como mecanismo para reducir riesgos legales.
  En Milvus también evaluaron muy bien a RustFS y, viendo los indicadores técnicos, creo que al final RustFS ganará.
  Evaluación de RustFS por parte de Milvus

  • Como maintainer de Milvus, comparto algunas ideas.
    El problema de los usuarios gratuitos es real, y en la era de la IA es todavía más grave.
    Mucha gente usa el proyecto gratis, pero el porcentaje que se convierte en cliente de pago es muy bajo.
    Milvus necesita un mejor object storage por estabilidad y rendimiento, y RustFS es un candidato fuerte.
    Pero a largo plazo, si el ecosistema no cumple con eso, también tendríamos que considerar construir el nuestro.
    Hace falta una discusión sobre sostenibilidad en torno al modelo de licencias open source.
    El modelo de la era Apache 2.0 está mostrando sus límites, y ya no funciona simplemente “esperar que las empresas apoyen”.
    La decisión de MinIO merece atención como una señal de ese cambio.
  • Yo opero Ceph en un clúster de k8s, con 4 nodos y dos SSD de 4 TB en cada uno.
    La configuración fue compleja, pero ahora es muy estable.
    Claude Code es excelente para administrar Ceph, y también resuelve fácil la recuperación o cambios en el mapa CRUSH.
    Me parece exagerado decir que “no puedes desplegarlo si no entiendes el código fuente a fondo”.
    Si Ceph encaja con tu caso de uso, de verdad recomiendo probarlo.
  • Instalar Garage es muy sencillo.
    Solo instalas un binario único y escribes el archivo de configuración /etc/garage.toml.
    Puedes ejecutarlo con garage server o pedirle a una IA que te escriba un script de init.
    AIStore de NVIDIA también es un excelente sistema compatible con S3; se puede ver en el sitio oficial de AIStore.
    Es más rápido que MinIO, aunque un poco menos eficiente en espacio.
    SeaweedFS se siente mucho como un proyecto personal, y si no haces respaldos frecuentes puede ser riesgoso.
    Quiero evitar RustFS porque, por el tema del CLA, parece una repetición del caso MinIO.
  • SeaweedFS está basado en el diseño Haystack de Facebook y está orientado a un propósito específico: minimizar consultas de metadatos.
    Funciona por volúmenes, y las actualizaciones también se hacen a nivel de volumen.
    En cambio, el object storage general suele usarse también como backend para analítica, así que necesita escaneos rápidos.
    Por eso SeaweedFS tiene trade-offs distintos a los de un object storage de propósito general.
  • Dijiste que el CLA de RustFS reduce el riesgo legal, pero me da curiosidad saber exactamente qué riesgos legales reduce.

• Cuando dejé de operar un servicio open source, desapareció esa fatiga crónica que sentía.
  Trabajar gratis no era divertido, y llevar en paralelo la versión paga y la comunitaria también era pesado.
  La relación con usuarios que no pagan terminaba siendo puro estrés.
  Parece que el equipo de MinIO llegó a la misma lección.

  • El equipo de MinIO no trabajaba gratis.
    Su modelo era COSS (Commercial Open Source Software): dar una versión base gratis y vender funciones pagas a clientes empresariales.
    Pasarse a código cerrado fue simplemente una decisión de negocio.
    Yo usé SeaweedFS por mucho tiempo en producción y ahora lo opero junto con Wasabi.
    SeaweedFS sigue siendo excelente para almacenamiento local rápido.
  • Cobrar por un producto es totalmente normal, pero si al principio lo promocionaste como FOSS y luego haces un cambio de licencia, sí me parece problemático.
    Tendrías que haber dejado claro el plan desde el inicio.
    Si no lo hiciste, lo correcto es respetar la promesa original.
  • Llevo años manteniendo un sistema de almacenamiento open source y todavía lo disfruto mucho.
    Administro un motor de almacenamiento llamado TidesDB, y aunque me duela la espalda, me gusta tanto que sigo con ello.
  • Si haces un proyecto open source popular con la intención de ganar dinero, entonces no entendiste de verdad el espíritu del open source.
  • Llevo casi 30 años participando en software libre, y la experiencia de trabajar con la comunidad ha sido muy gratificante.
    Es algo subjetivo, pero sin duda puede ser disfrutable.

• Migré exitosamente de MinIO a Ceph.
  También probé SeaweedFS, pero al analizar bugs con ayuda de Claude, vi que la estructura del código era un desastre.
  No debería usarse SeaweedFS para nada más que pruebas. Hay mucho riesgo de pérdida de datos.

  • SeaweedFS es un proyecto viejo, así que quizá solo viste rastros de una base de código legacy.
  • Ceph es el OG del object storage.
    Ha habido muchos intentos de reemplazarlo, pero al final Ceph es el que mejor resuelve la complejidad del problema.

• Últimamente estoy migrando MinIO a Ceph.
  Armé un clúster de Ceph de 3 servidores con cephadm, y estoy replicando 120 TB de datos a 420 MB/s.
  Ceph es más complejo que MinIO, pero tiene una escalabilidad excelente y es estable.
  Da pena que haya desaparecido la consola de MinIO.
  Elegí Ceph porque a Elasticsearch no le gustan los snapshots S3 de Garage.

  • Ceph es complejo, pero su capa de consenso es muy sólida.
    Eso sí, hay que cuidar que los discos de los nodos no se llenen.

• Me llama la atención que tanta gente esté probando a toda prisa alternativas que todavía no están validadas en producción.
  El verdadero riesgo de una dependencia de infraestructura no es que cierre el código, sino el costo de cambiarse.
  Aunque sea compatible con S3, una migración real puede tomar semanas o meses por diferencias sutiles.
  Me pregunto cuántos usuarios de MinIO realmente tienen documentado un plan de migración.

• Se menciona AIStore como alternativa a MinIO.
  Además hay varias otras alternativas open source:
  Garage, RustFS, SeaweedFS, Supabase Storage, Scality Cloudserver, Ceph

  • Soy el autor de Filestash.
    Ofrece un gateway S3 y hace proxy de llamadas S3 hacia SFTP, FTP, NFS, SMB, IPFS, Dropbox, Google Drive, etc.
    Es completamente stateless y puede conectarse a distintos backends.
  • RustFS tiene muchas funciones, incluso gestión propia de claves, pero todavía está en desarrollo.
    En el código ya hay preparativos para un futuro cambio de licencia.
    Ceph es el más parecido en funciones S3, pero configurarlo es complejo y es sensible a la latencia.
    Garage está bien para almacenamiento simple, pero le faltan funciones avanzadas de S3, como ACL avanzadas o restricciones de rutas.
    Su clustering es amigable con WAN, pero no requiere una configuración por racks como Ceph.
  • Además de MinIO, he usado Garage y Ceph, pero necesito un filesystem S3 simple para pruebas locales.
    Todavía no parece existir una alternativa así de simple.
  • Uso SeaweedFS en una sola máquina como almacenamiento compatible con S3.
    Le faltan funciones de administración, pero en integridad de datos confío más en Ceph.
    Ceph da la impresión de haber sido hecho por gente que realmente entiende muy bien los sistemas distribuidos.
  • Agregué la lista de alternativas de arriba al repositorio de MinIO en un Pull Request.
    Enlace al PR

• Si ves el hilo anterior de HN, ya se podía notar que MinIO había pasado a modo maintenance.
  Desde entonces ya estaba anunciada, en la práctica, la transición a código cerrado.

  • Pero modo maintenance y “ya no se mantiene” no son lo mismo.

• MinIO ya venía mostrando poca transparencia y estaba lejos del espíritu open source, por ejemplo borrando issues críticos o bloqueando comentarios.
  Por eso, apenas entró en modo maintenance, me cambié a Garage.
  Estoy preparando un PR, aunque todavía no lo envío.

  • Este tipo de proyectos requiere habilidades avanzadas, así que no veo razón para atender a usuarios gratuitos.
    La mayoría del open source serio recibe apoyo industrial, y para un desarrollador web común es difícil contribuir.

• Recomiendo hacer un fork y guardarlo localmente por si el repositorio de MinIO termina siendo eliminado.
  En GitHub, si un repositorio público se borra, los forks siguen existiendo, pero si se vuelve privado, los forks también desaparecen.
  Algo parecido pasó con la gema prawn_plus del ecosistema Ruby.
  Ver la documentación de la política de forks de GitHub
  Para quienes usaban MinIO solo en pruebas locales, esto puede ser una trampa que se va cerrando lentamente.

• Si operas soluciones de observabilidad (Observability) que requieren object storage, como Thanos, Loki, Mimir o Tempo,
  vale la pena considerar VictoriaMetrics, VictoriaLogs y VictoriaTraces en su lugar.
  Estas usan block storage y pueden escalar hasta petabytes, ofreciendo alto rendimiento y disponibilidad sin necesidad de administración manual.