Las mejores alternativas a Minimus en 2026

Minimus va a cerrar y su registro (reg.mini.dev) dejará de estar operativo el 22 de octubre de 2026, tras un periodo de mantenimiento de 60 días que comenzó el 24 de agosto. Las imágenes descargadas seguirán funcionando, pero no habrá nuevas actualizaciones. Si utilizas imágenes de Minimus, tienes una fecha límite para la migración.

Incluso antes de esto, su modelo no funcionaba para todo el mundo. Adoptar Minimus suponía pasarse a sus imágenes, que se creaban en su propia distribución (MinimOS), y depender de su cadencia de lanzamientos. Y como las imágenes carecen de distribución (sin shell ni gestor de paquetes), cualquier elemento del que dependiera tu configuración y que Minimus hubiera eliminado tenía que reelaborarse. 

Existen alternativas que evitan esto. En lugar de hacerte cambiar a una distribución de un proveedor, aplican parches a la imagen base que ya utilizas y, en los casos en los que hayas fijado una versión, incorporan las correcciones a esa versión en lugar de obligarte a actualizar. En esta entrada se explica qué pasos seguir a continuación.

En esta entrada te explicamos cuáles son los siguientes pasos y en qué debes fijarte para no tener que volver a migrar dentro de un año. Comparamos:

• Aikido Security
• Chainguard
• Docker Hardened Images
• RapidFort
• Echo

TL;DR

Nuestra mejor opción es Aikido Security. En lugar de migrarte a una nueva distribución, aplica parches a la imagen base que ya estás utilizando, por lo que nada deja de funcionar, y la corrección se envía como una solicitud de incorporación de cambios que solo tienes que fusionar una vez. A partir de ahí, Aikido sigue reconstruyendo la imagen a medida que se corrigen nuevas vulnerabilidades y te avisa cuando hay una versión más reciente disponible. Cada imagen es un sustituto directo con procedencia de SBOM, VEX y SLSA, que cubre los CVE a nivel del sistema operativo bajo un SLA definido para la creación de parches. Sigue aplicando parches a las versiones incluso después del fin de su vida útil, y forma parte de una plataforma que también cubre SAST, DAST, SCA, detección de secretos y la postura de seguridad en la nube. Habiendo ya migrado a los clientes de Root, Aikido puede ayudarle a dejar de utilizar Minimus de la misma manera.

{{cta}}

Lo que Minimus hizo bien

Minimus creó sus imágenes «distroless» a partir del código fuente en su propia distribución, MinimOS, que solo incluía lo necesario para que una aplicación funcionara, sin ninguna de las herramientas de shell ni de gestión de paquetes que amplían la superficie de ataque. El catálogo contaba con más de 1.200 imágenes que cumplían con las normas FIPS, CIS, NIST y STIG, y en junio de 2026 todo el catálogo pasó a ser gratuito sin necesidad de registrarse. En el caso de las imágenes que se adaptaban tal cual, su adopción consistía en un simple cambio de una línea en un Dockerfile o en un manifiesto.

Por qué necesitas una alternativa a Minimus ahora mismo

El catálogo de Minimus va a cerrar y no habrá más actualizaciones de las imágenes de Minimus a partir del 22 de octubre. Todo lo que hayáis descargado seguirá funcionando, pero los CVE se acumularán sin que haya ninguna versión parcheada que las sustituya.

Si quieres que tus imágenes estén libres de vulnerabilidades, ahora te ves obligado a llevar a cabo una costosa migración fuera de Minimus. Abandonar la plataforma implica sustituir cada imagen de Minimus que aloja uno de tus servicios por otra fuente y volver a realizar las pruebas. La migración en sí es inevitable a estas alturas, por lo que merece la pena elegir un sustituto que no te obligue a ceñirte a su propia distribución y cadencia; de lo contrario, tendrás que volver a hacer lo mismo la próxima vez que un proveedor cambie de rumbo. 

E incluso si no te hubiera supuesto ningún problema migrar a su distribución, el modelo era inestable. Minimus reconstruía las imágenes a partir del código original y lanzaba nuevas versiones, por lo que, aunque el número de versión no cambiara, una imagen parcheada suponía un nuevo resumen. Mantenerse al día significaba actualizar a cada una de ellas, y cada actualización suponía una nueva imagen que había que probar y volver a aprobar.

