100monkeys.ai

Blog · Guia · 28 de outubro de 2026

AEGIS auto-hospedado com Firecracker: a configuração que a documentação descreve e o que roda hoje

Também em: English, Español, 日本語 · Todos os guias em português

Aviso: a 100monkeys.ai desenvolve o AEGIS, então leia este guia como o relato de quem o fabrica. Ele foi redigido por um dos nossos agentes de IA a partir da documentação pública do AEGIS, principalmente Firecracker Deployment, What are Agents?, Infrastructure Requirements e Podman Deployment, e revisado pela empresa; esta versão em português é uma tradução do guia original em inglês. Cada comando e bloco de configuração foi copiado dessas páginas, e as citações ficam em inglês com a tradução ao lado. Não rodamos nenhum deles para este guia.

AEGIS by 100monkeys.ai, in beta, é um orquestrador auto-hospedado para agentes autônomos. A documentação descreve as microVMs do Firecracker como o isolamento para produção reforçada. Leia a primeira linha dessa página antes de comprar hardware: "Firecracker support is planned for a future release and is not yet available. The Docker and Podman runtimes are the current deployment targets." (O suporte a Firecracker está planejado para uma versão futura e ainda não está disponível. Os runtimes Docker e Podman são os alvos de implantação atuais.) Este guia cobre o que você pode fazer hoje: verificar um host, ler a configuração que a documentação registra para o runtime planejado e usar o caminho Podman que já é distribuído.

Por que Firecracker, nas palavras da documentação

"Docker containers share the host kernel: a container escape vulnerability could give a malicious prompt-injected agent code execution on the host. Firecracker provides hardware-level isolation via KVM." (Contêineres Docker compartilham o kernel do host: uma vulnerabilidade de fuga de contêiner poderia dar a um agente malicioso, vítima de prompt injection, execução de código no host. O Firecracker oferece isolamento em nível de hardware via KVM.) A comparação da página dá a cada agente "a dedicated guest kernel per agent" (um kernel convidado dedicado por agente), um raio de impacto em caso de fuga "bounded to single microVM" (limitado a uma única microVM) e armazenamento via virtio-fs, "shared memory, no network" (memória compartilhada, sem rede), onde os contêineres usam NFS. O custo declarado é um boot de cerca de 125 ms contra cerca de 100 ms de um contêiner.

O desenho mantém os agentes iguais entre runtimes: "Switching a node from Docker to Podman or Firecracker requires only a config change: no agent manifest changes needed." (Trocar um nó de Docker para Podman ou Firecracker exige só uma mudança de configuração: nenhum manifesto de agente precisa mudar.) Por isso preparar-se agora não é trabalho perdido.

Passo 1. Verifique KVM no host

O Firecracker precisa de KVM, o que segundo a documentação significa "bare-metal Linux servers with Intel VT-x or AMD-V CPU virtualization extensions" (servidores Linux bare metal com extensões de virtualização de CPU Intel VT-x ou AMD-V), ou instâncias de nuvem bare metal ou com virtualização aninhada. "NOT supported on standard EC2 instances without bare-metal, most VMs (including standard VMs on most cloud providers), and macOS (Docker Desktop)." (NÃO é suportado em instâncias EC2 padrão sem bare metal, na maioria das VMs, incluindo VMs padrão da maioria dos provedores de nuvem, nem no macOS com Docker Desktop.) As verificações da documentação, copiadas:

# Check for KVM device nodes
ls -la /dev/kvm

# Verify CPU virtualization extensions
grep -cw vmx /proc/cpuinfo   # Intel (should return > 0)
grep -cw svm /proc/cpuinfo   # AMD  (should return > 0)

Se /dev/kvm não existir numa VM de nuvem, esse host não vai rodar o runtime do Firecracker quando ele for lançado, tenha o que tiver.

Passo 2. Verifique o kernel

Rode uname -r e compare com a documentação. Duas páginas dão dois mínimos: What are Agents? lista "Bare-metal or KVM-passthrough host, Linux kernel 5.10+" (host bare metal ou com KVM passthrough, kernel Linux 5.10 ou superior), e Infrastructure Requirements lista "Linux kernel 5.15+" (kernel Linux 5.15 ou superior) com "KVM support for Firecracker (planned later phase)" (suporte a KVM para Firecracker, previsto para uma fase posterior). Planeje 5.15 ou superior e você atende às duas.

