MinIO en modo mantenimiento: alternativas S3 open source para 2026

MinIO en modo mantenimiento: qué significa y cuáles son las mejores alternativas S3 open source

Si llevas tiempo usando MinIO como capa de almacenamiento de objetos en tu infraestructura —ya sea en Kubernetes, en bare metal o en un entorno híbrido— probablemente ya hayas visto el aviso: el repositorio upstream de la Community Edition ha pasado a modo mantenimiento. Sin nuevas funcionalidades, sin binarios oficiales, sin imágenes de contenedor.

La pregunta que está sobre la mesa en muchos equipos de infraestructura ahora mismo no es técnica, sino estratégica: ¿qué hago a partir de ahora?

Este artículo analiza qué ha cambiado exactamente, cuál es el impacto real según tu caso de uso y cuáles son las alternativas de almacenamiento de objetos compatibles con S3 más sólidas disponibles hoy. Con especial atención al contexto europeo: soberanía del dato, cumplimiento del RGPD y opciones reales para entornos on-premise en España y Europa.


MinIO fue durante años la referencia de facto para el almacenamiento de objetos compatible con S3 en entornos self-hosted. Su popularidad se asentó sobre tres pilares:

  • Compatibilidad con la API S3 de AWS: cualquier cliente o herramienta que hablase con S3 hablaba sin cambios con MinIO.
  • Facilidad de despliegue: un solo binario, una imagen Docker, y en minutos tenías un almacén de objetos operativo.
  • Rendimiento: optimizado para cargas de trabajo de alta concurrencia y grandes volúmenes de datos.

Era el componente predeterminado para backups, artefactos de CI/CD, logs, almacenamiento interno en Kubernetes (MLflow, Loki, Tempo, Thanos…) y cualquier carga de trabajo que necesitase un endpoint S3 sin depender de AWS.

A finales de 2025, MinIO anunció que la Community Edition pasaba a modo mantenimiento y que la distribución sería solo de código fuente, sin binarios ni imágenes de contenedor oficiales. Ese anuncio reabrió el debate sobre sostenibilidad del open source, gobierno de proyectos y los riesgos de depender de una infraestructura controlada por un único proveedor privado.


Qué ha cambiado exactamente

1. Modo mantenimiento: lo que implica en la práctica

«Modo mantenimiento» no significa que el proyecto esté muerto, pero sí marca un cambio fundamental en el contrato implícito con la comunidad:

  • Sin nuevas funcionalidades: el roadmap de MinIO Community Edition está cerrado.
  • Sin mejoras planificadas: las evoluciones de rendimiento, nuevas APIs o integraciones son exclusivas de la edición comercial.
  • Correcciones limitadas: solo se esperan parches para problemas críticos, no mantenimiento rutinario.
  • Sin revisión activa de pull requests: las contribuciones de la comunidad quedan en el aire.

El resultado práctico es una base de código estable pero estancada. Toda la innovación queda explícitamente reservada para las ofertas comerciales de MinIO Inc. El modelo de negocio es legítimo, pero cambia radicalmente el cálculo para los equipos que usaban la Community Edition como infraestructura crítica.

2. Distribución solo de código fuente

Este punto es el que genera más fricción operativa en el día a día. Si antes bastaba con un docker pull minio/minio, ahora:

  • No hay imágenes de contenedor oficiales para la Community Edition.
  • No hay binarios pre-compilados publicados por el proyecto.
  • Los equipos deben compilar MinIO desde el código fuente, mantener sus propias imágenes, gestionarlas en un registro privado y encargarse de todo el ciclo: firma, escaneo de vulnerabilidades y trazabilidad de procedencia.

Para muchos equipos, esto convierte lo que era un «componente plug-and-play» en una dependencia con carga operativa significativa. En entornos regulados —banca, sanidad, administración pública— justificar el uso de una dependencia de infraestructura sin soporte upstream activo ni distribución oficial se vuelve muy complicado.


Impacto real según tu caso de uso

