Smol machines – máquinas virtuales portátiles con cold start de menos de 1 segundo

• smolvm es una herramienta de gestión de máquinas virtuales basada en CLI para ejecutar software en entornos aislados
• Admite cold start sub-segundo (menos de 1 segundo), gestión elástica de memoria y portabilidad en un solo archivo, lo que permite ejecutar VM de forma rápida y liviana
• Las VM se ejecutan como microVM basadas en el kernel de Linux y pueden empaquetarse como archivos .smolmachine para volver a ejecutarse sin dependencias
• Ofrece soporte integrado para entornos de desarrollo y seguridad con aislamiento mediante límites del hipervisor, reenvío del agente SSH y declaración de entorno basada en Smolfile
• Permite arrancar imágenes OCI sin daemon de Docker y propone una alternativa de virtualización liviana con tiempos de arranque de menos de 200 ms y aislamiento a nivel de hardware

---

Resumen general

• smolvm es una herramienta de gestión de máquinas virtuales basada en CLI para ejecutar software en entornos aislados
• Funciona en macOS y Linux y admite cold start sub-segundo, uso elástico de memoria y empaquetado portátil en un solo archivo
• Cada carga de trabajo se ejecuta como una microVM basada en el kernel de Linux, lo que proporciona aislamiento a nivel de hardware
• Las VM empaquetadas como archivos .smolmachine pueden volver a ejecutarse sin dependencias en plataformas con la misma arquitectura

Funciones principales

• Gestión y ejecución de máquinas virtuales locales

  • Ejecuta VM Linux personalizadas con el comando smolvm machine run
  • El cold start es de menos de 1 segundo y es compatible tanto con macOS como con Linux
  • La memoria se gestiona de forma elástica con virtio balloon, por lo que al host solo se le asigna el uso real

• Empaquetado portátil en un solo archivo

  • Puede agruparse como un archivo .smolmachine que incluye el estado de la VM para recrearlo en otra plataforma
  • Todas las dependencias van integradas, por lo que puede ejecutarse al instante sin instalación, con tiempos de arranque menores a 200 ms

• Sandbox para código no confiable

  • Separa por completo sistema de archivos del host, red y credenciales mediante límites del hipervisor
  • La red está desactivada por defecto y la opción --allow-host permite habilitar solo hosts específicos

• VM persistentes para desarrollo

  • Permite crear y gestionar VM con los comandos machine create, start y stop
  • Los paquetes instalados se conservan después de reiniciar, por lo que pueden usarse como entorno de desarrollo

• Reenvío del agente SSH

  • Reenvía el agente SSH del host hacia el interior de la VM, pero las claves privadas no se copian al guest
  • La opción --ssh-agent permite usar de forma segura la autenticación SSH del host

• Declaración de entorno basada en Smolfile

  • Declara la configuración de la VM con un Smolfile en formato TOML
  • Permite definir imágenes, red, comandos de inicialización, volúmenes y opciones de autenticación para construir entornos reproducibles

Ejemplos de uso

• Ejecución de VM temporales

  • smolvm machine run --net --image alpine -- sh -c "echo 'Hello world'"
  • Método de ejecución de un solo uso en el que la VM se limpia automáticamente al finalizar

• Creación de ejecutables empaquetados

  • smolvm pack create --image python:3.12-alpine -o ./python312
  • El ejecutable generado permite ejecutar un entorno Python independiente

• Control de red

  • La red está desactivada por defecto
  • La opción --allow-host permite autorizar acceso solo a dominios específicos

• Uso de SSH y Git

  • smolvm machine run --ssh-agent --net --image alpine
  • Permite acceder a repositorios Git usando de forma segura las claves SSH del host

Estructura interna y funcionamiento

• Cada carga de trabajo ejecuta un kernel independiente sobre Hypervisor.framework (macOS) o KVM (Linux)
• Usa un VMM basado en libkrun y un kernel personalizado (libkrunfw)
• Admite el formato de imagen OCI, por lo que puede obtener y ejecutar imágenes directamente desde Docker Hub, ghcr.io y otros registros
• No requiere daemon de Docker y puede arrancar imágenes OCI estándar tal cual
• La configuración predeterminada es de 4 vCPU y 8 GiB de RAM, ajustable con las opciones --cpus y --mem
• Los hilos de vCPU entran automáticamente en reposo en el hipervisor cuando están inactivos, por lo que el costo de sobreasignación es casi nulo

Comparación

Elemento	smolvm	Containers	Colima	QEMU	Firecracker	Kata
Nivel de aislamiento	VM por carga de trabajo	Namespaces (kernel compartido)	Namespaces (VM única)	VM individuales	VM individuales	VM por contenedor
Tiempo de arranque	<200ms	~100ms	varios segundos	15~30 segundos	<125ms	~500ms
Arquitectura	biblioteca (libkrun)	daemon	daemon dentro de una VM	proceso	proceso	stack de runtime
VM por carga de trabajo	compatible	no compatible	compartido	compatible	compatible	compatible
macOS nativo	compatible	vía VM de Docker	basado en krunkit	compatible	no compatible	no compatible
SDK integrado	compatible	no compatible	no compatible	no compatible	no compatible	no compatible
Artefacto portátil	.smolmachine	imagen que requiere daemon	no compatible	no compatible	no compatible	no compatible

Soporte de plataformas

