We made a cold start take 164 milliseconds
Vercel Fluid works to avoid the cold start — pre-warming and sharing instances so you rarely hit one. We took the other path: scale fully to zero — the sandbox is deleted — then thaw a frozen microVM in the time it takes to read this sentence.
Written by Ajay Kumar · Founder, PandaStack
run → idle → freeze to a seed → thaw on the next request
Every scale-to-zero platform makes the same trade
Scale to zero and you pay nothing while idle — but the next request eats a cold start. Keep something warm and the cold start disappears — but you pay for idle. For a decade that's been the whole conversation.
A scaled-to-zero app woke by cold-booting from its baked disk image: ~26s to pull the multi-gigabyte image, ~8s for the kernel and init, then ~20s for the app to start and bind its port. Honest $0 idle — slow wake.
How long it takes to restore a baked Firecracker snapshot— the same path that gives our sandboxes a 179ms p50 create with no warm pool. A restore isn't a boot: the kernel is up, init has run, the process is in memory.
So the question wrote itself. App wake was 54 seconds because it was a boot. Snapshot restore was 64 milliseconds because it wasn't. What would it take to make app wake a restore?
From 54 seconds to 164 milliseconds
That's not an optimization — it's a different mechanism. One built a machine. The other unfroze one.
wake lands on the seed's node
no download, full boot + app start
full image pull from object storage
last-resort never-fail fallback
Thaw is a memory-snapshot restore, not a boot — roughly 330× faster than a cold-cache boot. Every path eventually reaches a serving app; Thaw just makes the common case sub-second.
Deploy once. Sleep to zero. Thaw on demand.
Nothing runs while the app is idle — the sandbox is deleted. It thaws when a request arrives, so the visitor just waits ~164ms instead of ~54s.
Git push builds the app inside a microVM and serves it.
No traffic for the idle window. The reaper claims it.
App stopped, then one atomic pause snapshots memory + its own disk into a seed.
Sandbox deleted. CPU, RAM, and disk freed. $0 while idle.
A request restores the frozen microVM (~164ms) and starts the app fresh.
Live again, warm latency, with current env and rotated secrets.
A memory snapshot and the disk under it are a matched pair
Restore the memory over a different disk and you've built a machine that lies to itself. We learned that the hard way — every decision in Thaw exists to make that mismatch impossible.
The app process is stopped and its env file deleted first. The memory we're about to freeze has no in-flight request, no half-held lock, and no plaintext secrets.
request path
Because the memory snapshot and the disk copy come from the same instant, they cannot drift. On wake we restore over the seed's own disk — never a fresh template — so the frozen page cache sits over exactly the disk it was cached from. A write-fsync-read liveness gate runs before any request is served.
Thaw vs Fluid
Same problem, opposite directions. Both bets are defensible — they just optimize for different shapes of traffic.
- → Reduces cold starts via bytecode caching + function pre-warming on production.
- → Shares one instance across concurrent invocations; reuses idle resources before scaling up.
- → Bills active CPU (time your code is executing) plus provisioned memory.
- · A managed, no-config model that's a great default for steady traffic.
Per Vercel's own docs — verify against vercel.com, they move fast.
- → Scales to actual zero — the sandbox is deleted, so there's nothing to bill while idle.
- → Makes the cold start cheap (~164ms) instead of working to avoid hitting one.
- · Shines for the long tail: previews, side projects, agents idle most of the time.
- · Built on real microVMs — a container can't be frozen to a file and thawed.
Fluid works to avoid the cold start. Thaw makes the cold start fast — and goes all the way to zero.
The boring security choice unlocked the exciting result
A container shares the host kernel — there's no self-contained machine to snapshot. A Firecracker microVM is a complete machine: its own guest kernel, its own memory, its own virtual disk. That's exactly what makes it freezable. The same property that gives a microVM stronger isolation than a container is the property that lets it cold-restore in milliseconds.
You don't get Thaw on a substrate that was never a real machine in the first place.
Ship on the millisecond cloud.
Free tier with $5.40/mo usage credit. No card. Apache-2.0.