Blog · Guide · 28 octobre 2026
AEGIS auto-hébergé avec Firecracker : la configuration documentée et ce qui tourne aujourd'hui
Transparence : 100monkeys.ai développe AEGIS, lisez donc ce guide comme le récit de son fabricant. Il a été rédigé par l'un de nos agents d'IA à partir de la documentation publique d'AEGIS, principalement Firecracker Deployment, What are Agents?, Infrastructure Requirements et Podman Deployment, puis relu par l'entreprise ; cette édition française est une traduction du guide original en anglais. Chaque commande et chaque bloc de configuration sont copiés de ces pages. Nous n'en avons exécuté aucun pour ce guide.
AEGIS by 100monkeys.ai, in beta, est un orchestrateur auto-hébergé pour agents autonomes. Sa documentation décrit les microVM Firecracker comme l'isolation de la production durcie. Lisez la première ligne de cette page avant d'acheter du matériel : "Firecracker support is planned for a future release and is not yet available. The Docker and Podman runtimes are the current deployment targets." (La prise en charge de Firecracker est prévue dans une version future et n'est pas encore disponible. Les environnements Docker et Podman sont les cibles de déploiement actuelles.) Ce guide couvre ce que vous pouvez faire aujourd'hui : vérifier un hôte, lire la configuration documentée pour l'environnement prévu et suivre le chemin Podman, déjà livré.
Pourquoi Firecracker, selon la documentation
"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." (Les conteneurs Docker partagent le noyau de l'hôte : une faille d'évasion de conteneur pourrait donner à un agent malveillant, manipulé par injection de prompt, l'exécution de code sur l'hôte. Firecracker apporte une isolation matérielle via KVM.) Le comparatif de la page donne à chaque agent "a dedicated guest kernel per agent" (un noyau invité dédié par agent), un rayon d'impact en cas d'évasion "bounded to single microVM" (limité à une seule microVM) et un stockage via virtio-fs, "shared memory, no network" (mémoire partagée, sans réseau), là où les conteneurs utilisent NFS. Le coût indiqué est un démarrage d'environ 125 ms contre environ 100 ms pour un conteneur.
La conception laisse les agents inchangés d'un environnement à l'autre : "Switching a node from Docker to Podman or Firecracker requires only a config change: no agent manifest changes needed." (Passer un nœud de Docker à Podman ou Firecracker ne demande qu'un changement de configuration : aucun manifeste d'agent à modifier.) C'est pourquoi se préparer maintenant n'est pas du travail perdu.
Étape 1. Vérifier KVM sur l'hôte
Firecracker a besoin de KVM, c'est-à-dire, selon la documentation, de "bare-metal Linux servers with Intel VT-x or AMD-V CPU virtualization extensions" (serveurs Linux bare metal dotés des extensions de virtualisation Intel VT-x ou AMD-V), ou d'instances cloud bare metal ou avec virtualisation imbriquée. Non pris en charge : "NOT supported on standard EC2 instances without bare-metal, most VMs (including standard VMs on most cloud providers), and macOS (Docker Desktop)." (NON pris en charge sur les instances EC2 standard sans bare metal, la plupart des VM, y compris les VM standard de la plupart des fournisseurs cloud, et macOS avec Docker Desktop.) Les vérifications de la documentation, copiées :
# 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)Si /dev/kvm est absent sur une VM cloud, cet hôte ne fera pas tourner l'environnement Firecracker quand il sortira, quoi qu'il ait par ailleurs.
Étape 2. Vérifier le noyau
Lancez uname -r et comparez avec la documentation. Deux pages donnent deux minimums : What are Agents? indique "Bare-metal or KVM-passthrough host, Linux kernel 5.10+" (hôte bare metal ou avec passthrough KVM, noyau Linux 5.10 ou plus), et Infrastructure Requirements indique "Linux kernel 5.15+" avec "KVM support for Firecracker (planned later phase)" (prise en charge KVM pour Firecracker, prévue dans une phase ultérieure). Visez 5.15 ou plus et vous satisfaites les deux.
Étape 3. Lire la configuration documentée
L'environnement prévu se configure dans aegis-config.yaml sous runtime.firecracker. Le bloc de la page, copié :
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: v2Lisez-le pour ce qu'il demande à l'hôte : un jailer et un binaire Firecracker, un uid et un gid non privilégiés, une image de noyau invité, un système de fichiers racine pour l'agent, et du CPU et de la mémoire par VM. Le jailer "drops privileges before starting the VMM" (abandonne ses privilèges avant de lancer le VMM) : une prison chroot, une interface tap et un cgroup créés à l'avance, et des filtres seccomp. Chaque microVM a son propre périphérique tap, et "outbound traffic from the microVM is routed through the orchestrator proxy (SEAL), not directly to the internet." (le trafic sortant de la microVM passe par le proxy de l'orchestrateur, SEAL, et non directement vers internet.)
Ne déployez pas ce bloc aujourd'hui. La documentation ne dit pas d'où viennent l'image du noyau et le système de fichiers racine, et l'environnement qui les lit est décrit comme "in development" (en développement).
Étape 4. Faire tourner AEGIS aujourd'hui sur Podman
Pour la production actuelle, la documentation renvoie au dépôt aegis-deploy : "aegis-deploy is the recommended production deployment path. It includes OpenBao (secrets management), TLS via Caddy, and full observability." (aegis-deploy est la voie de déploiement recommandée en production. Il inclut OpenBao pour la gestion des secrets, TLS via Caddy et une observabilité complète.) Son démarrage rapide, copié :
# 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 exécute les agents sans root, ce à quoi la documentation attribue la suppression de "the privileged daemon" (le démon privilégié) et le mappage du root du conteneur "to an unprivileged host UID" (vers un UID non privilégié de l'hôte). Pour une évaluation sur une seule machine, l'installeur d'une ligne affiché sur 100monkeys.ai est curl -fsSL https://get.100monkeys.ai | bash, qui lance la pile Docker locale ; la documentation la réserve "for local testing and evaluation only" (aux tests et à l'évaluation en local uniquement).
Étape 5. Garder le passage à un changement de configuration
Écrivez vos manifestes d'agent sans fixer l'isolation, pour que le nœud décide. Le champ isolation du manifeste accepte inherit, firecracker, docker et process, et sa valeur par défaut est inherit, "from node config" (depuis la configuration du nœud). L'exemple de la référence de configuration fixe le default_isolation du nœud à docker, une valeur qui "works with both Docker and Podman runtimes" (fonctionne avec Docker comme avec Podman). Quand Firecracker sortira, le changement portera sur le nœud, pas sur chaque agent.
Étape 6. Suivre les travaux
La page se termine ainsi : "Monitor progress on Firecracker support in the aegis-orchestrator GitHub repository." (Suivez l'avancement de la prise en charge de Firecracker dans le dépôt GitHub aegis-orchestrator.) C'est là que sera nommée la version qui livrera cet environnement.
Ce que la documentation laisse ouvert
- Une date ou une version pour la prise en charge de Firecracker.
- D'où viennent le noyau invité (
vmlinux) et le système de fichiers racine de l'agent, et comment les construire. - Le noyau minimum : 5.10 sur une page, 5.15 sur une autre.
- D'autres pages décrivent encore Firecracker comme l'environnement de production durci sans l'avertissement "not yet available" (pas encore disponible) ; prenez donc la page Firecracker elle-même comme la parole actuelle.
Suite
Pour installer la pile d'évaluation et lancer un premier agent derrière une approbation, lisez Installer AEGIS sur un VPS Ubuntu neuf et lancer votre première tâche approuvée.