Seu VPS consegue executar microVMs Firecracker?

Seu VPS pode executar microVMs Firecracker?

Seu VPS só pode executar microVMs Firecracker se fornecer /dev/kvm. O Firecracker é um VMM (monitor de máquina virtual) criado sobre o KVM (máquina virtual baseada no kernel), a camada de virtualização do Linux. O KVM precisa das instruções de virtualização da CPU. Num VPS, essas instruções só ficam disponíveis quando o provedor as expõe ao seu sistema convidado, e a maioria dos planos não faz isso.

Por isso, a primeira pergunta não é qual ferramenta de microVM instalar. É se a máquina que você já paga consegue hospedar uma microVM. Essa é uma questão do serviço de hospedagem, e você pode respondê-la em cerca de um minuto.

Verifique /dev/kvm antes de instalar qualquer coisa

Execute estes três comandos no próprio VPS.

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

Uma máquina capaz de alojar microVMs responde assim:

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

A primeira linha é o nó de dispositivo KVM, pertencente ao grupo kvm. A segunda linha indica que esta máquina é, por sua vez, um guest a executar sob KVM, o que é normal e esperado num VPS. A terceira linha conta os núcleos de CPU que indicam o sinalizador de virtualização de hardware, vmx na Intel e svm na AMD. Um valor superior a zero dentro de um guest significa que o hypervisor está a expor virtualização aninhada.

Depois, verifique se o seu utilizador consegue abrir o dispositivo. Este é o teste da própria documentação de introdução do Firecracker:

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

FAIL enquanto o nó existe indica um problema de permissões, não de hardware. Conceda acesso ao seu utilizador com sudo setfacl -m u:${USER}:rw /dev/kvm ou adicione-se ao grupo com sudo usermod -aG kvm ${USER} e inicie sessão novamente.

O Ubuntu também inclui uma verificação que resume tudo isto em duas linhas de saída:

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

Um host funcional apresenta INFO: /dev/kvm exists e depois KVM acceleration can be used. Um host que não consegue apresenta INFO: Your CPU does not support KVM extensions e depois KVM acceleration can NOT be used. Numa máquina física, poderá ver INFO: KVM (vmx) is disabled by your BIOS, um problema que pode ser corrigido no firmware. Num VPS, essa mensagem é rara, porque não está a consultar firmware real.

O que significa cada resposta sobre /dev/kvm?

O nó existe e a contagem de flags é superior a zero. Tem virtualização por hardware, portanto o Firecracker vai funcionar. Avance para a seção de dimensionamento, porque a sua limitação restante é a memória, não os recursos da CPU.

Não existe nó, systemd-detect-virt exibe kvm ou qemu e a contagem de flags é 0. O seu VPS é uma máquina virtual cujo host não está disponibilizando a virtualização para a máquina convidada. Nada que você instale dentro da máquina convidada altera isso, porque a flag é uma propriedade da CPU virtual que o hypervisor criou para você. sudo modprobe kvm_intel falha com modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, e sudo dmesg | grep -i kvm registra a ausência do suporte de hardware. Este é o caso comum em planos de VPS compartilhados. Pergunte ao provedor se o plano oferece virtualização aninhada. Se a resposta for não, você precisa de outra hospedagem, não de outro comando.

systemd-detect-virt exibe lxc, lxc-libvirt ou openvz. O seu plano usa virtualização por contêineres, portanto você compartilha o kernel do host. /dev/kvm nunca aparecerá, porque você não tem um kernel próprio para carregar um módulo. Nenhum pacote corrige isso.

As flags estão presentes, mas o nó não existe. O módulo simplesmente não está carregado. Execute sudo modprobe kvm_intel (ou kvm_amd em AMD) e verifique ls -l /dev/kvm novamente. Se o nó aparecer, escreva o nome do módulo em /etc/modules-load.d/kvm.conf para que ele volte a ser carregado depois de um reboot.

Você está em arm64. vmx e svm são nomes usados em x86, portanto a contagem de grep é 0 em qualquer máquina arm64, funcionando ou não. Em arm64, confie no nó de dispositivo e no teste de leitura e escrita.

