Principales alternativas a Minimus en 2026

Actualización, 27 de agosto de 2026: Echo ha adquirido los activos de Minimus y se posiciona como la ruta de migración para los clientes de Minimus. El registro seguirá cerrando el 22 de octubre, por lo que si ejecutas imágenes de Minimus todavía debes migrar. Moverse a Echo significa pasar a las imágenes y al ciclo de publicaciones de Echo, el mismo modelo de catálogo de proveedores que estás dejando atrás, por lo que vale la pena compararlo con un enfoque que parchea la base que ya ejecutas. Más información sobre Echo a continuación.

Minimus va a cerrar y su registro (reg.mini.dev) dejará de funcionar 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 realizar la migración.

Incluso antes de esto, su modelo no funcionaba para todo el mundo. Adoptar Minimus implicaba migrar a sus propias imágenes, construidas sobre su propia distribución (MinimOS), y depender de su ritmo de lanzamientos. Y dado que las imágenes no tienen shell ni gestor de paquetes (distroless), todo lo que dependía de tu configuración y que Minimus eliminó tuvo que ser rehecho. 

Existen alternativas que evitan esto. En lugar de trasladarte a la distribución de un proveedor, parchean la imagen base que ya utilizas y, cuando has fijado una versión, aplican los correcciones retroactivamente (backporting) en lugar de obligarte a avanzar. Esta publicación detalla los siguientes pasos.

Esta publicación detalla cuáles son los siguientes pasos y qué debes buscar para no tener que migrar de nuevo en un año. Comparamos:

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

TL;DR

Nuestra opción principal es Aikido Security. En lugar de migrarte a una nueva distribución, parchea la imagen base que ya ejecutas, para que nada se rompa y la corrección llegue como una solicitud de incorporación de cambios (pull request) que fusionas una sola vez. Después de eso, Aikido sigue reconstruyendo la imagen a medida que se parchean nuevas vulnerabilidades y te avisa cuando hay una compilación más reciente disponible. Cada imagen es un reemplazo directo con un SBOM, VEX y procedencia SLSA, cubriendo CVEs a nivel de SO bajo un SLA de creación de parches definido. Sigue parcheando versiones incluso después del fin de vida útil (end-of-life), y se integra en una plataforma que también cubre SAST, DAST, SCA, detección de secretos y postura en la nube. Habiendo migrado ya a los clientes de Root, Aikido puede sacarte de Minimus de la misma manera.

{{cta}}

Lo que Minimus hacía bien

Minimus construía sus imágenes sin distribuciones (distroless) desde el código fuente utilizando su propia distribución, MinimOS, incluyendo únicamente lo necesario para ejecutar una aplicación y eliminando las herramientas de shell y de gestión de paquetes que amplían la superficie de ataque. El catálogo contaba con más de 1.200 imágenes con líneas base de FIPS, CIS, NIST y STIG, y en junio de 2026 todo el servicio pasó a ser gratuito y sin necesidad de registro. Para las imágenes que encajaban directamente, la adopción se reducía a un cambio de una sola línea en un Dockerfile o en un archivo de manifiesto.

Por qué necesitas una alternativa a Minimus ahora

El catálogo de Minimus va a cerrar y no habrá más actualizaciones para sus imágenes después del 22 de octubre. Todo lo que ya hayas descargado seguirá funcionando, pero las CVE se acumularán sin que llegue ningún parche de reemplazo.

Si quieres mantener tus imágenes libres de vulnerabilidades, ahora te ves obligado a realizar una costosa migración para salir de Minimus. Salir de allí implica sustituir cada imagen de Minimus que aloje uno de tus servicios por otra fuente y volver a realizar pruebas. La migración es inevitable en este punto, por lo que vale la pena elegir un reemplazo que no te encadene a su propia distribución y ritmo, o te encontrarás haciendo esto de nuevo la próxima vez que un proveedor cambie de rumbo. 