Host	Guest	Requisitos
macOS Apple Silicon	arm64 Linux	macOS 11 o superior
macOS Intel	x86_64 Linux	macOS 11 o superior (pruebas incompletas)
Linux x86_64	x86_64 Linux	requiere KVM (/dev/kvm)
Linux aarch64	aarch64 Linux	requiere KVM (/dev/kvm)

Limitaciones conocidas

• La red está desactivada por defecto y solo puede activarse con la opción --net
• Solo admite TCP/UDP; ICMP no es compatible
• El montaje de volúmenes solo es posible a nivel de directorio; no se admiten archivos individuales
• En macOS, solo pueden ejecutarse binarios firmados con permisos de Hypervisor.framework
• Al usar --ssh-agent, debe haber un agente SSH ejecutándose en el host (requiere configurar SSH_AUTH_SOCK)

Desarrollo

• Las pautas de desarrollo pueden consultarse en docs/DEVELOPMENT.md
• Se publica bajo licencia Apache-2.0 y fue creado por @binsquare

[GN⁺]

Comentarios en Hacker News

• Estoy creando una máquina virtual para reemplazar los contenedores Docker
  Mantiene la ergonomía de los contenedores, pero apunta a tiempos de arranque por debajo de 1 segundo
  Mientras trabajaba en AWS con Firecracker, me di cuenta de que los contenedores eran una capa innecesaria, y Firecracker era una tecnología diseñada para adaptarse a la infraestructura interna de AWS
  Así que terminé creando yo mismo una forma híbrida que combina las ventajas de los contenedores y las ventajas de Firecracker
  Me gustaría escuchar opiniones

  • Esto está realmente genial. Yo también estuve investigando soluciones de sandboxing para IA y terminé creando Locki con una combinación de Lima+Incus
    El problema era que los microVM normalmente no pueden ejecutar Docker ni Kubernetes
    Yo quiero meter un clúster completo de Kubernetes dentro de un sandbox. Me pregunto si también soporta ejecutar k3s
  • Me pregunto cuál es el estado del soporte para migración en vivo
    Siempre es una función que falta en sistemas parecidos, pero todavía hay muchos entornos que la necesitan, además de las cargas de trabajo cloud-native
    Si agregan esa función, creo que sería un verdadero punto diferenciador
  • Me pregunto qué parte del código fue escrita con LLM/IA
  • Yo también hice algo parecido — se llama shuru.run
    Como Firecracker no funciona en macOS, quería una forma fácil de crear sandboxes con microVM para apps de IA
    Para un usuario común, Firecracker es demasiado pesado
  • Me pregunto cuál fue el desafío de diseño más difícil para lograr un tiempo de arranque inferior a 1 segundo
    Y también quiero saber qué cuellos de botella existen ahora mismo si quisieran reducir todavía más ese tiempo

• Este proyecto suena parecido a varias implementaciones de unikernel, como Unikraft

  • No conozco bien el interior de Unikraft porque no es open source
    Pero Smol Machines no es una implementación de unikernel, sino una versión reducida del kernel de Linux
    Por eso tiene alta compatibilidad con la mayoría del software

• La función para generar binarios autocontenidos parece una forma de empaquetar apps de JVM más simple que GraalVM Native
  Comandos de ejemplo:
  smolvm pack create --image python:3.12-alpine -o ./python312
./python312 run -- python3 --version
  → Python 3.12.x se ejecuta en un estado completamente aislado, sin necesidad de pyenv/venv/conda

  • Es una idea parecida a Electron
    Así como Electron distribuye una web app junto con el navegador, Smol Machines empaqueta el software junto con una VM de Linux
    Eso evita problemas de gestión de dependencias o compatibilidad
    Personalmente, me gustaría que herramientas como Codex o Claude Code también se distribuyeran así
  • Todos alguna vez han tenido la experiencia de “arruinar su entorno de desarrollo”
    Esto es el concepto de una “máquina distribuible” para resolver ese problema
    Si la configuras bien una sola vez, puedes compartirla y ejecutarla de inmediato con cualquiera

• Me pregunto si el archivo .smolmachine soporta firma digital y autoautenticación
  Quisiera saber si puede funcionar como la documentación de firma/verificación de Sylabs

• Me pregunto si podrían hacerlo más rápido aplicando la idea de zeroboot

• La tabla comparativa está realmente muy bien hecha
  Al principio pensé “se parece a Firecracker”, pero al ver la tabla las diferencias quedaron claras
  Fue fácil de leer y, en general, es un trabajo muy impresionante

  • Gracias

• En la documentación del CLI vi las imágenes alpine y python:3.12-alpine, y me pregunto de dónde salen
  Quisiera saber si vienen de algún lugar como un registro de Docker, si están integradas o si se crean directamente con smolfile
  También me pregunto si hay imágenes de Ubuntu
  Estaría bueno que agregaran hot resize de memoria/CPU, y parece que también podría usarse para orquestar infraestructura backend por cliente

• La mayoría de los proyectos open source levantan contenedores con Docker Compose, pero Smol Machines no soporta Docker dentro del microVM
  También es una lástima que no soporte VM anidadas como Vagrant

  • El soporte para Docker está planeado. En la próxima release pensamos distribuir un kernel compatible con los flags necesarios
  • Como Vagrant levanta una VM en local, parece que por eso se necesita nesting
    En su lugar, propongo ejecutarlo como una VM hermana de la VM de Vagrant usando un método trampolín

• Me pregunto si podrías explicar brevemente cuál es la razón principal para usar Smol Machines en vez de un sandbox de Docker

• Es un resultado realmente genial. Felicitaciones