Por que uma microVM e não um contentor para executar agentes

Um contentor é um processo no seu kernel, isolado por namespaces e cgroups. Existe um único kernel e ele é o seu, por isso uma fuga ao nível do kernel chega ao host. Uma microVM arranca o seu próprio kernel dentro de um limite de virtualização de hardware e comunica com um pequeno modelo de dispositivos emulados, em vez de usar toda a superfície de chamadas de sistema do host. O Firecracker mantém esse modelo deliberadamente pequeno. Esse é todo o objetivo do desenho: menos dispositivos emulados significam menos formas de sair.

Essa diferença é importante para um agente de programação, porque o código executado por um agente é código que ninguém leu previamente. O agente instala pacotes, executa scripts de compilação e repete operações à velocidade da máquina quando algo falha. Um kernel separado significa que um passo incorreto danifica uma máquina que pode apagar, e nada mais.

O requisito resulta diretamente do mecanismo. O isolamento de hardware precisa de virtualização de hardware, e a virtualização de hardware é precisamente aquilo que o seu plano VPS pode não disponibilizar. Um contentor não precisa de nada disso. É por isso que os contentores funcionam em todos os planos alguma vez vendidos.

Por isso, quando /dev/kvm está ausente, a VM descartável baseada em contentores para agentes de programação continua a ser a opção correta. É um controlo real, não um prémio de consolação. Um contentor descartável, num host que não guarda credenciais importantes, restaurado a partir de um snapshot sempre que apresenta problemas, impede a maior parte do que pode realmente correr mal. O mesmo se aplica à configuração mais simples descrita em executar um agente de programação num VPS. Use uma microVM quando um agente for executar tarefas sem supervisão durante horas, sobre código que ainda não reviu, e quando o host estiver sob o seu controlo.

O que um host de agentes microVM exige

Nehemiah é um exemplo atual desta classe: um daemon Apache-2.0 que disponibiliza uma máquina Linux real para uma IA quando necessário, com uma microVM Firecracker por máquina. Em 10 August 2026, o README indicava o requisito de forma explícita: "uma máquina Linux com /dev/kvm" e, mais precisamente, "Ubuntu 24.04, x86_64 ou arm64, com /dev/kvm (bare metal ou uma VM com virtualização aninhada) à qual possa aceder por SSH como root".

Entretanto, isso mudou. Em 11 August 2026, o projeto substituiu a documentação de configuração autónoma por um runbook para hosts geridos, e o README consultado em 11 October 2026 já não contém essa linha de requisito nem a instalação com um único comando. Os hosts são agora provisionados a partir de artefactos de release assinados em servidores bare metal da Latitude.sh com infra/latitude/provision.sh. Trata-se de um processo manual, executado pelo operador para hosts aprovados, que depois são inscritos pelo plano de controlo do projeto. O canary do runbook continua a recusar um host sem um /dev/kvm utilizável, pelo que o requisito não desapareceu. Passou para bare metal.

Até essa alteração, a configuração documentada consistia num único comando dirigido a essa máquina:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

Nos main atuais, esse comando já não instala nada. infra/setup.sh está marcado como fora do âmbito e termina no primeiro passo com uma mensagem a indicar que o bootstrap autónomo já não é suportado, antes de executar qualquer verificação preliminar ou passo de instalação. O README informa que os instaladores autónomos anteriores agora terminam e apresentam uma referência para o runbook de hosts geridos.

No commit usado como base para a primeira versão deste artigo, infra/setup.sh executava uma verificação preliminar por SSH e parava imediatamente quando a máquina não cumpria os requisitos. As duas mensagens de recusa de hardware eram:

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

A primeira mensagem é o ponto central deste artigo. O instalador fazia a mesma pergunta que acabou de fazer com ls -l /dev/kvm e, na maioria dos planos VPS, recebia a mesma resposta dececionante. O runbook de hosts geridos também faz essa verificação.