La actualización automática funcionaba bien hasta que dejó de hacerlo. Por ejemplo, una vulnerabilidad CVE afectaba a una biblioteca de tu imagen y la corrección se incluyó en la versión 2.1, pero otro paquete del que dependías solo aceptaba versiones anteriores a la 2.0. Lo más sensato era fijar esa dependencia a una versión concreta, pero entonces no podías actualizar y la imagen no hacía más que acumular vulnerabilidades. 

Qué hay que tener en cuenta a la hora de buscar una alternativa a Minimus

• Un amplio catálogo de soluciones listas para usar: ¿cuántas de las plataformas que utilizas realmente ya están incluidas? Busca una amplia variedad de opciones en Debian, Ubuntu y Alpine, tanto en amd64 como en arm64.
• Procedencia verificable: un archivo « SBOM » firmado, un documento VEX y la información de procedencia SLSA adjuntos a cada pull, para que puedas demostrar qué contiene una imagen y cómo se ha creado.
• Seguridad tras el fin de la vida útil: aplicación de parches que continúa después de que la distribución original haya dejado de recibir actualizaciones, lo que te permite mantener una versión base más antigua sin tener que asumir los CVE críticos y de alto riesgo conocidos.
• Cobertura más allá de la imagen base: busca una herramienta que también abarque tus dependencias, el código (SAST), la infraestructura como código (IaC), los secretos y el entorno de ejecución, de modo que cada hallazgo venga acompañado de su contexto.
• Pruebas de cumplimiento por defecto: directrices FIPS, CIS, NIST y STIG con los documentos de auditoría generados automáticamente.
• Un proveedor en el que puedes confiar: evalúa su trayectoria , su historial y cuánto perderías si volviera a ocurrir.

Las mejores alternativas a Minimus

Aikido Security

Mientras que Minimus te traslada a su propia distribución, Aikido aplica parches a la imagen base que ya utilizas. Aikido Images es un repositorio con más de 2.000 imágenes de sustitución directa en las que ya se han corregido las vulnerabilidades críticas y de alto riesgo conocidas de la imagen base. Esas imágenes se recompilan, se parchean, se minimizan y se refuerzan durante el proceso de compilación, por lo que obtienes un tratamiento completo, una superficie de ataque más reducida y una configuración predeterminada más segura, todo ello sobre la imagen base que ya utilizas.

Para ejemplo, debian:bookworm envía una versión parcheada glib2.0 para CVE-2025-4373, que Debian corrigió en Trixie y Sid, pero no en Bookworm. La variante «Aikido Images» de debian:bookworm lleva el parche glib2.0 con lo que se cierra el asunto.

Dado que el intercambio es una sustitución directa que AutoFix propone como solicitud de incorporación de cambios, la corrección se aplica en el momento en que se realiza la fusión, y cada incorporación procedente de docker.aikido.io llega con una procedencia de SBOM, VEX y SLSA. Aikido sigue aplicando parches a las versiones incluso después de que el desarrollador original haya dejado de dar soporte, incluso a aquellas que han llegado al final de su ciclo de vida, por lo que puedes seguir utilizando una base más antigua sin tener que soportar sus fallos de seguridad conocidos y sin verte obligado a actualizar a una versión más reciente para mantener la protección.

El equipo responsable de estas imágenes se incorporó tras la adquisición de Root por parte de Aikido, la empresa creadora de SlimToolkit (antes DockerSlim), una de las herramientas de código abierto más utilizadas para el endurecimiento de imágenes, con más de 23 000 estrellas en GitHub y una capacidad demostrada para reducir el tamaño de las imágenes hasta 30 veces. Los clientes actuales de Root se han migrado a Aikido Images and Libraries, y Aikido puede ayudarte a dejar de utilizar Minimus de la misma manera. 

Aikido ha recaudado 85 millones de dólares y cuenta con la confianza de más de 150 000 equipos, entre los que se incluyen empresas como Revolut, Belfius, la Premier League, Deel y SoundCloud, además de Visma, que utiliza Aikido en más de 200 empresas de su cartera y con 6 000 desarrolladores. Una empresa con liquidez suficiente para adquirir Root en su totalidad no es precisamente la que está a punto de desactivar su registro.