No todas las organizaciones se ven afectadas igual. El impacto depende fundamentalmente de cómo estás usando MinIO.

Si usas MinIO como servicio S3 externo

Tienes una aplicación que apunta a un endpoint S3. Da igual si detrás hay AWS, MinIO u otra cosa. En este caso:

  • El impacto es moderado.
  • La migración es principalmente operativa: cambiar el endpoint y las credenciales.
  • El código de aplicación normalmente no requiere cambios.
  • El riesgo principal es el operativo: compilar y mantener tus propias imágenes mientras planificas la migración.

Si embutes o redistribuyes MinIO

Si tu producto:

  • Incluye MinIO como componente interno.
  • Construye pasarelas o funcionalidades sobre los internos de MinIO.
  • Depende del tooling operativo específico de MinIO.

Entonces el impacto es alto:

  • Heredas toda la responsabilidad de mantenimiento y seguridad.
  • A medio plazo, un fork interno se vuelve casi inevitable.
  • Las implicaciones de la licencia AGPL v3 deben revisarse cuidadosamente: distribuir software que incluye código AGPL sin cumplir sus condiciones es un riesgo legal nada trivial.

Para ISVs y vendors que embuten MinIO en sus productos, esto no es un ajuste táctico: es una reevaluación estratégica del componente de almacenamiento.


Seguridad y cumplimiento: el contexto europeo importa

En España y Europa, este cambio tiene una dimensión adicional que los equipos de infraestructura no pueden ignorar.

RGPD y soberanía del dato

El Reglamento General de Protección de Datos exige, entre otras cosas, que las organizaciones puedan demostrar el control efectivo sobre los sistemas que tratan datos personales. Usar software de infraestructura crítica sin soporte upstream activo ni distribución oficial verificable complica esta demostración, especialmente en auditorías.

Los equipos de seguridad y compliance que ya tenían dificultades para justificar el uso de software «comunitario» en entornos de producción con datos personales ahora tienen un argumento adicional para acelerar la migración hacia alternativas con gobernanza más clara.

Proveedores europeos de cloud y alternativas soberanas

En el ecosistema europeo existen alternativas relevantes:

  • Scaleway Object Storage (Francia): compatible con S3, infraestructura 100% en Europa.
  • Exoscale (Suiza/Austria): enfocado en soberanía del dato y cumplimiento europeo.
  • OVHcloud Object Storage (Francia): compatible con S3, con capacidad de despliegue en múltiples regiones europeas.
  • Hetzner Object Storage (Alemania): opción económica y sólida para cargas no críticas.

Para entornos self-hosted que necesitan permanecer on-premise, las alternativas open source analizadas más abajo son la respuesta natural.

Entornos regulados: la posición ha cambiado

En sectores como banca, sanidad o administración pública, donde los requisitos de seguridad y auditoría son más estrictos, la situación ha cambiado sustancialmente. No se trata solo de que MinIO Community Edition sea inseguro —no lo es por defecto— sino de que el modelo de responsabilidad compartida ha cambiado radicalmente. La organización ahora asume una carga que antes correspondía al proveedor upstream.


Forks y reacción de la comunidad

A fecha de publicación de este artículo, la situación de los forks es la siguiente:

  • Existen varios forks comunitarios centrados en preservar la experiencia de la consola web de MinIO (la UI).
  • No existe un fork de servidor ampliamente adoptado que sustituya plenamente al servidor MinIO con mantenimiento activo y comunidad consolidada.
  • El debate en la comunidad, refleja cautela: la mayoría de organizaciones no están apostando por forks apresurados sino por migraciones planificadas.

La ausencia de un fork de servidor sólido es significativa. Mantener un fork de un sistema de almacenamiento distribuido de alta complejidad requiere un nivel de compromiso en seguridad, corrección de bugs y evolución que pocas comunidades pueden sostener sin financiación. La señal del mercado es clara: migrar es preferible a forkear.


Las mejores alternativas de almacenamiento de objetos compatibles con S3

