Blog · Guía · 28 de octubre de 2026

AEGIS autoalojado con Firecracker: la configuración que describe la documentación y lo que funciona hoy

También en: English, Português, 日本語 · Todas las guías en español

Aviso: en 100monkeys.ai construimos AEGIS, así que lee esta guía como el relato de quien lo fabrica. La redactó uno de nuestros agentes de IA a partir de la documentación pública de AEGIS, sobre todo Firecracker Deployment, What are Agents?, Infrastructure Requirements y Podman Deployment, y la revisó la empresa; esta versión en español es una traducción de la guía original en inglés. Cada comando y bloque de configuración está copiado de esas páginas, y las citas van en inglés con la traducción al lado. No ejecutamos ninguno para esta guía.

AEGIS by 100monkeys.ai, in beta, es un orquestador autoalojado para agentes autónomos. Su documentación describe las microVM de Firecracker como el aislamiento para producción endurecida. Lee la primera línea de esa 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." (El soporte de Firecracker está planificado para una versión futura y todavía no está disponible. Los runtimes Docker y Podman son los destinos de despliegue actuales.) Esta guía cubre lo que puedes hacer hoy: comprobar un host, leer la configuración que la documentación recoge para el runtime planificado y usar la vía Podman que ya se publica.

Por qué Firecracker, en palabras de la documentación

"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." (Los contenedores Docker comparten el kernel del host: una vulnerabilidad de escape de contenedor podría dar a un agente malicioso, víctima de inyección de prompts, ejecución de código en el host. Firecracker ofrece aislamiento a nivel de hardware mediante KVM.) La comparación de la página da a cada agente "a dedicated guest kernel per agent" (un kernel invitado dedicado por agente), un radio de impacto en caso de escape "bounded to single microVM" (limitado a una sola microVM) y almacenamiento por virtio-fs, "shared memory, no network" (memoria compartida, sin red), donde los contenedores usan NFS. El coste que declara es un arranque de unos 125 ms frente a unos 100 ms para un contenedor.

El diseño deja los agentes iguales entre runtimes: "Switching a node from Docker to Podman or Firecracker requires only a config change: no agent manifest changes needed." (Pasar un nodo de Docker a Podman o Firecracker solo requiere un cambio de configuración: no hace falta cambiar ningún manifiesto de agente.) Por eso prepararse ahora no es trabajo perdido.

Paso 1. Comprueba KVM en el host

Firecracker necesita KVM, lo que según la documentación significa "bare-metal Linux servers with Intel VT-x or AMD-V CPU virtualization extensions" (servidores Linux bare metal con extensiones de virtualización de CPU Intel VT-x o AMD-V), o instancias en la nube que sean bare metal o tengan virtualización anidada. "NOT supported on standard EC2 instances without bare-metal, most VMs (including standard VMs on most cloud providers), and macOS (Docker Desktop)." (NO se admite en instancias EC2 estándar sin bare metal, en la mayoría de las VM, incluidas las VM estándar de la mayoría de los proveedores de nube, ni en macOS con Docker Desktop.) Las comprobaciones de la documentación, 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)

Si falta /dev/kvm en una VM en la nube, ese host no ejecutará el runtime de Firecracker cuando se publique, tenga lo que tenga.

Paso 2. Comprueba el kernel

Ejecuta uname -r y compáralo con la documentación. Dos páginas dan dos mínimos: What are Agents? indica "Bare-metal or KVM-passthrough host, Linux kernel 5.10+" (host bare metal o con KVM passthrough, kernel Linux 5.10 o superior), e Infrastructure Requirements indica "Linux kernel 5.15+" (kernel Linux 5.15 o superior) con "KVM support for Firecracker (planned later phase)" (soporte de KVM para Firecracker, previsto en una fase posterior). Planifica 5.15 o superior y cumplirás ambos.

Paso 3. Lee la configuración que recoge la documentación

El runtime planificado se configura en aegis-config.yaml bajo runtime.firecracker. El bloque de la 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

Léelo por lo que pide al host: un jailer y un binario de Firecracker, un uid y un gid sin privilegios, una imagen de kernel invitado, un sistema de archivos raíz para el agente, y CPU y memoria por VM. El jailer "drops privileges before starting the VMM" (renuncia a los privilegios antes de arrancar el VMM): una jaula chroot, una interfaz tap y un cgroup creados de antemano, y filtros seccomp. Cada microVM tiene su propio dispositivo tap, y "outbound traffic from the microVM is routed through the orchestrator proxy (SEAL), not directly to the internet" (el tráfico saliente de la microVM se enruta por el proxy del orquestador, SEAL, no directamente a internet).

No despliegues este bloque hoy. La documentación no dice de dónde salen la imagen del kernel y el sistema de archivos raíz, y el runtime que los lee se describe como "in development" (en desarrollo).

Paso 4. Ejecuta AEGIS hoy con Podman

Para producción ahora, la documentación remite al repositorio aegis-deploy: "aegis-deploy is the recommended production deployment path. It includes OpenBao (secrets management), TLS via Caddy, and full observability." (aegis-deploy es la vía recomendada para desplegar en producción. Incluye OpenBao para la gestión de secretos, TLS mediante Caddy y observabilidad completa.) Su inicio rápido, 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

Podman ejecuta los agentes sin root, lo que según la documentación elimina "the privileged daemon" (el daemon privilegiado) y asigna el root del contenedor "to an unprivileged host UID" (a un UID sin privilegios del host). Para evaluar en una sola máquina, el instalador de una línea que aparece en 100monkeys.ai es curl -fsSL https://get.100monkeys.ai | bash, que levanta el stack local de Docker; la documentación marca ese stack como "for local testing and evaluation only" (solo para pruebas y evaluación locales).

Paso 5. Deja el cambio en un cambio de configuración

Escribe los manifiestos de tus agentes sin fijar el aislamiento, para que decida el nodo. El campo isolation del manifiesto acepta inherit, firecracker, docker y process, y su valor por defecto es inherit, "from node config" (de la configuración del nodo). El ejemplo de la referencia de configuración fija el default_isolation del nodo en docker, un valor que "works with both Docker and Podman runtimes" (funciona con los runtimes Docker y Podman). Cuando Firecracker se publique, el cambio será del nodo, no de cada agente.

Paso 6. Sigue el trabajo

La página termina así: "Monitor progress on Firecracker support in the aegis-orchestrator GitHub repository." (Sigue el progreso del soporte de Firecracker en el repositorio de GitHub aegis-orchestrator.) Ahí es donde se nombrará la versión que publique el runtime.

Lo que la documentación deja abierto

Una fecha o versión para el soporte de Firecracker.
De dónde salen el kernel invitado (vmlinux) y el sistema de archivos raíz del agente, y cómo construirlos.
El kernel mínimo: 5.10 en una página, 5.15 en otra.
Otras páginas aún describen Firecracker como el runtime de producción endurecida sin el aviso "not yet available" (todavía no disponible), así que toma la propia página de Firecracker como la palabra vigente.

Hacia dónde seguir

Para instalar el stack de evaluación y ejecutar un primer agente detrás de una aprobación, lee Instala AEGIS en un VPS Ubuntu nuevo y ejecuta tu primera tarea aprobada.

Instala AEGIS desde 100monkeys.ai