Skip to main content
This guide runs PostgreSQL in a persistent sandbox with its data directory on an Archil disk. Postgres runs as a supervised service, listens on a public hostname, and requires a password for every network connection. You connect from your own machine with psql, write some rows, stop the sandbox, and read them back. Postgres doesn’t need to know anything about Archil. It reads and writes files in its data directory as usual, and Archil keeps them 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:
On your machine you also need psql and socat, which carries the connection over TLS to the sandbox. Any recent psql works.
Finally, generate a password for the postgres user. The setup script reads it from this variable, and so does psql later:

Write the setup script

This script runs inside the sandbox. The Archil disk is mounted by root, but Postgres refuses to run as root and requires its data directory to belong to the postgres user with mode 0700, so the script hands the directory over first. On an empty disk it then initializes a cluster with a password for the postgres user, creates a self-signed certificate so connections are encrypted all the way to the server, and only accepts network connections that use SSL and a password. Finally, it registers Postgres as a service, which restarts if it crashes and starts again whenever the sandbox boots.
setup.sh
Because the script only initializes an empty data directory, you can run it on a new sandbox that mounts an existing postgres-data disk, and it just starts the server on the data that’s already there.

Start the database

The next script creates a disk, creates a sandbox from the official postgres:17 image with the disk mounted at /mnt/archil, uploads setup.sh, and runs it with your password. Then it exposes port 5432 publicly and prints the hostname.
An exposed port is reachable by anyone who knows the hostname. The setup script requires SSL and a password for every network connection; keep the password long and random, as generated above, and never expose a Postgres user that has a weak password or none.

Connect from your machine

Archil serves public ports over TLS on port 443 with a publicly trusted certificate, and forwards the decrypted TCP stream to the sandbox. psql can’t open that kind of TLS connection on its own, so start a local socat tunnel that listens on port 15432, wraps each connection in TLS, and verifies Archil’s certificate. Use the hostname that create printed:
socat may print a warning that it doesn’t check certificate revocation lists; the tunnel still verifies the certificate. Now connect through the tunnel with your password. sslmode=require makes Postgres encrypt the stream inside the tunnel, too, so it stays encrypted all the way to the server:

Restart it

Stop the sandbox and start it again. Stopping sends SIGTERM to Postgres, which shuts down cleanly. Starting boots a fresh VM, which mounts the disk and starts the postgres service; the script waits until Postgres accepts connections.
Query the table again through the same tunnel:
The rows were on the Archil disk the whole time.
You don’t have to start a stopped sandbox yourself: a connection to its public port boots it, usually within a couple of seconds. Postgres starts listening a moment before it’s ready, though, so that first connection can fail with the database system is starting up. Connect again and it succeeds.

Benchmark it (optional)

The postgres:17 image includes pgbench. This script creates a 10-scale benchmark database (about 160 MB) and runs a 30-second read-write test with 8 clients inside the sandbox:
When the run finishes, look at the tps (transactions per second) and latency average lines of pgbench’s summary. Every commit waits for fsync on the Archil disk, so Postgres keeps its usual durability guarantees.

Clean up

Stop the tunnel, then stop and delete the sandbox and delete the disk:

Next steps

Persistent sandboxes

Lifecycle, services, network access, and forking in detail.

MySQL

Run MySQL the same way, with its data directory on an Archil disk.

Sharing disks

Mount modes, and reading a disk from several machines.

Python SDK

Full reference for sandboxes, disks, and serverless execution.