Sleep, wake and fork

An app with no requests for 15 minutes is snapshotted and its container stops. The next request wakes it, and the proxy holds that request open for roughly a second rather than failing it. Waking is not a redeploy: the bundle and the installed dependencies are still on disk, so the runner goes straight to starting the process. Sleeping costs a file on disk, not a machine.

Sleeping is normal and nothing to fix. An app that list_apps reports as sleeping is idle, not broken, and there is no "stay stopped": the next request wakes it, by design.

A connection held open counts as activity for as long as it is open, even when nothing new arrives on it. A gRPC stream, an SSE subscription or a long poll will not be slept out from underneath you.

fork(app: "hn-digest")              → hn-digest--f1, code + data + secrets copied
promote(fork_app: "hn-digest--f1")

The fork gets its own URL and its own copy of the data, taken with the online backup API, so forking an app that is serving traffic with a live writer is safe. That is how a migration gets tested:

fork → deploy the migration to the fork → check it with sql and screenshot → promote

Promoting points the parent's hostname at the fork with a one-row swap, so there is no window where the URL is down. The parent is stopped, not deleted. Promoting it back is the rollback. The fork keeps its own URL either way.