Y aunque te viniera bien migrar a su distribución, el modelo era frágil. Minimus reconstruía imágenes desde el origen y lanzaba nuevas versiones, por lo que, incluso cuando el número de versión no cambiaba, una imagen parcheada implicaba un nuevo resumen (digest). Mantenerse al día significaba actualizar a cada una de ellas, y cada actualización representaba una nueva imagen que probar y volver a aprobar.

Actualizar funcionaba bien hasta que dejaba de hacerlo. Por ejemplo, una CVE afectaba a una biblioteca en tu imagen y la solución se lanzaba en la versión 2.1, pero otro paquete del que dependías solo aceptaba versiones inferiores a la 2.0. Lo sensato era fijar esa dependencia a una versión exacta, pero entonces no podías actualizar y la imagen simplemente acumulaba vulnerabilidades. 

Qué buscar en una alternativa a Minimus

• Un catálogo amplio y listo para usar: ¿Cuántas de las imágenes base que utilizas realmente cubre ya? Busca una verdadera variedad en Debian, Ubuntu y Alpine, tanto en arquitecturas amd64 como arm64.
• Procedencia verificable: Un SBOM firmado, un documento VEX y la procedencia SLSA adjuntos a cada descarga (pull), para que puedas demostrar qué contiene una imagen y cómo se ha construido.
• Seguridad más allá del fin de vida útil (EOL): Parches que continúan incluso después de que la distribución de origen avanza, lo que te permite mantener una base anterior sin arrastrar sus CVE críticos y altos conocidos.
• Cobertura más allá de la imagen base: Busca una herramienta que también llegue a tus dependencias, código (SAST), IaC, secretos y runtime, para que cualquier hallazgo llegue con el contexto que lo rodea.
• Evidencia de cumplimiento normativo por defecto: Líneas base de FIPS, CIS, NIST y STIG con los artefactos de auditoría generados de forma automática.
• Un proveedor con solidez financiera en la que puedas confiar: Evalúa el respaldo, la trayectoria y cuánto perderías si esto volviera a suceder.

Principales alternativas a Minimus

Aikido Security

Mientras que Minimus te obligaba a migrar a su propia distribución, Aikido parchea la imagen base que ya utilizas. Aikido Images es un registro con más de 2.000 reemplazos directos (drop-in) en los que las vulnerabilidades críticas y altas conocidas de la base ya están solucionadas. Esas imágenes se reconstruyen, parchean, minimizan y endurecen durante el proceso de compilación, de modo que obtienes el tratamiento completo —una superficie de ataque más reducida y valores predeterminados más seguros— sobre la base que ya ejecutas.

Para ejemplo, debian:bookworm proporciona un parche glib2.0 para la vulnerabilidad CVE-2025-4373, que Debian solucionó en Trixie y Sid, pero no en Bookworm. La variante de Aikido Images de debian:bookworm incorpora el archivo glib2.0 parcheado que la soluciona.

Dado que el intercambio es un reemplazo directo que AutoFix propone como solicitud de extracción (pull request), la solución se aplica en el momento en que realizas el *merge*, y cada descarga desde docker.aikido.io llega acompañada de un SBOM, VEX y procedencia SLSA. Aikido sigue parcheando versiones incluso después de que el upstream haya avanzado, incluidas aquellas que han llegado al fin de su vida útil (EOL), para que puedas mantenerte en una base anterior sin acarrear sus fallos de seguridad conocidos y sin que se te presione para actualizar a una versión más reciente con el fin de mantener la cobertura.

El equipo detrás de estas imágenes se incorporó a través de la adquisición por parte de Aikido de Root, la empresa creadora de SlimToolkit (anteriormente DockerSlim), una de las herramientas de endurecimiento de imágenes de código abierto más utilizadas, con más de 23.000 estrellas en GitHub y una capacidad documentada para reducir el tamaño de las imágenes hasta 30 veces. Los clientes actuales de Root fueron migrados a Aikido Images y Libraries, y Aikido puede ayudarte a salir de 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, incluidas 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 6.000 desarrolladores. Una empresa con la solvencia necesaria para adquirir Root por completo no es la clase de compañía que va a apagar su registro de repente.