Una proporción cada vez mayor de correcciones reales nunca llega a tener un CVE. La supervisión continua de Aikido se alimenta, en parte, de «Aikido Intel», que analiza los registros de cambios y el historial de confirmaciones de los proyectos originales para detectar vulnerabilidades que se han corregido de forma silenciosa sin asignarles un CVE. Y mientras que la mayoría de estas herramientas corrigen un CVE actualizando el paquete afectado a una versión más reciente, Aikido recurre en gran medida a los parches retroportados, tomando la corrección de la versión más reciente y aplicándola a la versión que ya estás ejecutando. De este modo, el cambio es mínimo, por lo que es más probable que la imagen se comporte tal y como espera tu aplicación, con menos «deuda de actualización», que se acumula cuando te ves obligado a pasar a nuevas versiones.

Cuando no es posible realizar una retroportación limpia, Aikido actualiza o recompila el componente. Además, asocia cada contenedor a la base de la que hereda y te indica el cambio que elimina más riesgos en toda la organización, con más de 100 parches investigados y probados a diario y una cobertura a nivel de sistema operativo bajo un SLA definido para la creación de parches.

Las vulnerabilidades de los paquetes a nivel de aplicación en ecosistemas como npm, PyPI, Maven y Go se corrigen directamente a través de Aikido Libraries. Todo ello forma parte de una plataforma de seguridad de software consolidada que también abarca SAST, DAST, SCA, detección de secretos, la seguridad en la nube y escaneo de imágenes de contenedores, de modo que, al localizar una imagen, se muestra junto con el código y el contexto en la nube que la rodea.

Ideal para: equipos que desean eliminar las vulnerabilidades de las imágenes base y las dependencias que ya utilizan, sin tener que migrar a una distribución de un proveedor.

{{walkthrough}}

Chainguard

Chainguard Desmonta una imagen y la vuelve a crear a partir de Wolfi, su propia distribución de Linux. Incluye en cada imagen un archivo « SBOM » firmado, así como firmas de Sigstore, y publica un acuerdo de nivel de servicio (SLA) de corrección de 7 días para las vulnerabilidades CVE críticas y de 14 días para el resto. También hay opciones de nivel federal, con variantes validadas según FIPS y refuerzo de seguridad según las directrices STIG de la DISA.

El coste es la migración y la dependencia. Adoptar Chainguard implica trasladar tus servicios a su catálogo y a Wolfi, y si tu aplicación dependía de algún elemento que Chainguard haya eliminado, dejará de funcionar. El modelo te obliga a seguir avanzando, por lo que cada corrección se implementa como un nuevo resumen que debes volver a probar y aprobar, y fijar una versión a un resumen para garantizar la reproducibilidad impide que los parches te lleguen en absoluto. 

Chainguard Además, las versiones antiguas se retiran rápidamente. Los paquetes que no son los más recientes se conservan durante unos 12 meses, y su periodo de gracia tras el fin de vida útil dura seis meses, abarca únicamente los paquetes de dependencia incluidos en una imagen —en lugar del componente principal— y queda fuera del SLA habitual de CVE. Cualquier elemento extraído del repositorio general de Wolfi OSS queda fuera del SLA, el compromiso con FIPS no se extiende a las compilaciones personalizadas, y Chainguard no indica qué contiene una imagen a nivel de CVE, por lo que su propia documentación remite a Trivy, Grype, Snyk o Docker Scout para realizar el análisis. 

Ideal para: equipos que puedan comprometerse con la distribución y la periodicidad de un único proveedor. No es adecuado para equipos que necesiten mantener estable una base o una versión sin tener que volver a realizar pruebas constantemente.

Para más información, consulta nuestra lista completa de alternativas a « Chainguard ».

Docker Hardened Images

