Lifecycle and Persistence

A Sprite is not a server that runs until you turn it off. It runs while something is using it, pauses when nothing is, and wakes when work shows up again. Compute comes and goes. Your filesystem stays. This page is the mental model: when a Sprite is active, what happens when it pauses, what survives the pause, and how the storage underneath it works. The procedural details, the CLI commands, the full activity list, live on the pages linked throughout.

​

Active, warm, cold

A Sprite is active while there’s something to do: a command running, a session producing output, an open TCP connection to its URL, a service handling traffic. While it’s active you’re billed for compute. When the activity stops, a short idle window passes (about 30 seconds today) and the Sprite pauses. It pauses in two stages:

• Warm. The VM is suspended with everything in memory frozen in place. Compute billing stops. The next request resumes it in 100–500ms, and processes pick up mid-thought, exactly where they were.
• Cold. If the Sprite stays idle long enough, the VM is fully stopped and in-memory state is dropped. The next wake takes 1–2s and starts processes fresh.

The difference that matters: a warm wake preserves your running processes, a cold wake does not. You don’t choose between them and you can’t see the transition. A Sprite goes warm first and falls to cold on its own. One thing drops either way: open TCP connections do not survive a pause, warm or cold. Clients reconnect on the next request. For exactly what counts as activity, see Idle Detection. If you need a Sprite to stay active while an agent or worker finishes, that’s the Tasks API, which holds it in an active state instead of letting it pause.

​

What persists

The split is simple: disk persists, memory does not. Install dependencies once and they’re there on every wake. But a process you started by hand, a dev server, a database you launched in a shell, an agent, is gone after a cold wake unless something brings it back. Two things bring processes back:

• Services are processes the runtime owns. It starts them at boot, restarts them on crash, and brings them back after a cold wake. This is how you run a server that needs to answer the request that woke the Sprite.
• The Tasks API holds the Sprite active so the current run finishes before it pauses at all.

​

How persistence works

Every Sprite has an ext4 filesystem. It behaves like real local disk, because it is one: SQLite works in every mode, shared-memory files work, and tools that expect Linux filesystem semantics don’t hit surprises. It is not an object-storage shim or a network filesystem. Underneath, that filesystem is backed by two tiers:

• A hot NVMe cache holds the data you’re actively working with while the Sprite runs. It’s fast and local.
• Durable object storage holds the persistent copy of everything. The filesystem syncs to it continuously, not as a snapshot taken at hibernation.

Because the durable copy is always current, a pause doesn’t move your data anywhere. On wake, the same paths hold the same bytes. You don’t manage any of this.

​

Capacity and billing

Every Sprite starts with 100 GB of storage. It does not autoscale yet, so plan around that ceiling. Storage is TRIM-friendly: you pay for the bytes you actually write, not the full 100 GB, and deleting files lowers your bill. Compute is billed only while the Sprite is active, which is the whole point of pausing.

​

Resources

Each Sprite runs with:

• 8 vCPUs
• Memory the platform manages for you, sized per Sprite and able to scale up under pressure
• 100 GB of storage

You don’t set or resize these yourself. The vCPU count and the storage ceiling are fixed; memory is handled automatically.

​

Related documentation