Deep sleep

A sandbox that has been asleep for deep_sleep_after (template field, default 7d, off disables; overridable per sandbox on create) is taken down with compose down: its containers and its network are removed, its volumes and opt/sandboxes/<owner>/<name>/ stay. The volumes hold everything a user keeps: the sandbox's inner Docker (docker_data: images, inner containers and their volumes) and the sandbox's own /opt, /root, /home and /srv, so nothing written there is lost when the container is recreated (deep sleep, or a container removed by hand). Anything else in the sandbox container's file system (e.g. packages installed with apk add) is not kept. This frees Docker networks, which are limited. Purgatory checks every DEEP_SLEEP_CHECK_INTERVAL (default 1m).

Requests for a deep-sleeping sandbox have no sandbox router, so they reach Purgatory's catch-all /wake, which rebuilds the stack (compose up) and shows a waiting page that updates until the app answers — usually 20–60 s. From then on Sablier handles it as usual. The API reports such sandboxes with status: "deep_sleep", and POST /sandboxes/:name/start (Wake in the UI) brings them up. Deep sleep now on the details panel's Settings tab (POST /sandboxes/:name/deep-sleep) takes a sandbox down right away, without waiting for deep_sleep_after.

An asleep sandbox whose containers point at a network that no longer exists is taken down the same way at the next check, whatever its deep_sleep_after. This happens after docker compose down on the Purgatory stack, which removes and re-creates traefik-net: without it, Sablier could never start the sandbox again (exit code 128, "network … not found") and its waiting page would spin forever. The next request rebuilds it on the current networks; its data volume is kept.