Alternativas OSS a MinIO para S3 local en Docker

Por qué MinIO dejó de ser la opción obvia para S3 local

A finales de 2025 la compañía detrás de MinIO puso el proyecto en modo mantenimiento y, según reporta LWN, el repositorio fue archivado por completo en febrero de 2026. La consecuencia práctica para miles de desarrolladores y pequeños equipos es que la que durante una década fue la opción por defecto para correr una API S3 compatible sobre un único nodo, en local, desde Docker, dejó de recibir nuevas funcionalidades y los parches críticos se evalúan caso por caso, según la cobertura de InfoQ.

Según InfoQ, la compañía detrás del proyecto lo que hizo fue orientar la migración hacia MinIO Enterprise y deshabilitar funciones administrativas de la consola comunitaria. Para quien usaba MinIO como almacenamiento self-hosted en producción, el golpe fue doble: no solo se acabó el desarrollo, también desapareció la ruta comunitaria de patches.

Para fundadores y equipos técnicos hispanohablantes esto tiene una lectura directa: el software de infraestructura que tocas poco y “simplemente funciona” es también el más caro de reemplazar cuando cambia de modelo. Y cuando cambia sin aviso, como en este caso, te quedas corriendo sobre un proyecto archivado en producción.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Qué cambió y por qué importa más allá del storage

Lo que ya no tienes con MinIO

Sin nuevas funcionalidades ni pull requests aceptados, y los reportes de seguridad se revisan caso por caso según el último commit del repositorio público.
El proyecto comunitario está archivado desde febrero de 2026, según LWN.
El camino comercial recomendado es migrar a MinIO Enterprise, no una alternativa OSS.

Por qué afecta a demos, pipelines y MVPs

El artículo original de Robin Moffat lo deja muy claro: MinIO estaba tejido en demos, entornos Docker Compose y pipelines de validación de compatibilidad S3 que asumían que el proyecto existía y se mantenía. Cuando el proveedor cambia la apuesta, el problema no se ve en el data lake, se ve el día que necesitas actualizar tu stack.

Para una startup early-stage, esto se traduce en una regla práctica muy concreta: tu capa de almacenamiento “tranquila” no es un commodity, es una decisión de gobernanza. Si depende de un único vendor, en cualquier momento puede cambiar la licencia, el roadmap o el soporte. Y si no puedes evaluar el reemplazo en un fin de semana, tienes un riesgo de plataforma acumulado.

El panorama actual de alternativas OSS para S3 local

Robin Moffat evaluó seis proyectos sustitutos frente a unos requisitos muy concretos para entornos de demo y desarrollo: imagen Docker, compatibilidad S3, licencia libre con preferencia por OSI (Apache 2.0 ideal), despliegue single-node y comunidad sana. Estos son, según su comparativa, los jugadores que quedan en pie.

SeaweedFS

Licencia: Apache 2.0.
Origen: Chris Lu, primer commit en 2012.
Fortalezas: maduro, con soporte S3 desde 2018, 5M+ pulls en Docker Hub, 29.5k estrellas en GitHub.
Limitaciones: experiencia de configuración no tan pulida y sitio web principal enfocado en la versión enterprise, lo que dificulta saber que existe la versión OSS.
Uso típico: “drop-in” relativamente directo reemplazando la imagen Docker de MinIO.

s3proxy (gaul/s3proxy)

Licencia: Apache 2.0.
Origen: Andrew Gaul como único mantenedor, primer commit en 2014.
Fortalezas: opción ligera y muy fácil de configurar, 5M+ pulls.
Limitaciones: depende internamente de jclouds, que según Moffat fue retirado al Apache Attic a mediados de 2025; un dato corroborado en el análisis de LWN, que describe a jclouds como proyecto en desuso.
Uso típico: cuando quieres redirigir llamadas S3 a otro backend sin tocar tu código.

RustFS

Licencia: Apache 2.0.
Origen: proyecto joven, primer commit en 2024 (~19.7k estrellas).
Fortalezas: foco en rendimiento bruto para data lakes y workloads de IA, buena documentación y UI incluida.
Limitaciones: sigue en release alpha (1.0.0-alpha.79 en la prueba), y tuvo recientemente una vulnerabilidad de seguridad grave reportada; varios enlaces de su web resuelven a la misma página, según Moffat, “olor a pintura fresca”.
Uso típico: si necesitas performance para Iceberg/Parquet en AI pipelines y aceptas un proyecto alpha.

Garage

