Serverless on real microVMs. Scale to zero. Wake in under 350 ms.
Deploy functions to Firecracker microVMs on bare metal. They snapshot when idle and restore on the next request — one CLI and one API for humans and the agents they run.
Example session. Timings illustrate the documented p50 — they are not measured in your browser.
0 ms
documented p50 wake
0
vCPU billed while idle
0
microVM per app, own kernel
0
runtimes: node, bun, python, go
How it works
Deploy once, snapshot, wake
Three states, and your app is always in exactly one of them.
Deploy
Point Voopr at a Git ref. It builds once, records an SBOM and provenance, and boots the app in its own Firecracker microVM.
voopr deploy --ref main
Snapshot
When traffic stops, the whole memory image is written to disk and the VM is torn down. Nothing is resident, nothing is billed.
idle 30s → snapshot · parked at zero
Wake
The next request, cron tick or queue message restores that exact snapshot — an already-warm process, not a fresh boot.
GET / → restore 214 ms → 200 OK
How a request is served
Nothing runs until something asks
Every app is a snapshot until its first request, and a microVM from then until it is idle again.
Live request console: requests arrive, a cold request wakes the microVM in 312 milliseconds, the instance serves traffic and is snapshotted again with zero idle cost.
- idle
- waking
- servingmicroVM live
- snapshotted
- status · serving
- p50
- 0 ms
- p99
- 0 ms
- idle cost
- $0
The platform
deploy · main
Deploy
One-shot deploys from a Git ref, every build carrying an SBOM and provenance, secrets scanned on the way in and egress denied by default. Each pull request gets its own URL under your domain.
wake sources
Wake
Idle apps snapshot and park at zero. The next request — or a cron tick, or a message on a queue — restores the same snapshot in under 350 ms. Schedules and queues come with the platform, not a second service.
runtimes
Run
Handlers run in hardware-isolated microVMs, invoked sync or async. Stateless by design: plug in the managed Postgres, object store or KV you already use — the URL is a sealed secret, the env var is what your code reads.
wake timeline
Observe
Streamed logs, per-app metrics, a trace for every invocation and a timeline for every wake — alerts when it matters, and an audit log of every write.
Why Voopr
Real microVMs, not containers in disguise
Most serverless runs your code in a shared container and hopes. Voopr gives every function its own Firecracker VM — isolated, snapshotted when idle, and back in under 350 ms.
hello · microvm
Hardware-isolated
Every app runs in its own Firecracker microVM on bare metal, with its own kernel. Noisy neighbours and shared runtimes are somebody else's problem.
wake wk_2f8a
Back in under 350 ms
Idle apps snapshot to disk and park at zero. The next request restores the same snapshot in under 350 ms — scale-to-zero that costs a blink, not a cold start.
$ voopr deploy --ref main
Deployed hello · bld_9k2f
$ voopr cron add "0 */6 * * *"
$
One CLI, one API
Deploys, schedules, domains, secrets and logs behind one CLI and one API — the same surface for you and for the agents you run.
env · at wake
Bring your own state
Stateless by design. Plug in the Postgres, object store or KV you already run — every URL is sealed at rest and injected at wake, rotatable from the CLI.
Comparison
Container serverless vs Voopr
The same handler, a different machine underneath it.
| Container serverless | Voopr | |
|---|---|---|
| Isolation | Shared kernel, container namespace | Firecracker microVM, own kernel |
| Idle cost | Provisioned concurrency to stay warm | Zero — the app is a file on disk |
| First request | Cold start: runtime boots from scratch | Wake: memory snapshot restored |
| Schedules & queues | Separate services to wire up | Part of the same app and CLI |
| State | Opinionated, provider-bound stores | Bring your own Postgres, S3 or KV |
FAQ
Questions before you deploy
A cold start boots a runtime from nothing. A Voopr wake restores the exact memory snapshot of an already-warm process, so the documented p50 stays under 350 ms.
A dedicated Firecracker microVM on bare metal — hardware isolation per app, not a shared container with a namespace around it.
Nothing. An idle app is a snapshot on disk: no vCPU, no memory, no bill.
Yes. Voopr is stateless by design — point it at the Postgres, object store or KV you already run and seal the URLs as environment variables.
Create an account, run one deploy command against a Git ref, and your app answers on its own URL in a couple of minutes.
Flexible pricing for any scale
Pick a plan, pay for the compute you actually use. Scale-to-zero means idle costs nothing.