Cuando contamos que estamos dejando MinIO, la reacción más común es la pregunta: ¿por qué? Este texto responde con fuentes y con lo que vivimos en la práctica. Es el artículo hermano del relato de ejecución: allí está el cómo; aquí, el porqué de nuestra salida de MinIO. Una advertencia: este es un texto de opinión, escrito por quienes pagan las cuentas de un equipo pequeño, y las opiniones están señaladas como tales.
Qué pasó con MinIO community
La edición community de MinIO fue perdiendo cosas a lo largo de 2025. En junio, Blocks and Files registró que algunas funciones de administración habían desaparecido del código de la edición básica de object storage. Según la cronología recopilada por ayedo, el proyecto dejó de publicar imágenes Docker en los registros públicos en octubre, entró en modo de mantenimiento en diciembre y, a comienzos de 2026, empezó a avisar que el repositorio ya no recibe mantenimiento. En diciembre, InfoQ ya hablaba de alternativas compatibles con la API S3. Comprueba las fechas en las fuentes: aquí usamos su resumen, no nuestra memoria.
Qué cambió para nosotros
En la práctica, cuatro cosas. Primero, sin mantenimiento upstream, las correcciones de seguridad dejan de ser algo que se pueda esperar. Segundo, la distribución: cuando uno de nuestros equipos intentó descargar la imagen de MinIO para una prueba de CI, encontró todos los canales públicos cerrados o sin acceso anónimo. Tercero, la consola: la versión community ya había perdido la interfaz completa de administración.
Cuarto, y esto es una opinión nuestra: el camino que MinIO señala es el producto comercial, AIStor, y para un equipo pequeño ese precio es demasiado alto. No pondremos una cifra aquí, porque los precios cambian y dependen del contrato: haz tus cuentas. Las nuestras no cerraron.
Nada de esto deja fuera de servicio a un servidor hoy. Pero todo empuja el coste hacia el futuro, y un equipo pequeño no tiene margen para asumirlo de golpe, durante una mala noche.
Los criterios de la decisión
Partimos de tres criterios. Cero cambios para los clientes: nuestras aplicaciones, backups y el sitio hablan S3 con claves y hostnames fijos, así que cada consumidor al que haya que reconfigurar supone un riesgo. Rollback de verdad: tiene que ser posible volver atrás con un comando y con los datos intactos. Y bajo coste, tanto operativo como de licencia: un equipo pequeño no aprende un sistema nuevo completo ni paga una suscripción que no cabe en el presupuesto por culpa de un cambio forzado.
El trade-off es honesto. Estos criterios favorecen la opción más parecida a lo que ya tenemos, y eso nos deja un paso por detrás de una arquitectura nueva que quizá sería mejor a largo plazo.
Por qué Silo ahora, y RustFS o Garage después
Silo es un fork comunitario mantenido por Pigsty que, según el propio manifiesto del proyecto y la documentación, mantiene la API S3, las variables de entorno y el formato en disco, y restaura la consola integrada, bajo la licencia AGPLv3. Como las fuentes pertenecen al propio proyecto, validamos la compatibilidad con nuestros datos antes de confiar en ella: el relato está en el artículo de ejecución.
Esto encaja con los tres criterios, así que Silo es nuestro puente. No es el destino. Más adelante evaluaremos RustFS, si queremos algo parecido a la forma de operar de MinIO, y Garage, si la prioridad pasa a ser trabajar con varios sitios y hardware modesto. No hemos evaluado otras alternativas a fondo, así que este texto no las recomienda ni las descarta.
Para cerrar
Ahora viene la pullita: sí, llamamos traidor del open source al equipo de MinIO. Tomó un proyecto abierto, fue vaciando la edición community y empujó a todo el mundo hacia el producto de pago. Es nuestra opinión, expresada con la ironía de siempre. Y, de nuevo, es solo una pullita, una broma; no hay que tomarla en serio. De hecho, el final de la historia es bastante open source: el código que publicaron es precisamente lo que permite que exista un fork como Silo.
La decisión en sí trata de riesgo, precio y tamaño del equipo. Si tu situación es parecida, el mejor primer paso es sencillo: descubre quién depende de tu storage y elige el cambio que no obligue a nadie a modificar su configuración.