Una parte cada vez mayor de las soluciones reales no recibe nunca una CVE. La monitorización continua de Aikido se alimenta en parte de Aikido Intel, que analiza los registros de cambios (changelogs) y el historial de confirmaciones (*commits*) de los proyectos originales para detectar vulnerabilidades que se parchearon silenciosamente sin una CVE de por medio. Y mientras que la mayoría de estas herramientas solucionan una CVE actualizando el paquete afectado a una versión más reciente, Aikido hace un uso intensivo de parches retroportados (*backports*), tomando la solución de la versión más nueva y aplicándola a la versión que ya estás ejecutando. Esto mantiene los cambios mínimos, por lo que es más probable que la imagen se comporte tal y como espera tu aplicación, reduciendo la deuda de actualización que se acumula cuando se te obliga a pasar a nuevas versiones.

Cuando no es posible realizar un backport limpio, Aikido actualiza o recompile el componente en su lugar. También asigna cada contenedor a la base de la que hereda y te indica el cambio que elimina el mayor riesgo en toda la organización, con más de 100 parches investigados y probados diariamente y una cobertura a nivel de sistema operativo bajo un SLA de creación de parches definido.

Las vulnerabilidades de paquetes a nivel de aplicación en ecosistemas como npm, PyPI, Maven y Go se parchean in situ a través de Aikido Libraries. Todo ello se integra en una plataforma madura de seguridad de software que también abarca SAST, DAST, SCA, detección de secretos, postura de la nube y escaneo de imágenes de contenedores, de modo que cualquier hallazgo en una imagen se presenta con el contexto de código y nube que lo rodea.

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

{{walkthrough}}

Chainguard

Chainguard reduce una imagen al mínimo y la recompila a partir de Wolfi, su propia distribución de Linux. Entrega cada imagen con un SBOM firmado y firmas de Sigstore, y publica un SLA de remediación de 7 días para CVE críticos y 14 para el resto. También ofrece opciones de nivel federal, con variantes con validación FIPS y endurecimiento (hardening) DISA STIG.

El coste es la migración y la dependencia del proveedor (lock-in). Adoptar Chainguard significa trasladar tus servicios a su catálogo y a Wolfi, y si tu aplicación dependía de algo que Chainguard eliminó, fallará. El modelo te obliga a avanzar continuamente, por lo que cada corrección llega como un nuevo resumen (digest) que debes volver a probar y aprobar, y fijar una versión (pinning) para la reproducibilidad impide que los parches te lleguen por completo. 

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

Ideal para: Equipos que pueden comprometerse con la distribución y el ritmo de un único proveedor. No apto para equipos que necesitan mantener una base o una versión estables sin necesidad de realizar pruebas constantes.

Para obtener más detalles, consulta nuestra lista completa de alternativas a Chainguard.

Docker Hardened Images

El catálogo endurecido de Docker se lanzó en mayo de 2025 y pasó a ser de código abierto y gratuito bajo la licencia Apache 2.0 en diciembre de 2025. DHI vale la pena para los equipos que ya utilizan Docker Hub. Su objetivo es ofrecer imágenes con casi cero CVE sobre bases estándar de Alpine y Debian, sin necesidad de adoptar una distribución privativa, y suministra SBOM firmados y atestaciones VEX. DHI Select añade un SLA de 7 días para CVE críticos, además de variantes FIPS y STIG, y DHI Enterprise añade personalización con soporte de ciclo de vida extendido de hasta cinco años después del fin de vida útil de la versión original (upstream).

El catálogo es más reciente y menos extenso que el de los actores consolidados, por lo que su historial en cargas de trabajo muy reguladas es más corto y no se garantiza una versión endurecida de tu base exacta. Además, la cobertura termina en la imagen, sin incluir nada para tu código, dependencias, IaC o secretos. Y DHI remedia avanzando. Una corrección llega como una nueva versión o resumen (digest) que debes volver a probar, y fijar la versión (pinning) para mantener la estabilidad detiene la aplicación del parche.

