Blog · Guida · 28 ottobre 2026
AEGIS self-hosted con Firecracker: la configurazione documentata e cosa funziona oggi
Trasparenza: AEGIS è sviluppato da 100monkeys.ai, quindi leggete questa guida come il resoconto di chi lo costruisce. L'ha scritta in bozza uno dei nostri agenti di IA a partire dalla documentazione pubblica di AEGIS, soprattutto Firecracker Deployment, What are Agents?, Infrastructure Requirements e Podman Deployment, e l'azienda l'ha rivista; questa edizione italiana è una traduzione della guida originale in inglese. Ogni comando e blocco di configurazione è copiato da quelle pagine. Per questa guida non ne abbiamo eseguito nessuno.
AEGIS by 100monkeys.ai, in beta, è un orchestratore self-hosted per agenti autonomi. La documentazione descrive le microVM Firecracker come isolamento per la produzione blindata. Leggete la prima riga di quella pagina prima di comprare hardware: "Firecracker support is planned for a future release and is not yet available. The Docker and Podman runtimes are the current deployment targets." (Il supporto a Firecracker è previsto in una versione futura e non è ancora disponibile. I runtime Docker e Podman sono gli obiettivi di deployment attuali.) Questa guida copre ciò che potete fare oggi: verificare un host, leggere la configurazione che la documentazione descrive per il runtime previsto ed eseguire il percorso Podman, già disponibile.
Perché Firecracker, con le parole della documentazione
"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." (I container Docker condividono il kernel dell'host: una vulnerabilità di evasione dal container potrebbe dare a un agente malevolo, manipolato tramite prompt injection, l'esecuzione di codice sull'host. Firecracker offre isolamento a livello hardware tramite KVM.) Il confronto della pagina dà a ogni agente "a dedicated guest kernel per agent" (un kernel guest dedicato per agente), un raggio d'impatto in caso di evasione "bounded to single microVM" (limitato a una sola microVM) e uno storage su virtio-fs, "shared memory, no network" (memoria condivisa, nessuna rete), dove i container usano NFS. Il prezzo dichiarato è un avvio di circa 125 ms contro circa 100 ms per un container.
Il progetto mantiene gli agenti invariati tra i runtime: "Switching a node from Docker to Podman or Firecracker requires only a config change: no agent manifest changes needed." (Passare un nodo da Docker a Podman o Firecracker richiede solo una modifica di configurazione: nessuna modifica ai manifesti degli agenti.) Per questo prepararsi ora non è lavoro sprecato.
Passo 1. Verificate KVM sull'host
Firecracker richiede KVM, che secondo la documentazione significa "bare-metal Linux servers with Intel VT-x or AMD-V CPU virtualization extensions" (server Linux bare metal con estensioni di virtualizzazione Intel VT-x o AMD-V), oppure istanze cloud bare metal o con virtualizzazione annidata. Non è supportato: "NOT supported on standard EC2 instances without bare-metal, most VMs (including standard VMs on most cloud providers), and macOS (Docker Desktop)." (NON supportato su istanze EC2 standard senza bare metal, sulla maggior parte delle VM, comprese le VM standard della maggior parte dei provider cloud, e su macOS con Docker Desktop.) I controlli della documentazione, copiati:
# 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 manca su una VM cloud, quell'host non eseguirà il runtime Firecracker quando uscirà, qualunque altra cosa abbia.
Passo 2. Verificate il kernel
Eseguite uname -r e confrontate con la documentazione. Due pagine danno due minimi: What are Agents? indica "Bare-metal or KVM-passthrough host, Linux kernel 5.10+" (host bare metal o con passthrough KVM, kernel Linux 5.10 o successivo), e Infrastructure Requirements indica "Linux kernel 5.15+" con "KVM support for Firecracker (planned later phase)" (supporto KVM per Firecracker, previsto in una fase successiva). Puntate a 5.15 o successivo e soddisfate entrambe.
Passo 3. Leggete la configurazione documentata
Il runtime previsto si configura in aegis-config.yaml sotto runtime.firecracker. Il blocco della pagina, copiato:
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: v2Leggetelo per ciò che chiede all'host: un jailer e un binario Firecracker, un uid e un gid non privilegiati, un'immagine del kernel guest, un filesystem root per l'agente, CPU e memoria per ogni VM. Il jailer "drops privileges before starting the VMM" (rinuncia ai privilegi prima di avviare il VMM): una prigione chroot, un'interfaccia tap e un cgroup creati in anticipo, e filtri seccomp. Ogni microVM ha il proprio dispositivo tap, e "outbound traffic from the microVM is routed through the orchestrator proxy (SEAL), not directly to the internet." (il traffico in uscita dalla microVM passa per il proxy dell'orchestratore, SEAL, non direttamente verso internet.)
Non distribuite questo blocco oggi. La documentazione non dice da dove vengano l'immagine del kernel e il filesystem root, e il runtime che li legge è descritto come "in development" (in sviluppo).
Passo 4. Eseguite AEGIS oggi su Podman
Per la produzione di oggi la documentazione rimanda al repository aegis-deploy: "aegis-deploy is the recommended production deployment path. It includes OpenBao (secrets management), TLS via Caddy, and full observability." (aegis-deploy è il percorso di deployment consigliato per la produzione. Include OpenBao per la gestione dei segreti, TLS tramite Caddy e osservabilità completa.) Il suo avvio rapido, copiato:
# 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-secretsPodman esegue gli agenti senza root, cosa a cui la documentazione attribuisce l'eliminazione di "the privileged daemon" (il demone privilegiato) e la mappatura del root del container "to an unprivileged host UID" (su un UID non privilegiato dell'host). Per una valutazione su una sola macchina, l'installer di una riga stampato su 100monkeys.ai è curl -fsSL https://get.100monkeys.ai | bash, che avvia lo stack Docker locale; la documentazione indica quello stack come "for local testing and evaluation only" (solo per test e valutazione in locale).
Passo 5. Lasciate il passaggio a una modifica di configurazione
Scrivete i manifesti degli agenti senza fissare l'isolamento, così decide il nodo. Il campo isolation del manifesto accetta inherit, firecracker, docker e process, e il suo default è inherit, "from node config" (dalla configurazione del nodo). L'esempio del riferimento di configurazione imposta il default_isolation del nodo a docker, un valore che "works with both Docker and Podman runtimes" (funziona con i runtime Docker e Podman). Quando Firecracker uscirà, la modifica sarà del nodo, non di ogni agente.
Passo 6. Seguite i lavori
La pagina si chiude così: "Monitor progress on Firecracker support in the aegis-orchestrator GitHub repository." (Seguite l'avanzamento del supporto a Firecracker nel repository GitHub aegis-orchestrator.) È lì che verrà indicata la release che porterà il runtime.
Cosa la documentazione lascia aperto
- Una data o una versione per il supporto a Firecracker.
- Da dove vengono il kernel guest (
vmlinux) e il filesystem root dell'agente, e come costruirli. - Il kernel minimo: 5.10 su una pagina, 5.15 su un'altra.
- Altre pagine descrivono ancora Firecracker come runtime di produzione blindato senza l'avviso "not yet available" (non ancora disponibile), quindi prendete la pagina Firecracker come la parola attuale.
Prossimo passo
Per installare lo stack di valutazione ed eseguire un primo agente dietro un'approvazione, leggete Installare AEGIS su un VPS Ubuntu nuovo ed eseguire il primo task approvato.