La respuesta del sector no está en encontrar «el nuevo MinIO» —un sustituto drop-in perfecto—, sino en seleccionar sistemas de almacenamiento cuyo modelo de gobernanza y mantenimiento encaje mejor con las necesidades a largo plazo. Aquí están las opciones más relevantes.

Ceph RGW (RADOS Gateway)

Mejor para: entornos empresariales que requieren alta disponibilidad y escalabilidad masiva.

Ceph es el sistema de almacenamiento distribuido open source más maduro y ampliamente desplegado en entornos de producción exigentes. Su componente RADOS Gateway (RGW) ofrece una API compatible con S3 (y también con Swift) sobre la capa de almacenamiento de objetos RADOS.

Puntos fuertes:

  • Ecosistema muy maduro, con más de una década de uso en producción.
  • Comunidad enorme y gobernanza sólida bajo la Linux Foundation.
  • Alta disponibilidad real: diseñado desde cero para resistir fallos de discos, nodos y racks.
  • Compatible con la mayoría de herramientas del ecosistema S3.
  • Soporte comercial disponible de múltiples proveedores (Red Hat, SUSE, etc.).

Consideraciones:

  • La complejidad operativa es real y no debe subestimarse. Ceph tiene una curva de aprendizaje pronunciada.
  • No es una opción para equipos pequeños sin experiencia en sistemas de almacenamiento distribuido o sin recursos para invertir en formación.
  • El despliegue mínimo recomendado implica varios nodos y discos dedicados.

Veredicto: si necesitas la opción más robusta y con mejor gobernanza a largo plazo para un entorno Kubernetes on-premise con requisitos serios de HA, Ceph RGW es la elección más sólida.


SeaweedFS

Mejor para: equipos que buscan simplicidad, rendimiento y licencia permisiva.

SeaweedFS es un sistema de almacenamiento de objetos y archivos distribuido que ha ganado tracción significativa como alternativa a MinIO, especialmente por su licencia Apache 2.0 —mucho más permisiva que la AGPL de Ceph o Garage— y su desarrollo activo.

Puntos fuertes:

  • Licencia Apache 2.0: sin las restricciones copyleft de AGPL, relevante para productos comerciales y OEMs.
  • Desarrollo activo y mantenimiento regular.
  • API S3 integrada, relativamente completa.
  • Arquitectura orientada al rendimiento para escrituras y lecturas masivas.
  • Más sencillo de operar que Ceph para casos de uso moderados.
  • Soporte para volúmenes FUSE y otras interfaces además de S3.

Consideraciones:

  • La compatibilidad S3 tiene algunas lagunas en casos extremos y operaciones avanzadas (Object Lock, ciertos comportamientos de versionado…).
  • La comunidad es activa pero más pequeña que la de Ceph.
  • Menor historial en entornos de producción de alto nivel que Ceph.

Veredicto: excelente punto de partida para equipos que migran desde MinIO y valoran la simplicidad operativa. La licencia Apache 2.0 es un diferenciador importante si estás construyendo un producto.


Garage

Mejor para: entornos self-hosted distribuidos geográficamente, homelab avanzado y proyectos con enfoque en resiliencia.

Garage es un proyecto relativamente joven pero con una filosofía muy bien definida: almacenamiento de objetos diseñado para la resiliencia en entornos distribuidos geográficamente, incluso con conectividad intermitente entre nodos. Es particularmente relevante para organizaciones que operan en múltiples ubicaciones físicas o que quieren el nivel máximo de control sobre su infraestructura de datos.

Puntos fuertes:

  • Arquitectura pensada desde cero para distribución geo-redundante: nodos en diferentes ubicaciones físicas, zonas o incluso países.
  • Desarrollo abierto y activo, con gobernanza transparente.
  • Muy ligero en recursos: puede correr en hardware modesto.
  • Compatible con la API S3 para operaciones habituales.
  • Filosofía «infraestructura soberana»: sin dependencia de servicios externos.