Ideal para: Equipos que ya utilizan Docker Hub y desean imágenes endurecidas sin necesidad de FIPS, STIG o un SLA, los cuales se encuentran en los niveles de pago. No apto para equipos cuya base exacta no esté en el catálogo, todavía limitado, de Docker.

RapidFort

RapidFort ofrece un catálogo de imágenes endurecidas basadas en distribuciones LTS estándar como Alpine, Debian, Ubuntu y Red Hat en lugar de una distribución privativa. Su oferta está orientada a proyectos federales y de defensa, con validación FIPS y endurecimiento (hardening) STIG y CIS. Además del catálogo, RapidFort incorpora perfiles en tiempo real (runtime profiling), supervisando qué paquetes y binarios se ejecutan realmente en producción y eliminando todo lo que no se haya visto en ejecución.

Ese perfilado es también su principal inconveniente. Solo conserva lo que observa, por lo que el código que no se activa durante el periodo de análisis puede ser eliminado y fallar cuando finalmente se ejecute en producción. Los perfiles quedan desactualizados cuando la aplicación o su tráfico cambian, por lo que cualquier modificación relevante implica volver a perfilar y probar antes de desplegar. Y al igual que los demás en esta lista, la cobertura se detiene en la imagen, sin ofrecer nada por encima para tu código, dependencias o entorno en la nube.

Ideal para: Contratistas federales, proveedores del sector de defensa y equipos regulados que ya se han comprometido con el cumplimiento de FIPS y STIG. Sin embargo, los equipos que opten por la optimización basada en perfiles en tiempo real deben saber que es frágil y requiere volver a perfilar cada vez que la aplicación cambie.

Echo

En agosto de 2026, Echo adquirió los activos de Minimus y se convirtió en el proveedor hacia el cual Minimus está orientando a sus clientes. Para un equipo que usa Minimus, esa es la vía de menor resistencia, pero vale la pena tener claro de qué se trata. Estarías migrando a las imágenes de otro proveedor, creadas y reconstruidas según su propio ritmo, que es justamente el modelo del que te están obligando a salir. Echo incorpora el trabajo del sistema operativo de Minimus en su propio catálogo en lugar de mantener vivas las imágenes de Minimus, por lo que tendrás que reestructurar tu plataforma de todos modos.

Echo es un nuevo participante en el mercado que ofrece una fábrica de imágenes impulsada por IA capaz de compilar imágenes desde el código fuente, incluyendo únicamente los componentes que necesita una aplicación. Cuenta con agentes que supervisan los feeds de vulnerabilidades y regeneran las imágenes a medida que surgen CVEs en las versiones originales (upstream). Las imágenes buscan alcanzar cero CVEs, se distribuyen como reemplazos directos (drop-in) de las bases estándar de Docker, y cuentan con validación FIPS y alineación STIG para los equipos que lo requieran.

La cuestión principal es su madurez. Echo es una empresa en ronda Serie A con una corta trayectoria operativa, por lo que su proceso de reconstrucción y parcheo es el menos probado de todo el grupo bajo cargas de trabajo reguladas y a escala de producción. Asimismo, su catálogo es más reducido, por lo que la cobertura para cargas de trabajo menos comunes puede ser más limitada. Al igual que el resto de esta lista, la remediación se realiza mediante el envío de una nueva imagen en lugar de parchear la versión que estás ejecutando, y la cobertura se detiene en la imagen.

Ideal para: Equipos de Minimus que buscan el cambio con el menor esfuerzo posible, que no tienen inconveniente en adoptar el catálogo de otro proveedor y que pueden asumir el riesgo de un proveedor de Serie A con una trayectoria corta gestionando el pipeline del que dependen sus imágenes.

Preguntas frecuentes