Prerequisites
Export your Archil API key and a region where sandboxes are available (aws-us-east-1, aws-us-west-2, or aws-eu-west-1):
Write the app
The app uses only the Python standard library.POST / saves the request body as a message, and GET / lists every message under the app’s version. At startup it switches the database to write-ahead logging (WAL), so readers don’t block the writer.
app.py
Deploy it
The deploy script creates a disk for the app, creates a sandbox from thepython:3.13 image with the disk mounted at /srv/app, and uploads app.py onto the disk. It then registers the server as a service with archil-sandbox services create. Services run in the background, restart if they crash, and start again whenever the sandbox boots. Finally, the script exposes port 8080 publicly and prints the URL.
Stop it and let traffic wake it
A stopped sandbox doesn’t use compute, and a request to its public URL starts it again. The next script lists the files on the disk and checks the database’s journal mode, then stops the sandbox and requests its URL.-wal and -shm files beside it while connections are open. The request booted the sandbox, which mounted the disk and started the web service before answering, typically in a second or two. Nothing in the app had to handle the restart.
A plain mount like this one gives the sandbox exclusive access to the disk, so SQLite’s locking works exactly as it does on a local disk. Don’t open the same database file from several sandboxes at once: SQLite’s locks don’t extend across machines. To read the data from elsewhere while the app runs, see Sharing disks.
Create preview environments
To try a change before it reaches production, give it its own sandbox. Rather than setting each one up from scratch, keep a template sandbox with the app already installed and fork it: a fork starts from a copy of the template’s root filesystem, with every package, file, and service definition in place. The template keeps the app and its database on its root filesystem rather than on an Archil disk. A fork mounts the same disks as its source, and a plain mount can be held by only one sandbox at a time, so a template with a disk couldn’t run more than one preview. Previews are disposable, so their data doesn’t need to outlive them. Production isn’t involved at all: it keeps running onguestbook-data while you create and delete previews.
Create the template once. It runs the same app.py as a service, then stops; a stopped sandbox doesn’t use compute.
web service running; the script deploys a change to it, exposes its port, and prints its URL. The sed command stands in for deploying a new version of app.py.
Clean up
A fork must be deleted before the sandbox it was forked from, and a sandbox must be stopped before it’s deleted. Delete the preview, the template, and production, then production’s disk.Next steps
Persistent sandboxes
Lifecycle, services, network access, and forking in detail.
Coding agent in a sandbox
Have an agent build and run an app like this one in a sandbox.
Sharing disks
Mount modes, delegations, and reading a disk from several machines.
TypeScript SDK
Full reference for sandboxes, disks, and serverless execution.