Depois da verificação preliminar, a instalação abrangia toda a máquina: Firecracker e o seu jailer, uma toolchain Go, um kernel e um sistema de ficheiros raiz para o guest, uma imagem guest Python, uma imagem de desktop opcional com um browser e duas unidades systemd chamadas nehemiahd.service e boring-net.service. Uma verificação de integridade falhada apresentava /healthz didn't return ok, e SKIP_DESKTOP=1 ignorava a imagem de desktop, que o README dessa data indicava demorar cerca de 8 minutos a compilar. Nenhum desses passos, mensagens ou switches é executado pelo main atual. O daemon continua a aceitar ligações na porta 8080 por predefinição.

Leia as ressalvas antes de colar esse comando

Era necessário acesso SSH como root num host novo. O instalador autónomo escrevia pacotes do sistema, unidades systemd e configuração de rede como root. Se ainda assim executar esse commit sem suporte, aponte-o para uma máquina que esteja disposto a reinstalar do zero, não para o servidor que já aloja o seu site.

O daemon associa-se a 0.0.0.0:8080 por predefinição. Qualquer pessoa que alcance essa porta pode criar máquinas, e essas máquinas consomem a chave do modelo que forneceu ao host. Defina NEHEMIAH_TOKEN para exigir autenticação, ou defina NEHEMIAH_ADDR=127.0.0.1:8080 (o daemon também aceita -addr 127.0.0.1:8080) para que se associe apenas a 127.0.0.1 e aceda a ele através de um túnel com ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. A opção BIND_LOCALHOST=1 do instalador antigo não é lida pelo daemon, por isso não tem efeito fora desse script. A chave merece o mesmo cuidado que qualquer outro segredo no servidor, tal como em manter os segredos fora dos agentes de IA.

Cada máquina é um computador com acesso à Internet e agentes pré-instalados. O README lista claude, codex, cursor e pi dentro do guest, juntamente com node, python e git. O projeto indica que os guests ficam atrás de uma firewall de saída e que o próprio limite de isolamento é real. Ainda assim, o guest acede à rede por conceção, porque um agente de programação que não consegue obter um pacote é inútil. Planeie tendo isso em conta, em vez de presumir que existe um isolamento total da rede.

Não existe nenhuma release identificada por tag. Em 11 October 2026, o repositório não tinha tags nem releases, por isso clonar main obtém o que tiver sido incluído nessa manhã, e atualmente isso corresponde ao código apenas para ambientes geridos. Fixe um commit. O commit abaixo é aquele contra o qual este artigo foi escrito em 10 August 2026, no dia anterior à retirada do instalador autónomo, por isso o respetivo infra/setup.sh ainda instala. O projeto já não suporta esse caminho, portanto leia o script antes de ele ser executado como root no seu servidor:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

O repositório foi criado no fim de June 2026 e retirou a instalação autónoma seis semanas depois, por isso trate-o como software recente, cujo caminho suportado pode mudar sem aviso. Antes de obter qualquer versão mais recente, leia novamente o README e o runbook, porque aquilo que está a autorizar é acesso root a uma máquina, não uma atualização de versão de uma biblioteca.

Demonstre que o KVM funciona antes de culpar o instalador

Se a configuração falhar e quiser saber se a causa é o KVM, teste o Firecracker isoladamente. Estes são os passos de download do projeto upstream:

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

A apresentação da versão confirma que o binário corresponde à sua arquitetura e é executado. Não confirma o acesso ao KVM. Por isso, combine-a com o teste de leitura e escrita em /dev/kvm apresentado anteriormente. Em conjunto, os dois testes distinguem um problema de alojamento de um problema de empacotamento. Assim, evita depurar um instalador que estava correto desde o início.

De quanta capacidade de servidor precisam várias microVMs?

Cada microVM inclui um kernel convidado real, além da memória que lhe atribuir, e essa memória fica comprometida enquanto a máquina estiver em execução. Por isso, dimensione o host com base no tamanho dos convidados e no número que pretende executar em simultâneo. Os valores abaixo são cálculos aritméticos, não medições. Um convidado sem interface gráfica recebe 1 GB, e um convidado com ambiente gráfico e um browser recebe 2 GB. O host reserva 3 GB fixos para si próprio, para o daemon e para compilações de imagens. Essa é a reserva predefinida do daemon (NEHEMIAH_MEM_RESERVE_MB, 3072 MB). O daemon recusa arrancar uma máquina nova que consumisse essa reserva. Assim, um host subdimensionado atinge a capacidade máxima em vez de ficar sem memória.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 4
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 7
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 11
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 19
  }
]

