MicroVMs Firecracker em linguagem simples: uma VM de verdade que inicia em frações de segundo

Se você já leu algo sobre rodar com segurança código gerado por IA, viu a palavra microVM, geralmente ao lado de Firecracker. Costuma ser explicada como “uma VM leve” (verdade, pouco útil) ou com um diagrama das entranhas do kernel. Esta é a versão do meio.

Duas opções mais antigas, e por que nenhuma serve

Comece pelas duas coisas entre as quais a microVM fica.

Um contêiner é um grupo de processos comuns na sua máquina para os quais o kernel concordou em mentir. Os namespaces mostram a eles o próprio sistema de arquivos, a lista de processos e a rede; os cgroups limitam quanto de CPU e memória podem usar. Ele inicia em milissegundos porque nada novo é inicializado. Mas todos os contêineres de um host conversam com o mesmo kernel. Um bug de kernel alcançável de dentro de um contêiner é uma saída de todos eles.

Uma máquina virtual traz o próprio kernel. A CPU do host, via virtualização por hardware (KVM no Linux), executa o convidado como se ele tivesse o próprio computador. A fronteira é o hipervisor, que expõe muito menos que as centenas de chamadas de sistema de um kernel. O preço é o peso. Uma VM clássica emula um PC inteiro: firmware, um barramento PCI, controladores USB, placa de vídeo, às vezes placa de som. Ela inicia passando por tudo isso, leva de segundos a minutos, e cada instância carrega dezenas ou centenas de megabytes de sobrecarga.

Uma analogia que se sustenta razoavelmente: contêineres são apartamentos num mesmo prédio, dividindo fundação, encanamento e fiação. VMs são casas separadas. Casas são vizinhas mais seguras, mas ninguém constrói uma para uma visita de 20 segundos.

O que o Firecracker remove

O Firecracker é um monitor de máquinas virtuais (o programa que configura e roda uma VM sobre o KVM) escrito em Rust e lançado como código aberto em 2018. Ele foi feito para uma tarefa: rodar uma quantidade enorme de cargas de curta duração, que não confiam umas nas outras, em hardware compartilhado. Chega lá principalmente removendo coisas:

• Sem firmware, sem detecção de hardware. O kernel é carregado direto na memória e iniciado. Ninguém procura dispositivos que não existem.
• Um modelo de dispositivos minúsculo. Uma placa de rede, um dispositivo de bloco, um console serial e mais alguns, todos virtio (dispositivos projetados para máquinas virtuais, em vez de imitações dos físicos). Sem USB, sem gráficos, sem PCI.
• Uma base de código pequena e segura em memória. Menos código emulando dispositivos significa menos lugares para um bug que deixe o convidado alcançar o host.
• Uma jaula ao redor do próprio VMM. Cada processo do Firecracker roda dentro de um chroot, com filtros seccomp nas próprias chamadas de sistema e cgroups nos recursos. Se algo escapasse do convidado, cairia numa jaula, não no host.

Os números publicados pelo próprio projeto são espaço de usuário em apenas 125 ms e menos de 5 MiB de sobrecarga de memória por microVM. São os melhores valores de laboratório; uma sandbox real também precisa preparar disco e rede e esperar um agente interno pronto para aceitar comandos, por isso a nossa fica pronta em cerca de um segundo. Ainda é perto o bastante da velocidade de um contêiner para criar uma por tarefa e descartá-la depois.

Contêiner vs microVM, na prática

A linha que importa é a segunda. Com um contêiner, a pergunta “esse código pode escapar?” vira “existe algum bug alcançável no kernel do host?”. Com uma microVM, vira “existe um bug no hipervisor ou num punhado de dispositivos virtuais?”. A segunda superfície é muito menor, e é a que as plataformas de nuvem já defendem na própria hospedagem multilocatário.

Do que você abre mão

Uma microVM não é um upgrade gratuito.

• Sem GPU e sem tela. Ela serve para rodar código, não para desktops nem gráficos.
• Menos dispositivos, menos flexibilidade. Tudo que espera hardware real ou uma longa lista de módulos de kernel não vai se sentir em casa.
• Fronteiras ainda precisam de política. Uma microVM com tráfego de saída aberto ainda pode enviar tráfego que você não quer; uma com suas chaves de API dentro ainda pode vazá-las. O isolamento protege o host do convidado, não os seus segredos do código a quem você os entregou.

Como nossas sandboxes a usam

Cada sandbox da EQVPS é uma microVM Firecracker com kernel próprio, de 0.25 vCPU e 512 MB até 8 vCPU e 16 GB. Vem com Python 3.12, Node.js 22, bash, git e curl, tem internet de saída e nenhuma porta de entrada. Sandboxes efêmeras são excluídas quando você termina; as persistentes mantêm o disco, e pausar uma grava um snapshot da microVM em disco, de modo que ela não custa nada até ser retomada. Snapshots pausados ficam guardados por 14 dias. Depois disso a sandbox é apagada e o id dela responde 410 sandbox_deleted.

Escolhemos microVMs em vez de contêineres por um motivo: o código que roda numa sandbox é, por definição, código que ninguém revisou. A saída de um agente de IA, o pull request de um desconhecido, um benchmark de mil programas escritos por um modelo. Para isso, um kernel próprio é a fronteira que vale o preço. Os detalhes do que construímos em volta — planos, cotas, o limite de 55 segundos para comandos síncronos — estão na documentação das sandboxes.

Se você quiser comparar essa fronteira com as outras opções em mais detalhe, níveis de isolamento para código não confiável coloca processos, contêineres, microVMs e VMs completas lado a lado. E se foi o preço por segundo que chamou sua atenção, como a cobrança por segundo funciona de verdade mostra as contas.