Skip to main content
Boxes have an auto-stop timer. The default is 1 hour. The timer counts from creation, not from your last activity: a box with a 1 hour TTL stops one hour after it started, even mid-work. Resuming a stopped box restarts the timer.
Everything on this page needs a payment method on the account. On the free trial auto-stop cannot be disabled and cannot exceed 2 hours — the call is refused with trial_auto_stop_required. See On the free trial.
For work that should keep running until you stop it yourself, disable auto-stop when you create the Box or update an existing Box’s TTL to null:
You can also set No auto-stop from the dashboard. Use this for demos, browser sessions, long setup jobs, or unattended workflows where stopping the VM would interrupt work and force you to restart processes. resume and fork take ttlSeconds too, so a Box that comes back does not need a second call to set its lifetime. Resume keeps the Box’s current setting when you omit it; a fork always defaults to 1 hour rather than inheriting, so forking a Box with auto-stop off does not silently produce another Box nothing will stop. See Snapshots & Copies.

Timed Extension

If you still want an auto-stop deadline, extend the Box instead:
2592000 seconds is 30 days. This is the maximum numeric TTL accepted by the Box API; larger values are capped to 30 days.

Resume and Fork

box stop snapshots the filesystem. box resume restores that filesystem, and box fork creates a new Box from the latest snapshot. Resume takes a few seconds regardless of how much data the Box holds. See Snapshots for what is captured, restore behavior, retention, and how to inspect or download a snapshot. Stop/resume behaves like a server reboot: systemd services you enabled start again automatically. Processes you ran by hand (dev servers, background jobs, tunnels, browser sessions) do not survive a reboot; restart them, or make them a systemd service so they come back on their own (see below).

Run a Background Command

For one-off jobs that outlive the synchronous command limit (builds, installs, data processing), start the command detached and poll for its result. This replaces the nohup ... & pattern for simple cases: no SSH session to keep open, no unit file to write. Synchronous commands cap at timeoutSeconds 600 (10 minutes); anything longer is start → poll → collect.
The command keeps running on the box after the start call returns, with stdout/stderr appended to ~/.ascii/processes/<pid>.log on the box. The status call reports running, the exitCode once finished, and a tail of each log; read the full log from the box when you need more than the tail. The process runs under the box user’s own systemd user manager, so a restart of the box’s agent (a platform upgrade, for example) does not interrupt it. The agent does forget the process on restart: the status degrades to lost, running becomes a best-effort probe, exitCode is no longer reported, and the logs are read from the on-disk files. Detached processes do not survive a stop, resume, or fork on their own. For a process that must come back on its own, run it as an always-on systemd service (below).

Run an Always-On Service

To make a process survive stop, resume, and fork without any action on your side, run it as an enabled systemd service. The unit file lives under /etc, which is snapshotted, so a resumed or forked box starts it automatically.
Restart=always also revives the process if it crashes. Check on it with systemctl status my-app and read its logs with journalctl -u my-app. These are in-box shell commands: run them over box ssh, or programmatically through the command endpoint or the SDKs’ command method. If the service serves HTTP, expose it with host <port>. Hosting the same port again after a resume returns the same URL and token, so links you handed out keep working. See Hosting. Resume or fork from the latest snapshot when a user needs to continue or branch prior work:
For repeatable workflows, keep setup and start commands idempotent:
Command calls are never retried automatically: running a command is not idempotent, so a timeout (retryable: false) or a network failure mid-call leaves the decision to you, because the command may already be running on the box. Synchronous commands accept timeoutSeconds from 1 to 600 (default 30); values outside that range are refused with a 400 invalid_timeout error.