Smol machines – cold start em menos de 1 segundo e máquinas virtuais portáteis

• smolvm é uma ferramenta de gerenciamento de máquinas virtuais baseada em CLI que executa software em ambientes isolados no macOS e Linux
• Suporta cold start em menos de 1 segundo, gerenciamento elástico de memória e portabilidade em arquivo único, permitindo executar VMs de forma rápida e leve
• As VMs rodam no formato de microVM baseada em kernel Linux e podem ser empacotadas em arquivos .smolmachine, possibilitando reexecução sem dependências
• Oferece suporte integrado a ambientes de desenvolvimento e segurança com isolamento por fronteira de hipervisor, encaminhamento de agente SSH e declaração de ambiente baseada em Smolfile
• Suporta boot de imagens OCI sem daemon Docker e se apresenta como uma alternativa de virtualização leve com tempo de boot abaixo de 200ms e isolamento em nível de hardware

---

Visão geral

• smolvm é uma ferramenta de gerenciamento de máquinas virtuais baseada em CLI para executar software em ambientes isolados
• Funciona em macOS e Linux e oferece cold start em menos de 1 segundo, uso elástico de memória e empacotamento portátil em arquivo único
• Cada workload é executada em uma microVM baseada em kernel Linux, oferecendo isolamento em nível de hardware
• VMs empacotadas em arquivos .smolmachine podem ser reexecutadas sem dependências em plataformas com a mesma arquitetura

Principais recursos

• Gerenciamento e execução de máquinas virtuais locais

  • Execução de VMs Linux customizadas com o comando smolvm machine run
  • O cold start leva menos de 1 segundo, com suporte para macOS e Linux
  • A memória é gerenciada elasticamente com virtio balloon, de forma que apenas o uso real é alocado no host

• Empacotamento portátil em arquivo único

  • Pode ser agrupado em um arquivo .smolmachine incluindo o estado da VM, permitindo recriação em outra plataforma
  • Todas as dependências são embutidas, permitindo execução imediata sem instalação, com tempo de boot abaixo de 200ms

• Sandbox para código não confiável

  • Sistema de arquivos do host, rede e credenciais são completamente separados por meio da fronteira do hipervisor
  • A rede vem desativada por padrão, e apenas hosts específicos podem ser permitidos com a opção --allow-host

• VMs persistentes para desenvolvimento

  • Criação e gerenciamento de VMs com os comandos machine create, start e stop
  • Os pacotes instalados permanecem após reinicializações, permitindo uso como ambiente de desenvolvimento

• Encaminhamento de agente SSH

  • O agente SSH do host é encaminhado para dentro da VM, mas a chave privada não é copiada para o guest
  • A autenticação SSH do host pode ser usada com segurança por meio da opção --ssh-agent

• Declaração de ambiente baseada em Smolfile

  • A configuração da VM pode ser declarada com um Smolfile em formato TOML
  • É possível definir imagem, rede, comandos de inicialização, volumes e opções de autenticação para criar ambientes reproduzíveis

Exemplos de uso

• Execução de VM temporária

  • smolvm machine run --net --image alpine -- sh -c "echo 'Hello world'"
  • Modo de execução descartável em que a VM é limpa automaticamente ao encerrar

• Criação de executável empacotado

  • smolvm pack create --image python:3.12-alpine -o ./python312
  • O executável gerado permite executar um ambiente Python independente

• Controle de rede

  • A rede vem desativada por padrão
  • A opção --allow-host permite acesso apenas a domínios específicos

• Uso de SSH e Git

  • smolvm machine run --ssh-agent --net --image alpine
  • Permite acessar repositórios Git usando com segurança as chaves SSH do host

Estrutura interna e funcionamento

• Cada workload executa um kernel independente sobre Hypervisor.framework (macOS) ou KVM (Linux)
• Usa VMM baseado em libkrun e kernel customizado (libkrunfw)
• Suporta o formato de imagem OCI, podendo buscar e executar imagens diretamente do Docker Hub, ghcr.io e outros
• Não requer daemon Docker, podendo inicializar imagens OCI padrão diretamente
• A configuração padrão é 4 vCPU e 8GiB de RAM, ajustável com as opções --cpus e --mem
• Threads de vCPU entram automaticamente em economia de energia no hipervisor quando ociosas, então o custo de overcommit é quase nulo

Comparação

Item	smolvm	Containers	Colima	QEMU	Firecracker	Kata
Nível de isolamento	VM por workload	Namespaces (kernel compartilhado)	Namespaces (VM única)	VM individual	VM individual	VM por contêiner
Tempo de boot	<200ms	cerca de 100ms	alguns segundos	15~30s	<125ms	cerca de 500ms
Arquitetura	biblioteca (libkrun)	daemon	daemon dentro da VM	processo	processo	stack de runtime
VM por workload	Suportado	Não suportado	Compartilhado	Suportado	Suportado	Suportado
macOS nativo	Suportado	via VM do Docker	baseado em krunkit	Suportado	Não suportado	Não suportado
SDK embutido	Suportado	Não suportado	Não suportado	Não suportado	Não suportado	Não suportado
Artefato portátil	.smolmachine	imagem que requer daemon	Não suportado	Não suportado	Não suportado	Não suportado

Suporte de plataforma

Host	Guest	Requisitos
macOS Apple Silicon	arm64 Linux	macOS 11 ou superior
macOS Intel	x86_64 Linux	macOS 11 ou superior (testes incompletos)
Linux x86_64	x86_64 Linux	Requer KVM (/dev/kvm)
Linux aarch64	aarch64 Linux	Requer KVM (/dev/kvm)