Uma máquina sem interface gráfica de cada vez precisa de cerca de 4 GB. Um VPS de capacidade média consegue suportá-la quando disponibiliza KVM. Quatro máquinas precisam de 7 GB. Execute 8 máquinas com ambiente gráfico e o mesmo cálculo exige 19 GB antes de contar um único gigabyte de disco.

O disco é o recurso que ninguém planeia. O host armazena um kernel convidado, um sistema de ficheiros raiz base, uma imagem por variante de convidado e um snapshot por máquina em execução. A imagem de ambiente gráfico com um browser é a maior. O README não indica nenhum valor de disco. Por isso, monitorize df -h / durante a primeira compilação, em vez de confiar numa estimativa.

É por isso que a resposta honesta à pergunta "que VPS executa o Firecracker" é muitas vezes "uma classe diferente de máquina". O bare metal disponibiliza os flags de CPU sem um hypervisor pelo meio. Essa é a contrapartida em escolher entre um VPS e um servidor dedicado. Alguns fornecedores disponibilizam virtualização aninhada em planos virtuais. virtualização aninhada num VPS explica como confirmá-la antes de pagar. Se o hardware já for seu, Proxmox em vez de um VPS simples é a mesma questão vista do lado do hypervisor.

O servidor também é a parte barata do custo total. Cada máquina que entrega a um agente consome tokens do modelo enquanto estiver em execução. Assim, uma microVM inativa custa memória, enquanto uma microVM ocupada custa memória e utilização da API. Um plano de 1 GB não consegue suportar o host. Um plano que consiga suportar o host ainda não pagará a chave.

FAQ

Como verifico se o meu VPS pode executar o Firecracker?

Execute ls -l /dev/kvm, systemd-detect-virt e grep -cE '\b(vmx|svm)\b' /proc/cpuinfo no VPS. Um nó de dispositivo pertencente ao grupo kvm, juntamente com uma contagem de flags superior a zero, indica que o Firecracker pode ser executado. A ausência do nó, com uma contagem de 0, indica que o hipervisor não está a disponibilizar a virtualização, e sudo kvm-ok do pacote cpu-checker confirma-o com KVM acceleration can NOT be used. Em arm64, ignore a contagem, porque vmx e svm são nomes usados em x86.

Posso ativar a virtualização aninhada a partir do meu VPS?

Não. A virtualização aninhada é ativada pelo host, no módulo do kernel do próprio hipervisor, e chega até si como uma flag de CPU no processador virtual que lhe foi atribuído. Dentro do guest, sudo modprobe kvm_intel devolve modprobe: ERROR: could not insert 'kvm_intel': Operation not supported porque a CPU virtual não tem VMX disponível. As opções são escolher um fornecedor que disponibilize virtualização aninhada no plano ou utilizar uma máquina cujo hipervisor esteja sob o seu controlo.

Um contentor é suficiente para colocar um agente de programação numa sandbox?

Muitas vezes, sim. Um contentor partilha o seu kernel, por isso uma fuga ao nível do kernel alcança o host. No entanto, um contentor descartável numa máquina que não armazena credenciais valiosas elimina a maior parte do risco efetivo. Escolha uma microVM quando um agente executar tarefas sem supervisão durante períodos longos sobre código não revisto e quando lhe puder atribuir um host com /dev/kvm. Quando isso não for possível, um contentor que destrói após cada tarefa é melhor do que uma microVM que nunca consegue arrancar.

De quanta RAM precisa um host de agentes em microVM?

Comece pelo tamanho do guest. Um guest sem interface gráfica com 1 GB, num host com uma reserva de 3 GB, precisa de cerca de 4 GB no total, e 8 guests com ambiente gráfico, com 2 GB cada, precisam de cerca de 19 GB. O disco é separado e é fácil subestimá-lo, porque o host mantém um kernel, sistemas de ficheiros raiz, uma imagem por variante de guest e um snapshot para cada máquina em execução.