Running a Fleet of Firecracker microVMs for eve.dev Agents

One Firecracker microVM on one host is a demo. This series turns it into a fleet: a pool of bare-metal AWS hosts, a control plane that places a new eve agent onto whichever host has room, and a routing layer that hands requests back to it — so a developer can run deploy my-agent and get a live URL. All of it as reproducible AWS CDK infrastructure you can deploy and tear down yourself.

Start with Part 1 →1 of 7 parts published

This is a learning series, not a production blueprint.

The infrastructure built here is designed to teach how the pieces fit together. A fleet of bare-metal hosts, a public deploy API, and multi-tenant microVMs running arbitrary agent code each introduce risks that require deliberate hardening beyond what a tutorial covers. Before running anything like this with real workloads, proprietary data, or user traffic, conduct a thorough security review, understand the attack surface of each layer, and assess the compliance requirements for your context.

The Target Architecture

   developer                              ┌────────────────────────┐
   $ deploy my-agent  ── build rootfs ──► │  S3 artifact bucket    │
        │                                 │  agent images + kernel │
        │  POST /agents                   └───────────┬────────────┘
        ▼                                              │ pull image
  ┌────────────────────┐   place agent   ┌─────────────▼───────────┐
  │  control plane      │ ───────────────►│    host fleet (ASG)     │
  │  API GW + Lambda    │                 │  bare-metal *.metal     │
  │  DynamoDB registry  │◄── heartbeat ───│  ┌──────┐     ┌──────┐  │
  └────────────────────┘    + capacity    │  │ µVM  │ ··· │ µVM  │  │
        ▲                                  │  └──────┘     └──────┘  │
        │ placement lookup                 └───────────┬─────────────┘
  ┌─────┴──────────────┐  agent.fleet.dev  ┌───────────▼─────────────┐
  │  ALB + router       │◄──── clients ──── │  tap devices + NAT      │
  └────────────────────┘                    └─────────────────────────┘
      all inside one VPC — hosts private, ALB + NAT public
FirecrackerAWS CDKEC2 MetalLambdaDynamoDBALBeve.devTypeScript

The Parts

Each part builds on the network from Part 1 and deploys on its own. Published parts link to the full walkthrough; the rest are on the way.

01

Architecture & the Network Foundation

Published

The whole platform — a control plane that places agents onto bare-metal hosts, and a routing layer that gets requests back to them — then the CDK network stack it all lives in: VPC, subnets, and the three security groups that separate the tiers.

AWS CDKVPCTypeScript
02

The Host Fleet

Coming soon

An Auto Scaling Group of bare-metal hosts. A launch template whose user data installs Firecracker and a host-agent daemon, the IAM role each host runs under, and host self-registration with the control plane on boot.

EC2 MetalASGFirecracker
03

Packaging an Agent as a microVM Image

Coming soon

A build-rootfs.sh that turns an eve agent directory into a bootable ext4 rootfs, a versioned S3 artifact bucket the hosts pull from, and where Firecracker snapshots come in for fast boots.

rootfsS3Snapshots
04

The Control Plane: Scheduler & Placement API

Coming soon

API Gateway and Lambda over a DynamoDB registry of hosts, agents, and placements, with EventBridge driving the lifecycle. The scheduler that turns a deploy request into a bin-packed placement decision.

LambdaAPI GatewayDynamoDBEventBridge
05

Networking & Routing

Coming soon

Per-microVM tap devices and NAT on each host, an ALB out front, and a per-agent subdomain scheme so an inbound request reaches the right microVM wherever the control plane placed it.

ALBRoute 53tap/NAT
06

The Deploy Workflow

Coming soon

Tying it together into the deploy-my-agent developer experience — from an eve directory on a laptop to a live URL — and wiring the same call into CI so a merge ships an agent.

CLIGitHub ActionsCI/CD
07

Fleet Operations

Coming soon

Scaling the host fleet on real microVM demand, health-checking and rescheduling agents when a host dies, per-agent logs and metrics, the cost model, and how to tear the whole thing down.

CloudWatchAutoscalingFinOps

New to this? Start with the single-host version — Running an eve agent in a Firecracker microVM on AWS — or the eve framework quickstart for the agent side.

Want This Built for Your Team?

We build agent platforms like this one for clients — reproducible, cost-aware, and documented so your team can own it. Book a free call and we'll map the fastest path.

Book a Free Call