Kiri vs Docker Desktop: la verdad detrás del 80x viral
En pocas palabras: Kiri es un runtime de contenedores en Rust (Apache-2.0) que compite con Docker Desktop. El “80 veces más rápido” solo aplica a la llamada a la Docker Engine API (2,55 ms vs 213 ms); medido por CLI completo baja a 17 veces, y la propia web oficial de Kiri usa 8 veces como cifra real.
Kiri es un runtime de contenedores escrito en Rust que se presenta como alternativa a Docker Desktop y OrbStack. Un video viral asegura que arranca contenedores en 2,5 milisegundos, 80 veces más rápido que Docker Desktop, pero esa cifra sale de la medición más angosta del propio proyecto: por CLI completo la diferencia real baja a 17 veces, y en la web oficial el titular usa 8 veces.
Kiri es un runtime de contenedores open source (licencia Apache-2.0) desarrollado por libracoder, pensado como Kiri alternativa a Docker Desktop en macOS, Windows y Linux. En Mac bootea una VM Linux liviana vía Virtualization.framework de Apple, en Linux corre directo sobre el kernel del host, y en Windows usa WSL 2. Funciona con los comandos docker, Compose y buildx que ya tenés instalados, sin pedirte que reescribas nada.
En este artículo:
- En 30 segundos
- ¿Cómo logra Kiri iniciar contenedores en milisegundos?
- ¿De dónde sale realmente el número de 80 veces más rápido?
- ¿Cuánta memoria consume Kiri frente a Docker Desktop y OrbStack?
- ¿Qué riesgos de seguridad y compatibilidad tiene Kiri hoy?
- ¿Conviene reemplazar Docker Desktop por Kiri ahora mismo?
- Qué está confirmado y qué no
- Errores comunes al evaluar el hype de Kiri
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- El 80x es real pero recortado: mide solo la llamada a la Docker Engine API (2,55 ms en Kiri vs 213 ms en Docker Desktop), sin contar el tiempo del CLI.
- Medido con CLI completo, el número cae a 17x: 14,2 ms en Kiri contra 243 ms en Docker Desktop, según el mismo README del proyecto.
- En runkiri.com el titular usa 8x: 22 ms contra 178 ms en Docker Desktop, con
docker runreal. - El repositorio tiene apenas días: se creó el 2 de noviembre de 2026, con 139 estrellas y 2 colaboradores al 5 de noviembre.
- Hay bugs de compatibilidad documentados: faltan expresiones nftables en el kernel de la VM y el bind a puerto 80 sin privilegios falla.
¿Cómo logra Kiri iniciar contenedores en milisegundos?
Kiri elimina capas que Docker Desktop y OrbStack sí tienen. En lugar de pasar por runc, un shim por contenedor y dockerd, el daemon de Kiri habla directo con un agente Rust que corre como PID 1 dentro de una VM mínima, y ese agente crea el contenedor con una sola llamada a clone3 hacia namespaces y cgroups, según el README del proyecto.
El flujo completo es este: docker CLI → Docker Engine API → kiri daemon → vsock → guest agent (PID 1) → clone3 → container. Nada de eso pasa por un shim que quede corriendo. El kernel de la VM pesa unos 10 MB y el agente que vive adentro, según el README, ronda los 900 KB (el archivo de resultados de benchmarks lo mide en 650 KB, así que hay una diferencia de criterio entre documentación y medición real).
En Linux no hay VM de por medio: el agente corre directo sobre el kernel del host. En Windows, Kiri se apoya en WSL 2. Esa diferencia importa más de lo que parece, y la retomo más abajo cuando hablo de seguridad, porque no tener una VM de por medio en Linux cambia el perímetro de protección frente a Mac.
¿De dónde sale realmente el número de 80 veces más rápido?
El 80x sale de medir solo la llamada a la API, no la experiencia completa del usuario en la terminal. El benchmark corrió un contenedor alpine ejecutando true y después lo borró, con mediana de 30 corridas, usando el mismo docker CLI para los tres motores: Kiri, Docker Desktop y OrbStack. Relacionado: otra herramienta self-hosted que corre en Docker.
Vía Docker Engine API, Kiri tardó 2,55 ms, Docker Desktop 213 ms y OrbStack 380 ms. Ahí sale el 83x que redondean a 80. Pero medido por CLI completo (el tiempo que el usuario realmente percibe cuando tipea un comando), los números cambian: Kiri 14,2 ms, Docker Desktop 243 ms, OrbStack 442 ms. Esa cuenta da 17x, no 80x.
¿Y qué número usa el propio sitio del proyecto para su titular? Ni 80x ni 17x: usa 8x, con docker run real tomando 22 ms en Kiri contra 178 ms en Docker Desktop, según runkiri.com. Tres cifras distintas, ninguna falsa, cada una midiendo un corte distinto del mismo proceso. El problema es cuál de las tres termina en el titular de un clip de redes.
Todo esto se midió en una sola Mac con Apple Silicon, con cada motor limitado a 2 CPU y 8 GB de RAM. Un detalle que el propio archivo de resultados admite: durante la medición de OrbStack había 86 contenedores corriendo junto con un clúster de Kubernetes activo, lo que infla artificialmente el tiempo de OrbStack en esa comparación puntual.
¿Cuánta memoria consume Kiri frente a Docker Desktop y OrbStack?
El daemon de Kiri usa 9,7 MB en total según el archivo de benchmarks: 9,0 MB en el proceso del Mac más 0,69 MB del agente dentro de la VM. El README redondea esa cifra a “15 MB”, que probablemente incluya componentes adicionales que el bench no desglosa.
Para dar contexto, el mismo archivo de Kiri midió a OrbStack con dockerd más containerd en 216 MB, sumado a unos 7,9 MB por cada shim activo. Con 143 contenedores corriendo, esos shims solos acumulaban 1.133 MB. Ojo con este dato: es una medición hecha por Kiri sobre OrbStack, no un número publicado por OrbStack, así que tomalo como referencia de orden de magnitud y no como verdad absoluta de la competencia. Complementá con si todavía no tenés Docker instalado en Windows.
| Herramienta | Vía Docker API | Vía CLI completo | Memoria del daemon | Precio |
|---|---|---|---|---|
| Kiri | 2,55 ms | 14,2 ms | 9,7 MB | Gratis (beta, v0.1.17/v0.1.18) |
| Docker Desktop | 213 ms | 243 ms | Sin dato publicado | Gratis hasta 250 empleados o USD 10M de ingresos anuales |
| OrbStack | 380 ms | 442 ms | 216 MB + ~7,9 MB por shim | Gratis uso personal, Pro USD 8/mes anual o USD 96/año |
¿Qué riesgos de seguridad y compatibilidad tiene Kiri hoy?
Kiri tiene al menos dos bugs de compatibilidad documentados en sus propios issues de GitHub y le falta documentación de seguridad que un evaluador externo ya marcó como ausente. Nada de esto invalida el proyecto, pero sí condiciona para qué lo podés usar hoy.
Ponele que corrés un test suite de reglas de firewall dentro de un contenedor. El issue #14 documenta exactamente eso: al kernel de la VM le faltan varias expresiones de nftables que sí existen en OrbStack y Docker Desktop, y tampoco expone /proc/modules, así que no podés cargar módulos adicionales. El mismo hilo registra otro caso: net.ipv4.ip_unprivileged_port_start viene en 1024 en Kiri contra 0 en Docker Desktop, lo que rompe cualquier imagen que intente bindear el puerto 80 con un usuario sin privilegios. El propio maintainer confirmó el bug y dijo que lo va a arreglar.
El issue #13 es más delicado: un evaluador independiente que abrió el repositorio para revisarlo escribió que no encontró política de seguimiento de CVEs del kernel de la VM ni un documento de threat model publicado. Para una empresa que necesita auditar software antes de instalarlo, esa es una pregunta sin respuesta todavía.
Eso sí, hay algo que juega a favor: la documentación de Kiri es honesta sobre sus límites. Dice directamente que contenedores con --privileged o seccomp desactivado siguen contenidos por el perímetro de la VM, sin sockets vsock que lleguen al Mac. Pero en Linux no hay VM de por medio, y ahí el agente corre sobre el kernel del host sin esa capa extra: ser parte del grupo kiri equivale a root, exactamente como pasa hoy con el grupo docker. El instalador de Windows todavía no tiene Authenticode (está “pendiente”, según las notas de release) y los builds de Linux no son reproducibles byte a byte.
¿Conviene reemplazar Docker Desktop por Kiri ahora mismo?
No, todavía no para un equipo entero, y sí para probarlo en una máquina personal sin apuro. El repositorio se creó el 2 de noviembre de 2026, tiene 139 estrellas, 2 colaboradores y su último release documentado es v0.1.17 (la web muestra v0.1.18). Eso no es poco para dos días de vida, pero tampoco es una base sólida para meterlo en CI de producción. Ya lo cubrimos antes en las opciones gratuitas frente a Docker Desktop.
Los dos hilos de Hacker News que circulan en el clip viral tampoco sostienen el hype: uno tiene 2 puntos y cero comentarios, el otro tiene 6 puntos, 4 comentarios y terminó marcado (flag). Los pocos comentarios que hay critican más el texto del posteo (que suena escrito con IA) que el código en sí. No hay reseñas de nadie que lo haya usado por semanas o meses en un proyecto real.
Mi recomendación práctica, si te interesa probarlo sin arriesgar nada: instalá Kiri en paralelo con docker context create kiri en vez de pisar tu instalación actual, corré kiri bench en tu propia máquina antes de creerte cualquier número publicado en una web (los suyos incluidos), y revisá si tu test suite usa nftables o bindea puertos bajos con usuario no privilegiado antes de darlo por compatible. Volver atrás es tan simple como docker context use default. Para equipos con requisitos de auditoría de seguridad, esperá a que haya threat model publicado y el instalador de Windows firmado.
Qué está confirmado y qué no
- Confirmado: los tres benchmarks (80x, 17x y 8x) existen y vienen de mediciones documentadas en el README, en bench/results.json y en runkiri.com.
- Confirmado: los bugs de nftables y de puerto privilegiado están registrados en issues públicos, con respuesta del maintainer.
- Confirmado: el repositorio se creó el 2 de noviembre de 2026 y tiene licencia Apache-2.0.
- No confirmado: que exista una política de seguimiento de CVEs del kernel de la VM o un threat model publicado, según lo que encontró un evaluador externo.
- No confirmado: rendimiento en un uso de semanas o meses en producción, porque no hay reseñas independientes de largo plazo todavía.
Errores comunes al evaluar el hype de Kiri
- Tomar el 80x como universal: ese número mide solo la llamada cruda a la Docker Engine API, sin el tiempo del CLI. Con CLI completo, la diferencia real es 17x.
- Asumir compatibilidad total porque “usa los mismos comandos”: los issues #14 muestran que test suites que pasan en OrbStack y Docker Desktop fallan en Kiri por diferencias de kernel y de configuración de red.
- Confundir un hilo de Hacker News con validación de la comunidad: 2 puntos sin comentarios o 6 puntos con flag no es lo mismo que una revisión técnica seria.
- Usar la cifra de memoria de OrbStack que publica Kiri como dato oficial de OrbStack: es una medición hecha por el proyecto competidor, no un número que OrbStack haya publicado.
Preguntas Frecuentes
¿Kiri es realmente 80 veces más rápido que Docker Desktop?
Solo en la medición más estrecha: la llamada directa a la Docker Engine API da 2,55 ms en Kiri contra 213 ms en Docker Desktop. Medido por CLI completo, que es lo que el usuario percibe al tipear un comando, la diferencia baja a 17 veces (14,2 ms contra 243 ms).
¿Cómo arranca Kiri los contenedores tan rápido?
Elimina capas intermedias: no usa runc, no usa un shim por contenedor y no usa dockerd. Un agente Rust de PID 1 dentro de una VM mínima crea cada contenedor con una sola llamada a clone3 directo a namespaces y cgroups. Tema relacionado: automatizar la publicación de imágenes con GitHub Actions.
¿Kiri es seguro para usar en una empresa?
Todavía no hay garantías suficientes para entornos con requisitos de auditoría: un evaluador independiente no encontró política de seguimiento de CVEs del kernel ni un threat model publicado, y el instalador de Windows aún no tiene firma Authenticode.
¿Kiri funciona con los mismos comandos y Dockerfile que ya uso?
En la mayoría de los casos sí, porque Kiri habla la Docker Engine API y acepta docker, Compose y buildx sin cambios. Pero hay excepciones documentadas, como fallas con reglas de nftables y con el bind a puerto 80 sin privilegios de usuario.
¿Conviene cambiar de Docker Desktop u OrbStack a Kiri hoy?
No para un equipo completo todavía, porque el proyecto tiene días de vida (creado el 2 de noviembre de 2026) y le faltan documentos de seguridad básicos. Probarlo en paralelo con docker context en una máquina personal es razonable; migrar producción no.
Conclusión
Kiri existe, tiene código real, tiene documentación que admite sus propios límites, y tiene al menos una revisión externa de arquitectura con comentarios positivos sobre el perímetro de seguridad en Mac. Eso es más de lo que suele tener un proyecto de dos días. El problema no es el proyecto: es el titular de 80x circulando sin la letra chica de qué se midió y en qué máquina.
Si usás Mac y te molesta el consumo de RAM o el arranque lento de Docker Desktop, y tu trabajo es correr las mismas imágenes con los mismos comandos sin depender de funciones raras de Docker, vale la pena que lo prueben en paralelo. Si tu equipo necesita pasar auditorías de seguridad o depende de reglas de firewall avanzadas dentro de contenedores, esperá unos meses más hasta que aparezcan el threat model público y una base de usuarios con experiencia real, no solo con el entusiasmo de un clip de 30 segundos.
