What It Takes to Own Your Agent Platform: The Firecracker Fleet Series in One Read
A capstone to the seven-part series on running eve.dev agents on a fleet of Firecracker microVMs in AWS. The whole platform in one picture, a guided tour of the parts, and the design threads — bare-metal constraints, desired-vs-actual state, event-driven placement, and packing-as-economics — that hold it together.
Running a Fleet of Firecracker microVMs for eve.dev Agents, Part 3: Packaging an Agent as a microVM Image
Part 3 of the hands-on series. We turn an ordinary eve agent directory into a bootable ext4 rootfs with a build-rootfs.sh, store it in a versioned S3 artifact bucket the hosts pull from, inject secrets per-microVM with MMDS, and use Firecracker snapshots to turn a cold multi-second boot into a warm sub-second resume.
Running a Fleet of Firecracker microVMs for eve.dev Agents, Part 4: The Control Plane
Part 4 of the hands-on series. We build the scheduler that turns a deploy request into a running agent — API Gateway and Lambda over a DynamoDB registry of hosts, agents, and placements, a race-safe bin-packing placement algorithm, and EventBridge decoupling the API from the work, all in AWS CDK.
Running a Fleet of Firecracker microVMs for eve.dev Agents, Part 6: The Deploy Workflow
Part 6 of the hands-on series. We turn the moving parts into one command — a deploy CLI that chains build, upload, place, and wait-for-URL; IAM auth on the control-plane API; and a GitHub Actions pipeline that ships an agent on merge and gives every pull request its own preview agent.
Running a Fleet of Firecracker microVMs for eve.dev Agents, Part 2: The Host Fleet
Part 2 of the hands-on series. We put the first machines into the network from Part 1 — an Auto Scaling Group of bare-metal EC2 hosts, a launch template whose user data installs Firecracker and a host-agent daemon, the IAM role each host runs under, and the capacity model that decides how many agents a host can hold.
Running a Fleet of Firecracker microVMs for eve.dev Agents, Part 7: Fleet Operations
The final part of the series. We make the fleet operable — event-driven host autoscaling with lifecycle-hook draining, a reconciliation loop that reschedules agents off a dead host, per-agent logs and metrics rolled up across the fleet, and the FinOps view that turns packing density into cost per agent.
Running a Fleet of Firecracker microVMs for eve.dev Agents, Part 5: Networking & Routing
Part 5 of the hands-on series. We make a placed agent reachable — per-microVM tap devices and NAT on each host, an internet-facing ALB with a wildcard certificate, a per-agent subdomain scheme, and a host-local front proxy that resolves an agent to its microVM wherever the control plane placed it.
Running a Fleet of Firecracker microVMs for eve.dev Agents, Part 1: Architecture & the Network Foundation
Part 1 of a hands-on series turning a single Firecracker host into a fleet that hosts eve.dev agents on demand. We map the whole platform — a control plane that places agents onto bare-metal hosts, and a routing layer that gets requests back to them — then provision the VPC, subnets, and security groups in AWS CDK.
Building a Hybrid LLM Platform on EKS, Part 5: Serving Local Models with vLLM and KEDA
Part 5 of our hands-on EKS series. We deploy vLLM model servers on the GPU pool from Part 4, load Qwen2.5-7B model weights from Amazon S3 via an init container, and wire KEDA autoscaling that scales replicas with live queue depth and drives GPU nodes to zero overnight.
Building a Hybrid LLM Platform on EKS, Part 7: Observability and Cost Telemetry
Part 7 of our hands-on EKS series. We instrument the TypeScript router with OpenTelemetry, upgrade Prometheus to kube-prometheus-stack for GPU and vLLM metrics, add Grafana Tempo for distributed traces, and wire Langfuse so every request shows its backend, token count, and dollar cost.
Building a Hybrid LLM Platform on EKS, Part 6: The Hybrid Router
Part 6 of our hands-on EKS series. We build a TypeScript/Hono router that sits in front of both vLLM and the Anthropic API, routes each request to the right backend based on model name and complexity heuristics, and falls back to cloud when the local model is cold-starting.
Building a Hybrid LLM Platform on EKS, Part 8: Testing, Load, and Examples
The final part of our EKS series. We write integration tests with Vitest, load-test the ALB with k6, build three real-world TypeScript workloads that prove the hybrid routing works, and use the Grafana and Langfuse dashboards from Part 7 to verify the platform under traffic.
Building a Hybrid LLM Platform on EKS, Part 4: Platform Add-ons, the Load Balancer Controller, and Karpenter
Part 4 of our hands-on EKS series. We install the two add-ons every production EKS cluster needs: the AWS Load Balancer Controller so Kubernetes Ingress objects provision real ALBs, and Karpenter for cost-aware autoscaling — including the GPU NodePool that scales to zero between inference workloads.
Building a Hybrid LLM Platform on EKS, Part 3: Node Groups, GPU AMIs, and the NVIDIA Device Plugin
Part 3 of our hands-on EKS series. We add worker nodes to the empty cluster from Part 2: a CPU system pool for add-ons and the hybrid router, a GPU pool for vLLM model servers, the NVIDIA device plugin DaemonSet, and the taints and labels that make scheduling predictable.
Building a Hybrid LLM Platform on EKS, Part 2: The Control Plane, IAM, and IRSA
Part 2 of our hands-on EKS series. We provision the EKS cluster into the VPC from Part 1, wire up OIDC federation and IRSA so pods authenticate without static credentials, and end with a working kubectl connection to a real cluster.
Building a Hybrid LLM Platform on EKS, Part 1: Architecture and the Network Foundation
Part 1 of a hands-on series building the EKS-based hybrid LLM platform referenced throughout this blog. We map out the full architecture, then provision the VPC, subnets, NAT, and VPC endpoints with AWS CDK — the network foundation every later part builds on.
Observability for LLM Applications on Kubernetes: Tokens, Traces, and Cost per Request
How to instrument self-hosted and hybrid LLM workloads with OpenTelemetry, Prometheus, and Langfuse — tracking time-to-first-token, tokens per second, GPU utilization, and unit economics down to the individual request.
Self-Hosting LLMs on Kubernetes: A Practical Guide
How to deploy, serve, and autoscale open-source large language models on Kubernetes with vLLM — from GPU node pools and deployment manifests to KEDA-based autoscaling and production guardrails.