Passo 3. Leia a configuração que a documentação registra

O runtime planejado é configurado em aegis-config.yaml sob runtime.firecracker. O bloco da página, copiado:

runtime:
  type: firecracker
  firecracker:
    # Path to the jailer binary
    jailer_binary: /usr/local/bin/jailer
    # Path to the Firecracker VMM binary
    firecracker_binary: /usr/local/bin/firecracker
    # User/group for the jailed process
    uid: 65534   # nobody
    gid: 65534
    # Kernel image for microVMs
    kernel_image_path: /opt/aegis/vmlinux
    # Root filesystem for agent microVMs (minimal Linux + Python)
    rootfs_path: /opt/aegis/agent-rootfs.ext4
    # CPU and memory limits
    vcpu_count: 2
    mem_size_mib: 512
    # cgroup version (v1 or v2)
    cgroup_version: v2

Leia pelo que ele pede do host: um jailer e um binário do Firecracker, um uid e um gid sem privilégios, uma imagem de kernel convidado, um sistema de arquivos raiz para o agente, e CPU e memória por VM. O jailer "drops privileges before starting the VMM" (abre mão dos privilégios antes de iniciar o VMM): uma jaula chroot, uma interface tap e um cgroup criados antes, e filtros seccomp. Cada microVM ganha o seu próprio dispositivo tap, e "outbound traffic from the microVM is routed through the orchestrator proxy (SEAL), not directly to the internet" (o tráfego de saída da microVM passa pelo proxy do orquestrador, o SEAL, e não vai direto para a internet).

Não implante este bloco hoje. A documentação não diz de onde vêm a imagem do kernel e o sistema de arquivos raiz, e o runtime que os lê é descrito como "in development" (em desenvolvimento).

Passo 4. Rode o AEGIS hoje no Podman

Para produção agora, a documentação aponta para o repositório aegis-deploy: "aegis-deploy is the recommended production deployment path. It includes OpenBao (secrets management), TLS via Caddy, and full observability." (aegis-deploy é o caminho recomendado para implantar em produção. Inclui OpenBao para gestão de segredos, TLS via Caddy e observabilidade completa.) O início rápido dele, copiado:

# Clone the deployment repo
git clone https://github.com/100monkeys-ai/aegis-deploy.git
cd aegis-deploy

# Copy and edit environment configuration
cp .env.example .env
# Edit .env with your values (GHCR credentials, passwords, LLM API keys)

# Install system dependencies (Ubuntu)
make setup

# Authenticate with GitHub Container Registry
make registry-login

# Generate SEAL signing keys
make generate-keys

# Deploy the full stack
make deploy PROFILE=full

# Validate all services are healthy
make validate

# Bootstrap secrets
make bootstrap-secrets

O Podman roda os agentes sem root, o que a documentação credita por eliminar "the privileged daemon" (o daemon privilegiado) e mapear o root do contêiner "to an unprivileged host UID" (para um UID sem privilégios no host). Para avaliar numa só máquina, o instalador de uma linha mostrado em 100monkeys.ai é curl -fsSL https://get.100monkeys.ai | bash, que sobe o stack local de Docker; a documentação marca esse stack como "for local testing and evaluation only" (só para testes e avaliação locais).

Passo 5. Deixe a troca numa mudança de configuração

Escreva os manifestos dos seus agentes sem fixar o isolamento, para que o nó decida. O campo isolation do manifesto aceita inherit, firecracker, docker e process, e o padrão é inherit, "from node config" (da configuração do nó). O exemplo da referência de configuração define o default_isolation do nó como docker, um valor que "works with both Docker and Podman runtimes" (funciona com os runtimes Docker e Podman). Quando o Firecracker for lançado, a mudança será do nó, não de cada agente.

Passo 6. Acompanhe o trabalho

A página termina assim: "Monitor progress on Firecracker support in the aegis-orchestrator GitHub repository." (Acompanhe o progresso do suporte a Firecracker no repositório aegis-orchestrator do GitHub.) É ali que a versão que trouxer o runtime será anunciada.

O que a documentação deixa em aberto

Próximos passos

Para instalar o stack de avaliação e rodar um primeiro agente atrás de uma aprovação, leia Instale o AEGIS numa VPS Ubuntu nova e rode sua primeira tarefa aprovada.

Instale o AEGIS pelo 100monkeys.ai