Skip to main content
This guide deploys a small guestbook app: a Python HTTP server that stores messages in SQLite. The code and the database live on an Archil disk mounted into a persistent sandbox, the server runs as a supervised service, and you reach it at a public HTTPS URL. Then you fork preview environments that run a new version of the code, without touching production. SQLite doesn’t need to know anything about Archil. It reads and writes a file on the mounted disk, and Archil keeps the data durable in object storage, so the database outlives any one sandbox.

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):
Then install the SDK:

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 the python: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.
Save the printed URL, then sign the guestbook from your machine:
exposePort makes the port reachable by anyone who has the URL. This guestbook accepts writes from anyone; a real app needs its own authentication before you expose it. For programmatic clients, use a port token instead; see Hosting network services.

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.
The database file sits on the Archil disk next to the code, in WAL mode. SQLite keeps its -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 on guestbook-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.
Each preview is a fork of the template. The fork boots with the 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.
Sign the preview’s guestbook, then compare the two environments:
The preview runs the new code with its own database, and production is untouched. Fork the template again, with a different name, for each branch you want to preview.

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.