Licencia: AGPLv3.
Origen: Deuxfleurs (asociación sin fines de lucro), primer commit en 2020 (~2.5k estrellas).
Fortalezas: escrito en Rust, mínimas necesidades de hardware (1 GB de RAM), single-binary y apuesta clara por durabilidad y fault tolerance con CRDTs, según LWN. La versión estable más reciente reportada por LWN es la 2.3.0, de abril de 2026.
Limitaciones: no es un drop-in: requiere un contenedor extra de bootstrap, archivo TOML aparte y un formato de Key ID propio que comienza con “GK”. Para una demo local es overkill de governance.
Uso típico: clusters pequeños auto-hospedados, labs en casa, entornos distribuidos de pequeño porte, como el autor de XDA Developers describe.

Zenko CloudServer (Scality)

Licencia: Apache 2.0.
Fortalezas: parte de un toolset empresarial con respaldo comercial, sustituye a MinIO con pocos cambios, imagen Docker disponible.
Limitaciones: la confusión entre CloudServer / Zenko / Scality y la sensación de que la documentación apunta a una imagen Docker desactualizada.
Uso típico: cuando quieras alinearte con un proveedor comercial conocido sin salirte de Apache 2.0.

Apache Ozone

Licencia: Apache 2.0.
Origen: spinoff de Apache Hadoop en 2020, ~1.1k estrellas, 30+ commiteadores significativos.
Fortalezas: única opción con respaldo de una fundación (Apache Software Foundation), lo que la hace inmune a “rug-pulls” de licencia.
Limitaciones: Moffat no logró desplegarlo con menos de cuatro nodos; el sabor a Hadoop es fuerte.
Uso típico: entornos grandes multi-nodo, no demos locales.

El veredicto práctico para reemplazar MinIO en demos

El propio Moffat redujo su elección a dos nombres después de probar todas las opciones: SeaweedFS y s3proxy. La razón es la misma que te va a importar a ti: mínimas modificaciones a un Docker Compose existente, licencia Apache 2.0 y trayectoria. RustFS queda en el “tal vez” por su juventud y porque su última release era alpha. Garage y Ozone quedan descartados para su caso de uso (demo single-node) por complejidad de setup, no por calidad del proyecto.

Si tu perfil es más cercano al home-lab o NAS pequeño que al demo de Iceberg, el análisis en XDA Developers refuerza la elección por Garage justamente por las razones contrarias: simplicidad operativa, predictibilidad y respaldo de una nonprofit, aún a costa de renunciar a la facilidad de un drop-in.

Cómo decidir tú, en 10 minutos

¿Solo quieres reemplazar MinIO en un Docker Compose sin tocar el código? Empieza por SeaweedFS o s3proxy.
¿Tu prioridad es estabilidad a tres años, aunque la config inicial sea más lenta? Mira Garage y asume AGPLv3 desde el día uno.
¿Necesitas performance bruta para Iceberg o AI pipelines? Prueba RustFS con la advertencia de que es alpha y revisa los CVEs recientes.
¿Tu carga exige el set completo de la API S3 a escala distribuida? La opción con respaldo de fundación es Apache Ozone (o Ceph, que LWN analiza en profundidad y ahora vive bajo la Linux Foundation).
¿Quieres quedarte con un MinIO parchecido mientras decides? Existe un fork comunitario llamado pgsty/minio mencionado en el propio post de Moffat, mantenido por Ruohang Feng. Sin embargo, LWN aclara que el alcance de ese fork es solo bugs y CVEs: no se planean nuevas funcionalidades, y su release más reciente a la fecha de LWN fue el 18 de junio de 2026. No es una vía de escape, es un parche temporal.

Qué significa esto para tu startup

Más allá del caso técnico, lo que MinIO acaba de demostrar es el riesgo sistémico de basar tu storage de demo, CI/CD o incluso producción en un proyecto OSS sostenido por un único vendor. La frase de Alexey Minin recogida por InfoQ lo resume: “En 2025, OSS no es suficiente. Necesitamos Open Governance. Los proyectos hospedados en fundaciones (CNCF, Apache, Linux Foundation) son inmunes a estos rug-pulls. Los proyectos single-vendor, no.”

Acciones concretas que puedes aplicar esta semana:

Audita qué dependencias OSS single-vendor tienes en producción o staging. Una búsqueda rápida en GitHub por licencia y mantenedor único te va a sacar más de una sorpresa: MinIO no fue el primero y no va a ser el último.
Define tu criterio de “sustituible en una tarde”. Si hoy no puedes reemplazar tu capa de storage por una alternativa OSS en menos de un día, tienes un lock-in blando que no aparece en tu cap table pero sí en tu risk register.
Si adoptas SeaweedFS o s3proxy, congela la versión en tu Docker Compose. Ninguno de los dos vive bajo una fundación; ambos pueden cambiar su roadmap igual que MinIO. Documenta el fork conocido (en el caso de s3proxy, su dependencia jclouds está retirada) antes de comprometerte.