feat: support microVM runtime (Firecracker/Cloud Hypervisor) for compute-intensive agent workloads

[mengmengmengqiang]

Background

The current worker sandbox relies on gVisor (runsc) for container-level isolation. This works well for typical agent tasks, but for users who need heavier computation — GPU workloads, long-running builds, or full OS-level isolation — gVisor's syscall interception overhead becomes a bottleneck and the isolation boundary is insufficient.

Proposal

Add support for microVM-backed worker pods (e.g. Firecracker or Cloud Hypervisor) as an alternative runtimeClassName alongside the existing gVisor option.

# values.yaml
worker:
  runtimeClassName: "kata-fc"  # Kata Containers + Firecracker

Why microVMs

Property	gVisor	microVM (Firecracker)
Isolation boundary	Syscall filter (host kernel shared)	Full VM kernel (hardware-level)
Boot time	~ms	~125ms (Firecracker)
Memory overhead	Low	~5MB per VM
Compute overhead	Moderate (syscall interception)	Near-native
GPU passthrough	Not supported	Supported via vfio

Use cases

• Agent tasks that require native kernel features (eBPF, FUSE, kernel modules)
• Compute-intensive workloads where gVisor syscall overhead is measurable
• Stricter multi-tenant isolation requirements where a shared host kernel is unacceptable
• GPU-accelerated inference or training inside the worker environment

Implementation notes

• Kata Containers provides a drop-in RuntimeClass that works with existing K8s pod specs
• No changes to worker image required — Kata wraps the existing OCI image in a VM
• The runtimeClassName field in charts/lobu/values.yaml (worker.runtimeClassName) already exists; this would add documentation and tested values for microVM runtimes
• Node pool with bare-metal or nested-virt support required (e.g. GKE Bare Metal, AWS i3.metal, Hetzner dedicated)

[buremba]

Hi! We did some architectural changes to keep the main agent-loop in the gateway so we don't really need to have a full microVM sandbox unless the agent decides that it needs one. That way the basic messages like "hi!" doesn't need a full sandbox.

I'm open for contribution in case we start with external sandbox providers like Daytona, E2B, Vercel, etc. and we can also add Kubernetes based gVisor, Firecracker sandbox within the same cluster. The focus is on stability at the moment so we removed the Firecracker integration until we stabilize the main system.

[buremba]

Closing as out-of-scope for now.

Since this was filed, the architecture moved the main agent-loop into the gateway, so the basic agent path no longer needs a full microVM sandbox — short messages don't pay the cold-start cost.

When we revisit heavier isolation it'll most likely be via external sandbox providers (Daytona, E2B, Vercel) rather than a self-hosted Kata/Firecracker runtime. Happy to accept a contribution along that direction — open a new issue scoped to a specific provider integration if you'd like to pick it up.

Thanks for the detailed proposal — the table on isolation/boot/overhead tradeoffs was a useful reference. Closing.