Lifecycle and Persistence | Sprites

https://docs.sprites.dev/concepts/lifecycle/ • 106 KB fetched
Open original page

Lifecycle and Persistence | Sprites

Skip to content Sprites
Search Press ⌘ K
GitHub
Toggle theme

* Getting Started
* Overview

* Quickstart

* Working with Sprites

* Keeping a Sprite Running

* Sprite Maintenance

* Concepts
* Checkpoints

* Connectors

* Lifecycle and Persistence

* Networking

* Services

* CLI Reference
* Installation

* Authentication

* Commands

* Integrations
* Remote MCP Server

* Claude Managed Agents

GitHub
Toggle theme

On this page
* Overview

* Active, warm, cold

* What persists

* How persistence works
* Capacity and billing

* Resources

* Related documentation

On this page

* Overview

* Active, warm, cold

* What persists

* How persistence works

* Capacity and billing

* Resources

* Related documentation

* Concepts

*

* Lifecycle and Persistence
Copy page

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
Section titled “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
Section titled “What persists”

The split is simple: disk persists, memory does not.

Persists Does not persist
Files and directories Running processes
Installed packages In-memory state
Git repositories Open network connections
Databases (SQLite, etc.) Anything in /tmp you treat as scratch

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
Section titled “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
Section titled “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
Section titled “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.

Memory is not a fixed number to design around
A Sprite doesn’t run with one published RAM figure. Memory is assigned per Sprite, and the platform can autoscale it: when a workload comes under memory pressure, the runtime grows the Sprite’s memory in response, so the amount available changes with demand rather than sitting at a constant. The figure a Sprite reports from inside is adjusted to reflect usable memory, so it isn’t a ceiling to build hard limits against. Size memory-hungry workloads against headroom you’ve measured, not a fixed number.

Related documentation
Section titled “Related documentation”

Working with Sprites
Interaction modes, idle detection, and the filesystem in practice

Services
Processes the runtime restarts on boot, crash, and cold wake

Keeping a Sprite Running
Hold a Sprite in an active state while work finishes

Sprite Maintenance
Keep your Sprites healthy as they sleep, wake, and accumulate state

Was this page helpful? Yes No

Connectors Networking

Company About Pricing Jobs Articles Blog Sprites Infra Log Toolbox Turnout Phoenix Files Laravel Bytes Ruby Dispatch Django Beats JavaScript Journal Resources Docs Customers Support Support Metrics Status Contact GitHub Twitter Community Legal Security Privacy policy Terms of service Acceptable Use Policy

Copyright (c) 2026 Fly.io

Links found on this page

1. Skip to content [direct]
2. Sprites [direct]
3. GitHub [direct]
4. Quickstart [direct]
5. Working with Sprites [direct]
6. Keeping a Sprite Running [direct]
7. Sprite Maintenance [direct]
8. Checkpoints [direct]
9. Connectors [direct]
10. Networking [direct]
11. Services [direct]
12. Installation [direct]
13. Authentication [direct]
14. Commands [direct]
15. Remote MCP Server [direct]
16. Claude Managed Agents [direct]
17. Tasks API [direct]
18. Services [direct]
19. Working with Sprites Interaction modes, idle detection, and the filesystem in practice [direct]
20. Sprite Maintenance Keep your Sprites healthy as they sleep, wake, and accumulate state [direct]
21. About [direct]
22. Pricing [direct]
23. Jobs [direct]
24. Blog [direct]
25. Sprites [direct]
26. Infra Log [direct]
27. Toolbox Turnout [direct]
28. Phoenix Files [direct]
29. Laravel Bytes [direct]
30. Ruby Dispatch [direct]
31. Django Beats [direct]
32. JavaScript Journal [direct]
33. Docs [direct]
34. Customers [direct]
35. Support [direct]
36. Support Metrics [direct]
37. Status [direct]
38. GitHub [direct]
39. Twitter [direct]
40. Community [direct]
41. Security [direct]
42. Privacy policy [direct]
43. Terms of service [direct]
44. Acceptable Use Policy [direct]