3 ms·
Sandflare – I built a sandbox that launches AI agent VMs in ~300ms
I've been building Sandflare for the past few months — it launches Firecracker microVMs for AI agents in ~300ms cold start. The idea came from running LLM-generated code in production. Docker felt too risky (shared kernel), full VMs too slow (5–10s). Firecracker hits the middle: real VM isolation, fast boot.
I also added managed Postgres because almost every agent I built needed persistent state. One call wires a database into a sandbox.
There are great tools in this space already (E2B, Modal, Daytona) — I wanted something with batteries-included Postgres, and simpler pricing
What I'm trying to figure out: how do I get cold start below 100ms? Currently the bottleneck is the Firecracker API + network setup. Would love to hear from anyone who's pushed Firecracker further.
https://sandflare.io
- pasanhk 6mo agoThis is a killer niche. Integrated Postgres solves the biggest headache with ephemeral sandboxes—actually keeping the agent's memory. 300ms is already solid, but getting under 100ms usually means moving from "booting" to Firecracker Snapshots. If you haven't yet, look into pre-warming TAP devices and bypassing the HTTP API for direct process management. Exciting stuff!
- ajaysheoran2323 6mo agoThanks! The snapshot approach is exactly what we're using — UFFD (userfaultfd) to restore from a pre-booted snapshot, with on-demand page faulting so the VM responds before all memory is loaded. That's how we get to ~300ms.
- algolint 6mo ago[flagged]
- aborsy 6mo agoHow much more lightweight is firecracker compared to a minimal image vm? Because one could simply create a proper lightweight vm.
- ammmir 6mo agohonest question: what use case requires cold starts below 100ms, considering TTFT of major LLMs are in the 300+ms range? presumably sandbox will be driven by an agentic loop, so.. you’re still bottlenecked by what essentially amounts to network I/O.
- zephyrwhimsy 6mo ago[flagged]