Limitações conhecidas

• A rede vem desativada por padrão e só pode ser ativada com a opção --net
• Suporta apenas TCP/UDP, sem suporte a ICMP
• Montagem de volumes é possível apenas no nível de diretório, não para arquivos individuais
• No macOS, só é possível executar binários assinados com permissão do Hypervisor.framework
• Ao usar --ssh-agent, é necessário que um agente SSH esteja em execução no host (SSH_AUTH_SOCK precisa estar definido)

Desenvolvimento

• As diretrizes de desenvolvimento podem ser consultadas em docs/DEVELOPMENT.md
• Disponibilizado sob a licença Apache-2.0 e criado por @binsquare

[GN⁺]

Comentários no Hacker News

• Estou criando uma máquina virtual para substituir contêineres Docker
  mantendo a mesma ergonomia dos contêineres, mas com tempo de inicialização abaixo de 1 segundo
  Trabalhando com Firecracker na AWS, percebi que contêineres eram uma camada desnecessária, e o Firecracker era uma tecnologia projetada para se encaixar na estrutura interna da AWS
  Então acabei criando eu mesmo uma forma híbrida que combina as vantagens dos contêineres com as do Firecracker
  Gostaria de ouvir opiniões

  • Isso é realmente muito legal. Eu também estava pesquisando uma solução de sandboxing para IA e acabei criando o Locki com a combinação Lima+Incus
    O problema com microVMs normalmente era que elas não conseguiam rodar Docker ou Kubernetes
    Quero colocar um cluster Kubernetes inteiro dentro de uma sandbox. Queria saber se também suporta rodar k3s
  • Queria saber qual é o estado do suporte a migração ao vivo
    É um recurso que sempre fica faltando em sistemas parecidos, mas ainda há muitos ambientes que precisam disso além de workloads cloud-native
    Se vocês colocarem isso, parece que pode virar um verdadeiro diferencial
  • Queria saber quanto do código foi escrito com LLM/IA
  • Eu também construí algo parecido — chama-se shuru.run
    Como o Firecracker não roda no macOS, eu queria facilitar a criação de sandboxes microVM para apps de IA
    Para usuários comuns, o Firecracker é pesado demais
  • Queria saber qual foi o desafio de arquitetura mais difícil para atingir tempo de boot abaixo de 1 segundo
    E também gostaria de saber quais são hoje os gargalos para reduzir ainda mais esse tempo

• Este projeto soa parecido com várias implementações de unikernel — por exemplo, coisas como Unikraft

  • Não conheço bem o interior do Unikraft porque não é open source
    Mas o Smol Machines não é uma implementação de unikernel, e sim uma versão enxuta do kernel Linux
    Então ele mantém alta compatibilidade com a maior parte dos softwares

• O recurso de geração de binário autossuficiente parece uma forma de empacotar apps JVM de maneira mais simples do que com GraalVM Native
  Exemplo de comando:
  smolvm pack create --image python:3.12-alpine -o ./python312
./python312 run -- python3 --version
  → O Python 3.12.x roda em isolamento total, sem precisar de pyenv/venv/conda

  • Isso é um conceito parecido com o Electron
    Assim como o Electron distribui apps web junto com o navegador, o Smol Machines empacota o software junto com uma VM Linux
    Dá para evitar problemas de gerenciamento de dependências e compatibilidade
    Pessoalmente, eu adoraria ver ferramentas como Codex ou Claude Code sendo distribuídas assim
  • Todo mundo já teve pelo menos uma experiência de “quebrar o ambiente de desenvolvimento”
    Isso é o conceito de uma “máquina distribuível” para resolver esse tipo de problema
    Depois de configurar uma vez direito, dá para compartilhar e executar com qualquer pessoa imediatamente

• Queria saber se o arquivo .smolmachine suporta assinatura digital e autenticação própria
  Gostaria de saber se ele pode funcionar de forma parecida com a documentação de assinatura/verificação da Sylabs

• Queria saber se seria possível deixá-lo ainda mais rápido aplicando as ideias do zeroboot

• A tabela de comparação está realmente muito bem feita
  No começo pensei “parece com o Firecracker”, mas depois de ver a tabela as diferenças ficaram bem claras
  Foi fácil de entender e, no geral, é um trabalho muito impressionante

  • Obrigado

• Vi imagens alpine e python:3.12-alpine na documentação da CLI e queria saber de onde elas vêm
  Queria saber se são puxadas de algum lugar como um registro Docker, se são embutidas ou se são criadas manualmente com smolfile
  Também queria saber se há imagem Ubuntu
  Seria ótimo adicionar hot resize de memória/CPU, e parece que isso também poderia ser usado para orquestrar infraestrutura backend por cliente

• A maioria dos projetos open source sobe contêineres com Docker Compose, mas o Smol Machines não suporta Docker dentro da microVM
  Também é uma pena que não suporte VM aninhada como o Vagrant

  • O suporte a Docker está planejado. Na próxima release, pretendemos distribuir um kernel compatível com os flags de kernel necessários
  • Como o Vagrant sobe VMs localmente, parece que ele exigiria nesting
    Em vez disso, sugiro rodar como uma VM irmã da VM do Vagrant, usando uma abordagem de trampolim

• Queria uma explicação curta do motivo principal para usar Smol Machines em vez de sandbox Docker

• Resultado realmente incrível. Parabéns