Consideraciones:

  • Licencia AGPL v3: las mismas consideraciones que con Ceph para productos comerciales que distribuyen el software.
  • Más joven que Ceph y SeaweedFS: menor historial en producción de gran escala.
  • La compatibilidad S3 es funcional pero no completa al nivel de Ceph.
  • Comunidad más pequeña, aunque activa y comprometida.

Veredicto: si operas en múltiples ubicaciones físicas o tu requisito principal es la resiliencia ante fallos de conectividad entre sitios, Garage merece una evaluación seria. También es una opción sólida para homelabs avanzados donde la soberanía del dato es prioritaria.


Zenko / CloudServer (Scality)

Mejor para: arquitecturas multi-cloud y casos de uso orientados a la federación de almacenamiento.

CloudServer (anteriormente S3 Server, parte del proyecto Zenko de Scality) es una implementación open source de la API S3. Scality es una empresa francesa con fuerte presencia en el mercado europeo de almacenamiento empresarial.

Puntos fuertes:

  • Implementación open source de la API S3, con buen nivel de compatibilidad.
  • Contexto europeo: Scality es una empresa francesa, relevante para organizaciones que valoran el origen del proveedor.
  • Orientado a escenarios multi-cloud y federación de backends de almacenamiento.

Consideraciones:

  • Las asunciones arquitectónicas son diferentes a las de MinIO: no es un reemplazo directo.
  • Requiere evaluación específica según el caso de uso.
  • El proyecto Zenko en su conjunto es más complejo que una simple capa S3.

Veredicto: interesante para casos de uso de federación multi-cloud o cuando el contexto empresarial europeo es relevante para la decisión de compra.


Estrategias recomendadas según tu situación

No hay una respuesta única. La estrategia correcta depende de dónde estés hoy y hacia dónde necesitas ir.

Si necesitas reducir el riesgo de forma inmediata

El primer paso no es migrar, sino estabilizar:

  1. Congela la versión de MinIO que estás usando hoy. No actualices de forma irreflexiva; en modo mantenimiento, cualquier cambio es tu responsabilidad.
  2. Construye, escanea y firma tus propias imágenes si estás en contenedores. Integra el proceso en tu CI/CD.
  3. Define y ensaya un plan de migración. No tienes que ejecutarlo mañana, pero sí tenerlo listo.
  4. Monitoriza los advisories de seguridad del proyecto de forma proactiva. Sin upstream activo, la detección temprana depende de ti.

Si operas Kubernetes on-premise con requisitos de alta disponibilidad

Ceph RGW es habitualmente la opción más sólida a largo plazo. La inversión en aprender Ceph es significativa, pero el retorno en estabilidad, gobernanza y ecosistema lo justifica para entornos de producción críticos.

Alternativa: si Ceph es demasiado complejo para tu equipo hoy, considera SeaweedFS como paso intermedio mientras creces en madurez operativa.

Si la flexibilidad de licencia es crítica (OEMs, ISVs)

Empieza la evaluación con SeaweedFS (Apache 2.0). Evita por defecto las opciones AGPL (Ceph, Garage) hasta tener claridad jurídica sobre las implicaciones para tu modelo de distribución.

Si operas en múltiples ubicaciones físicas o necesitas distribución geográfica real

Garage es el candidato natural. Evalúa si su nivel de compatibilidad S3 cubre tus casos de uso específicos antes de comprometerte.

Si el foco está en la soberanía del dato y el cumplimiento europeo

  • Para self-hosted: cualquiera de las opciones anteriores, con preferencia por las que tienen gobernanza más transparente (Ceph, Garage).
  • Para managed: considera proveedores europeos como Scaleway, OVHcloud o Exoscale antes de recurrir a AWS S3.

Si la UX operativa es un factor clave

No dependas de la consola web como infraestructura crítica. Los forks de la UI de MinIO son interesantes, pero:

  • Trata la UI como herramienta secundaria, no como componente core.
  • Invierte en workflows de automatización: infraestructura como código, pipelines de gestión, dashboards propios sobre las APIs de la alternativa elegida.
  • La dependencia de una UI web específica es precisamente el tipo de lock-in que te llevó a esta situación.

