How it works
Stopped between requests. Restored from memory.
SmolClouds does not keep your app warm — it keeps a picture of your app warm, and puts it back when someone knocks.
Lifecycle
What happens to an app after you deploy it.
The mechanism is the same for every application, whether it serves one request a week or a thousand a day.
- 01
First deploy
We detect the runtime, build the app, boot it once inside a microVM and let it reach a ready state.
- 02
Snapshot
The memory of that booted, warmed-up process is captured as a snapshot and stored alongside the app's disk.
- 03
Stop
With no traffic, the microVM is stopped. Nothing of the app is running; only its snapshot and disk remain.
- 04
Restore
The next request restores the snapshot into a fresh microVM. There is no install step, no cold framework boot — the process resumes with the memory it already had.
- 05
Share
VMs built from the same base image share identical memory pages copy-on-write, so a hundred Node apps do not each pay for their own copy of the runtime.
How it works
Three steps, no infrastructure decisions.
01 — Build
- Claude Code
- Codex
- Cursor
- Your code
02 — Deploy
- $ smolclouds deploy
03 — Done
- your-app.smolclouds.com
SmolClouds handles builds, routing, isolation, HTTPS and scale-to-zero.
Sleep / wake economics
Zero traffic. Nearly zero compute.
Idle apps are not throttled or scaled down — they are stopped. The cost of an app tracks the time it actually spends serving requests.
No requests
Application
Sleeping
No active compute
Request
Wake
Application ready
Response
Cold wake (p95)
Benchmark pending
Time from request arriving at the edge to the restored app responding.
Warm request
Benchmark pending
Response time while the microVM is already running.
Compute billed while idle
None
A sleeping app has no running VM, so there is no active compute to bill.
Architectural: the microVM is stopped between requests.
We publish a latency figure only once it comes from a benchmark we can reproduce and describe. Until then this space stays empty on purpose.
Architecture
Tiny apps deserve serious isolation.
Small does not mean shared. Each application gets a hardware-virtualised boundary — the same primitive that runs serverless workloads at large cloud providers.
SmolClouds Host
Shared Runtime Snapshot
microVM
App A
microVM
App B
microVM
App C
copy-on-write memory · isolated kernels · private network namespace
Firecracker microVM isolation
Every app runs in its own microVM with its own kernel — not a shared process or container namespace.
Shared warm runtimes
VMs derived from the same base image share memory copy-on-write, so identical runtime pages are stored once.
Sub-second wake architecture
Waking restores a memory snapshot of an already-booted app instead of running install, boot and warm-up.
Build as much small software as you want.
Deploy the first one in a couple of minutes. It sleeps when nobody is using it.