Sleep guarantees

Last updated 2 November 2026

Rely on a Machine’s database being intact after every sleep; nothing else on the Machine comes back.

• A Machine can sleep when it is idle. A request to one of its ports wakes it.
• Every synced commit in its database is intact after every wake. Volumes are not offered yet, so nothing about them is a promise until they are (see Its Volume).
• Every wake boots fresh: memory, processes and its other disks never come back.
• Every sleep ends its open connections.

What you do about it, and how a Machine stops, is on Sleep, wake and stop.

When it sleeps and wakes

An active connection prevents sleep for being idle. Without one, the Machine can sleep before its sleep-after time. A request to one of its ports wakes it.

• The text below also names exec calls (running a command), SSH connections and inbox events, which Tonbo does not serve.
• sleep_after is the Machine’s sleep-after time: 10 minutes unless you set it.

Word for word

sleep_after is the longest your Machine stays awake without an active connection. It bounds cost; it never keeps a Machine awake. A Machine with an active connection stays awake while the connection is active. Tonbo may put an idle Machine to sleep sooner: one with no open HTTPS, SSH or exec connection, no open network connection of its own, and almost no CPU or network use for 2 minutes. A Machine with a connection open, a request in flight or a running exec call is never put to sleep for being idle. A sleeping Machine wakes on the next request, SSH connection, exec call or inbox event.

What comes back

Every sleep stops the Machine, and every wake boots it fresh, with its database intact (see What a wake starts with).

• Every Machine holds a database, so the sentence below that begins “Until” applies to every Machine: each sleep stops it, and the next wake boots fresh with its database intact.

Word for word

If Tonbo could check the Machine's databases before it slept, the Machine continues where it stopped, on a best-effort basis: its memory, processes and disks come back, its open connections do not, and its clock jumps forward. While it runs again, the disk part of its last snapshot stays stored and is billed as stored bytes until it next sleeps or ends. Otherwise the Machine boots fresh with its database intact. Until the Ursula hook ships, that applies to every Machine that may hold a database.

Memory, disks and connections

Memory, processes, the root and scratch disks and open connections never come back after a sleep.

• Suspend, resume and discard, below, would keep a Machine across a sleep; Tonbo does not suspend Machines, so every sleep stops one and every wake boots fresh.
• A Machine’s disks are its root disk, which holds its image, and its scratch disk; the cache-volume disk, below, is not a Volume.
• The text below also names terminals, which Tonbo does not serve.

Word for word

What	Promise
Memory, processes, terminals, and the root, scratch and cache-volume disks	Ephemeral: suspend brings them back on a best-effort basis.
Open connections	A sleep ends every open connection to the Machine, including a sleep Tonbo starts because it is removing a host it no longer needs. When a Machine resumes, Tonbo resets the Machine's own outbound TCP connections, so its programs see an error at once and can reconnect; its UDP and QUIC flows stop receiving replies.

Your database across a sleep

A sleep never costs you a synced commit: at every sleep Tonbo drains the database, sending what is left, and then stops the Machine (see Data guarantees).

• “It”, below, is the promise on a synced commit; unacknowledged bytes are commits synced() has not confirmed, and the guest is Tonbo’s agent inside the Machine.
• Drained and released: the Machine sends what its databases had left to send, then stops, so its next wake starts fresh. Tonbo keeps no snapshot.
• The sentence that begins “Until” applies to every Machine, for the reason under What comes back.

Word for word

• Suspend does not weaken it. A suspend first requires every database on the Machine to report zero unacknowledged bytes. Otherwise the Machine is drained and released, so a snapshot never holds the only copy of an unreplicated commit. Until Tonbo can prove that report from the Machine's disk (Ursula 0.11.1 and the guest's drain), a Machine that may hold a database is never suspended: it is drained and released, and it boots fresh with its database intact. A snapshot is a discardable cache. A failed, absent or mismatched restore falls back to a fresh boot with the database intact, and only one copy of a Machine ever runs.

What “durable” means for the database is on Data guarantees, and the exact rules of sleeping and waking on Activations.