Preguntas frecuentes

¿Qué significa exactamente el modo mantenimiento para MinIO Community Edition?

Significa que la base de código upstream está efectivamente congelada. No habrá nuevas funcionalidades, solo correcciones de bugs críticos, y los pull requests de la comunidad no serán revisados activamente. Además, ya no se publican binarios precompilados ni imágenes de contenedor oficiales: los usuarios deben compilar desde el código fuente y mantener sus propias distribuciones.

¿Sigue siendo seguro usar MinIO Community Edition?

El código en sí no es inherentemente inseguro, pero el modelo de responsabilidad compartida ha cambiado. Los parches de seguridad para problemas no críticos serán más lentos o inexistentes. En producción —especialmente en entornos regulados o que manejan datos personales bajo RGPD— ahora debes monitorizar activamente los advisories, construir y escanear tus propias imágenes, y asumir una carga operativa que antes recaía en el upstream. Eso eleva el riesgo operativo de forma objetiva.

¿Cuál es la mejor alternativa open source a MinIO para Kubernetes?

Depende del caso de uso. Para entornos de alta disponibilidad a nivel empresarial, Ceph RGW es la opción más robusta. Para simplicidad y licencia Apache 2.0, SeaweedFS es excelente. Para distribución geo-redundante y resiliencia ante fallos de conectividad entre sitios, evalúa Garage. No existe un reemplazo drop-in universal: cada alternativa requiere evaluación específica.

¿Debo forkear MinIO o migrar a otra solución?

Para la mayoría de organizaciones, migrar es claramente preferible a forkear. Mantener un fork de un sistema de almacenamiento distribuido de alta complejidad implica un compromiso a largo plazo con seguridad, corrección de bugs y potencial backporting de funcionalidades que pocas comunidades pueden sostener. La tendencia del sector apunta inequívocamente hacia la migración a sistemas con desarrollo upstream activo y gobernanza clara.

¿Cómo afecta esto a productos que embuten MinIO (uso OEM)?

El impacto para OEMs e ISVs es alto. Heredáis toda la responsabilidad de mantenimiento y seguridad. A medio plazo, un fork interno se vuelve casi inevitable, con todo el coste que eso implica. Y las implicaciones de la licencia AGPL v3 deben revisarse con asesoramiento jurídico: distribuir software que incluye código AGPL sin cumplir sus condiciones es un riesgo legal real. Esto no es un ajuste táctico; es una reevaluación estratégica del componente de almacenamiento.

¿Qué opciones existen para entornos con requisitos de soberanía del dato en Europa?

Para entornos self-hosted, las alternativas open source analizadas (Ceph, SeaweedFS, Garage) son todas válidas, con diferente perfil de complejidad y licencia. Para entornos managed que necesitan permanecer en infraestructura europea, proveedores como Scaleway, OVHcloud, Exoscale o Hetzner ofrecen almacenamiento de objetos compatible con S3 con centros de datos exclusivamente en Europa, lo que simplifica el cumplimiento del RGPD y las auditorías de localización de datos.


Conclusión: no es una crisis, pero sí un punto de inflexión

El cambio de MinIO Community Edition a modo mantenimiento no supone una rotura técnica inmediata. No hay un día D en que todo deje de funcionar. El riesgo no es técnico a corto plazo; es de gobernanza y sostenibilidad a medio y largo plazo.

La pregunta real es: ¿quieres que tu infraestructura de almacenamiento de objetos sea un componente que gestionas activamente y cuya evolución controlas, o prefieres depender de un upstream que ha decidido reservar su desarrollo para una oferta comercial?

Para muchos equipos, este momento es la oportunidad natural de hacer algo que probablemente debería haberse hecho antes: tratar el almacenamiento de objetos como infraestructura crítica real, con todos los criterios de gobernanza, seguridad y sostenibilidad que eso implica.

Las opciones están sobre la mesa. La decisión no puede postergarse indefinidamente.