El catálogo reforzado de Docker se lanzó en mayo de 2025 y pasó a ser gratuito y de código abierto bajo la licencia Apache 2.0 en diciembre de 2025. Vale la pena considerar DHI para los equipos que ya utilizan Docker Hub. Su objetivo es proporcionar imágenes con un número de CVE prácticamente nulo basadas en las distribuciones estándar Alpine y Debian, sin necesidad de adoptar ninguna distribución propietaria, y ofrece SBOM firmadas y certificados VEX. DHI Select añade un SLA de 7 días para CVE críticos, además de variantes FIPS y STIG, mientras que DHI Enterprise ofrece personalización con soporte ampliado del ciclo de vida hasta cinco años después del fin de vida útil del proyecto original.

El catálogo es más reciente y menos amplio que el de los proveedores consolidados, por lo que su historial en entornos con cargas de trabajo muy reguladas es más breve y no se garantiza una versión reforzada de tu base concreta. Además, la cobertura se limita a la imagen, sin incluir nada para tu código, dependencias, IaC ni secretos. Y DHI aplica las correcciones mediante actualizaciones progresivas. Las correcciones llegan en forma de nuevas versiones o resúmenes que debes volver a probar, y el «pinning» para garantizar la estabilidad retrasa la aplicación del parche.

Ideal para: Equipos que ya están en Docker Hub y que buscan imágenes reforzadas, pero que no necesitan FIPS, STIG ni un SLA, ya que estas características solo están disponibles en los planes de pago. No es adecuado para equipos cuya base concreta no se encuentre en el catálogo de Docker, que aún es bastante limitado.

RapidFort

RapidFort ofrece un catálogo de imágenes reforzadas basadas en distribuciones LTS estándar como Alpine, Debian, Ubuntu y Red Hat, en lugar de una distribución propia. La gama está orientada a trabajos en el ámbito federal y de defensa, con validación FIPS y refuerzos según STIG y CIS. Además del catálogo, RapidFort añade el análisis de perfiles en tiempo de ejecución, que supervisa qué paquetes y binarios se ejecutan realmente en producción y elimina todo aquello que no se haya detectado en ejecución.

Ese perfilado es también el inconveniente. Solo conserva lo que observa, por lo que el código que no se ejecuta durante el periodo de perfilado puede eliminarse y, posteriormente, fallar cuando finalmente se ejecute en producción. Los perfiles quedan obsoletos cuando la aplicación o su tráfico cambian, por lo que cualquier cambio significativo implica volver a realizar el perfilado y las pruebas antes de lanzar la aplicación. Y, al igual que los demás aquí mencionados, la cobertura se limita a la imagen, sin nada por encima de ella para tu código, las dependencias o la nube.

Ideal para: contratistas federales, proveedores del sector de la defensa y equipos sujetos a normativa que ya se hayan comprometido a cumplir con las normas FIPS y STIG; sin embargo, los equipos que busquen una optimización más profunda mediante la creación de perfiles en tiempo de ejecución deben tener en cuenta que es un método frágil y que requiere volver a crear los perfiles cada vez que se modifique la aplicación.

Echo

Echo es una empresa de reciente creación que ofrece una «fábrica de imágenes» basada en inteligencia artificial que recopila imágenes desde la fuente, incluyendo únicamente los componentes que necesita una aplicación, con agentes que supervisan los canales de información sobre vulnerabilidades y regeneran las imágenes a medida que se publican nuevos CVE en las fuentes originales. Las imágenes tienen como objetivo alcanzar un nivel de cero CVE, se distribuyen como sustitutos directos de las bases estándar de Docker y cuentan con validación FIPS y cumplimiento de las directrices STIG para los equipos que lo necesiten.

La cuestión principal es la madurez. Echo es una empresa en fase de Serie A con una trayectoria operativa breve, por lo que su proceso de reconstrucción y aplicación de parches es el menos probado del grupo en entornos regulados y con cargas de trabajo a escala de producción; además, su catálogo es más reducido, por lo que la cobertura para cargas de trabajo menos habituales puede ser más limitada. Al igual que el resto de esta lista, la solución consiste en distribuir una nueva imagen en lugar de aplicar parches a la versión que se está ejecutando, y la cobertura se limita a la imagen.

Ideal para: Equipos que desean una estrategia de imágenes base creadas a partir del código fuente y que pueden asumir el riesgo que supone que un proveedor de la Serie A, con una trayectoria aún corta, gestione el proceso del que dependen sus imágenes.

Preguntas frecuentes