Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
El 13 de febrero de 2026, MinIO Inc. archivó la comunidad minio repositorio. El proyecto había superado las 59 000 estrellas y más de mil millones de descargas de Docker. La base instalada abarca el almacenamiento de objetos de Kubernetes, los repositorios de artefactos de CI/CD, los registros de modelos de aprendizaje automático y los lagos de datos locales. Todo ello se ejecuta ahora sobre un código base que ya no recibe correcciones de seguridad del desarrollador original.
Para los equipos que han elegido MinIO para implementar un almacenamiento de objetos compatible con S3 en los servidores que gestionan, la pregunta práctica es dónde pueden encontrar asistencia técnica y mantenimiento de seguridad continuos para MinIO, ahora que ya no se ofrece soporte por parte del desarrollador original. En esta entrada se explica qué ha cambiado, cuáles son las opciones viables y cómo encaja el servicio «Endless Lifecycle Support» de TuxCare.
¿Qué cambió y cuándo?
El cambio se produjo por etapas a lo largo de unos quince meses.
A principios de 2025, MinIO Inc. eliminó la mayoría de las funciones administrativas de la consola web de la edición comunitaria, dejando únicamente un explorador de objetos básico. Las funciones completas de gestión se trasladaron al producto comercial de la empresa. Las versiones binarias precompiladas fueron desapareciendo durante ese mismo periodo; la edición comunitaria pasó a distribuirse únicamente como código fuente.
El 3 de diciembre de 2025, la empresa puso el repositorio de la comunidad en modo de mantenimiento. Se suspendió el desarrollo de nuevas funciones y las correcciones de seguridad se gestionaron caso por caso, en lugar de seguir un calendario establecido.
El 13 de febrero de 2026, el repositorio se archivó en GitHub. Ahora es de solo lectura: no se admiten nuevas confirmaciones, ni nuevas solicitudes de incorporación de cambios, ni nuevas correcciones de seguridad por parte de MinIO Inc. en el código base de la comunidad. El soporte oficial de MinIO se ha trasladado íntegramente a AIStor, su sucesor comercial.
Ya se han dado a conocer varios CVE relacionados con la última versión de la comunidad, entre ellos CVE-2026-39414, CVE-2026-34204, GHSA-9c4q-hq6p-c237 y GHSA-hv4r-mvr4-25vw. MinIO Inc. ha lanzado correcciones para algunas de ellas en AIStor, pero no se están aplicando parches al código base comunitario archivado que ejecutan las instalaciones existentes. Para los equipos que desean mantener su implementación actual, esto supone una clara carencia en el soporte técnico de MinIO.
Por qué es importante para los operadores
Cualquier equipo que utilice MinIO en entorno de producción se enfrenta a dos retos.
Lo primero es el cumplimiento normativo. Las normas PCI DSS, HIPAA, SOC 2 y FedRAMP establecen plazos de corrección para las vulnerabilidades conocidas; por lo general, son de 30 días para los hallazgos de alta gravedad, aunque a veces son más cortos. Una política «caso por caso» ya resultaba difícil de cumplir dentro de esos plazos. Un repositorio archivado sin correcciones posteriores es inviable. Los hallazgos de auditoría comienzan a acumularse en el momento en que se registra un nuevo CVE y empieza a correr el plazo.
El segundo es la deriva del riesgo. Cada nueva vulnerabilidad CVE que se da a conocer tras la última versión publicada por la comunidad complica aún más la defensa interna de la posición operativa. Los equipos de seguridad elevan el nivel de alerta. Los registros de riesgos se amplían. La inacción tiene su propio plazo, marcado por la próxima auditoría que se realice.
Las opciones que se barajan
Los operadores que utilizan MinIO en la actualidad tienen cuatro opciones viables.
| Opción | Coste | Qué se necesita | Compensación |
|---|---|---|---|
| Quédate con la versión archivada | $0 | Nada | Aumenta la exposición a las vulnerabilidades CVE; no es viable en la mayoría de los marcos normativos |
| Migrar a AIStor | Según los datos, a partir de unos 96 000 $ al año para ≤400 TiB de capacidad útil + costes de migración | Migración de productos, nuevas licencias, reciclaje profesional | Un producto diferente, un modelo operativo diferente |
| Pasarse a una alternativa de código abierto | Tiempo de ingeniería | Transferencia de datos, verificación de la compatibilidad con S3, recertificación | Proyecto de gran envergadura; no existe ninguna alternativa que suponga una sustitución directa |
| Suscríbete a un programa de mantenimiento de terceros | Cuota de suscripción | Sigue ejecutando el MinIO actual | Depende del alcance del programa y del modelo de impartición |
Entre las alternativas de código abierto que vale la pena tener en cuenta se encuentran SeaweedFS, Garage, RustFS y Ceph RGW. Todas ellas son proyectos reales con mantenedores activos y una arquitectura diferente a la de MinIO. Ninguna de ellas es un sustituto directo.
La cuarta opción —el soporte de MinIO por parte de terceros— abarca programas que crean una bifurcación del código base de la comunidad y continúan actualizándolo. Su alcance, formato de prestación y compromisos varían. El programa «Endless Lifecycle Support» (ELS) de TuxCare para MinIO es uno de ellos. En el resto de esta entrada se explica qué ofrece y en qué se diferencia de las alternativas.
Qué ofrece ELS para MinIO
El soporte de ciclo de vida ilimitado de TuxCare para MinIO permite a los clientes seguir utilizando el código base de MinIO que ya tienen en funcionamiento. Los parches se distribuyen como paquetes binarios (RPM, DEB y binarios Go) que se pueden integrar directamente en las implementaciones existentes en máquinas virtuales, servidores físicos y entornos locales sin necesidad de rediseñar el entorno de ejecución.
Cada suscripción incluye:
- Respuesta rápida a incidencias de seguridad (CVE) con soporte SLA durante todo el tiempo que el cliente necesite la versión con soporte
- Cobertura completa de las dependencias tanto directas como transitivas sin coste adicional
- Actualizaciones probadas que mantienen la compatibilidad con las implementaciones existentes
- Integración «plug-and-play» con los flujos de trabajo y los procesos de CI/CD existentes
- Actualizaciones firmadas y a prueba de manipulaciones procedentes de los repositorios alojados en TuxCare
- Con cada versión actualizada se incluye una lista de componentes de software (SBOM). Dado que MinIO es un binario en Go con dependencias de terceros, la SBOM ofrece a los operadores y auditores un único manifiesto oficial que detalla el contenido real de cada versión.
- Contexto de Vulnerability Exploitability eXchange (VEX) que muestra qué CVE del SBOM ya se han solucionado, de modo que los equipos de seguridad puedan centrar su atención en los aspectos que aún requieren intervención
- Asistencia especializada las 24 horas del día, los 7 días de la semana, que incluye la clasificación de vulnerabilidades CVE, solicitudes de parches personalizados y resolución de problemas
Los parches son propiedad de los ingenieros de TuxCare y se distribuyen con una periodicidad respaldada por un acuerdo de nivel de servicio (SLA). El cliente sigue utilizando el código que ha validado, mientras que el soporte técnico de MinIO corre a cargo de un proveedor que respalda el trabajo de forma comercial.
En qué se diferencia ELS de otras opciones de soporte técnico de MinIO
Hay tres características que definen el enfoque de ELS respecto al mantenimiento de MinIO.
- El primero es el modelo de distribución. ELS se distribuye en forma de paquetes binarios. Los programas de mantenimiento alternativos solo se distribuyen como imágenes de contenedores reforzadas, lo que resulta adecuado para entornos nativos de Kubernetes, pero no se adapta a las implementaciones que ejecutan MinIO en máquinas virtuales, servidores físicos o entornos locales. Un cliente que ejecute MinIO fuera de contenedores no puede adoptar una solución basada exclusivamente en contenedores sin rediseñar la implementación.
- El segundo aspecto es el alcance de la cobertura. ELS se compromete a aplicar correcciones retroactivas tanto para las dependencias directas como para las transitivas como parte de la suscripción estándar. MinIO incluye un amplio conjunto de dependencias de Go, y los CVE relacionados con esas dependencias integradas suelen requerir adaptaciones retroactivas de cierta complejidad. Ese trabajo forma parte del compromiso estándar de ELS, no supone ningún coste adicional.
- El tercero es el compromiso de entrega. Los parches se distribuyen con una periodicidad publicada y respaldada por un SLA, y los tiempos de respuesta dependen del nivel de gravedad. Los marcos de cumplimiento como PCI DSS, HIPAA, SOC 2 y FedRAMP establecen plazos estrictos para la corrección de incidencias, y un calendario de entrega predecible es lo que permite a los operadores cumplirlos.
Estas características son las más importantes para los operadores que ejecutan MinIO fuera de contenedores, especialmente cuando se enfrentan a exigencias de cumplimiento normativo.
¿Qué hacer ahora?
Si estás utilizando MinIO en un entorno de producción y necesitas asistencia técnica continua para MinIO más allá del mantenimiento de código fuente, el servicio «Endless Lifecycle Support» de TuxCare ya está disponible.
Para obtener más información o ponerse en contacto con nuestro equipo para comentar los requisitos de su entorno, escriba a: https://tuxcare.com/endless-lifecycle-support/minio-eol-support/.
