State directory

The app config. Fields: entrypoint, args, installCommand, buildCommand, preDeployCommand, buildDirectory, network (none or sandboxed), buildTimeout (minutes or null), buildMemoryLimit (MiB or null), region (3-letter region code or global) and maxReplicas (1 to 16), see Scaling. Missing fields take their defaults (appConfig in common/appconfig.ts), so older files stay readable. The environment is not stored here: readConfig fills env from env/ and writeConfig drops it.

One environment variable per key, so every change is a single atomic write: {"value", "secret", "local", "updatedAt"}. <NAME> matches [A-Za-z_][A-Za-z0-9_]*. local puts the variable in the Local context (context_ids: null in the deno deploy API, otherwise production and preview). A secret variable is write-only: its value is never sent to a browser, the admin API or the deno deploy CLI, it cannot become non-secret again, its local flag is fixed, and saving it with an empty value keeps the sealed one. Values are stored as plain text; builds and instances get all variables, and revision records keep a snapshot of them.

{"id", "createdAt", "updatedAt"}: a UUID used as the app id by the deno deploy API, and ISO timestamps. updatedAt changes on every config write.

The promoted revision id as a JSON string. Promotion is a single set, so the switch is atomic. Missing until the first promotion.

Playgrounds only: {"volume", "createdAt"}, the volume holding the code.

{"status", "updatedAt"}: status is uploading, queued, building, ok or failed, updatedAt the ISO time of the last change.

The revision record:

{
	"prod": true,
	"createdAt": "2026-10-19T19:54:54.664Z",
	"config": { "entrypoint": "...", "...": "..." },
	"source": { "tree": "<sha256 of the root tree>" },
	"git": { "url": "https://...", "ref": "main", "commit": "<sha1>" },
	"manifest": { "blob": "<sha256>", "files": 42 },
	"detect": { "install": true, "build": true, "runtime": true },
	"build": { "image": "<sha256>", "size": 80928768, "nodeModules": true },
	"crons": [{ "name": "cleanup", "schedule": "0 * * * *", "backoffSchedule": [1000] }]
}

{"name", "runs"} for one cron job, keyed by the base64url of its name (cron names may contain spaces). runs holds the last cron.history runs, oldest first:

{
	"id": "mvhngj9o-1a2b3c4d",
	"schedule": "0 * * * *",
	"rev": "mvhngbru-139140f2",
	"attempt": 1,
	"scheduledAt": "2026-10-21T05:00:00.000Z",
	"startedAt": "2026-10-21T05:00:00.012Z",
	"finishedAt": "2026-10-21T05:00:00.140Z",
	"status": "ok",
	"traceId": "<32 hex>",
	"zone": "ord1"
}

Warm runtime sandboxes per network flavor. /app is an empty mountpoint in the rootfs; on assignment the revision's build image is mounted there (runsc debug --mount).

One directory per build sandbox: out/ is the read-write /out slot that receives app.erofs (kept on shutdown, then streamed into blobs/) next to the bundle. The read-write /app slot is the bundle's slots/app/. The bundle's blobfs/0/ backs the read-only /src mount that serves the revision's source tree.

Generic sandboxes (e2b and Deno Sandbox APIs). Their rootfs has an FHS layout (/usr/local/bin, /home/...) and a sparse .gvisor.filestore.<container> file (1 GiB apparent size) backing the writable root overlay.

One record per generic sandbox, kept after it stops. Ids are sbx_<region>_<20 base32 chars>. Fields: id, api (e2b or deno), template, labels, network, memoryMb, cpuCount, volumes ([{volume, path}]), createdAt, stopAt, stoppedAt, pausedAt, autoPause, envdAccessToken, zone, profile and envdVersion (of the zone that runs it, kept so a checkpoint resumes with the same profile), stopReason, image ({build, hash, user, workdir} for template sandboxes), egress (policy without secret values) and the front-door state that has to survive a sandboxod restart: exposures ([{label, port}] of exposeHttp hosts, port is null while a label is reserved but not bound), sshUsers and vscode ({label, pid}).

Volume record: id, slug, capacity, createdAt, zone, and baseSnapshot ({id, slug}) for volumes created from a snapshot. Ids are vol_<region>_<20 base32 chars>. capacity is not enforced.

Snapshot record: id, slug, volume ({id, slug} of the source volume), createdAt, zone. Ids are snp_<region>_<20 base32 chars>.

{"name", "token", "region"?, "cordoned"?, "url"?, "bootId"?, "registeredAt"?}, see Zones. The token is stored in plain text.

e2b templates: {id, name, createdAt, tags: {<tag>: {buildID, createdAt}}} and one record per build with status (waiting, building, ready, error), tags, cpuCount, memoryMB, createdAt, finishedAt, reason, zone, and once ready image ({hash, size} of the EROFS image in blob storage), config ({env, workdir, user}) and logBlob (the build log as JSON lines).

{sub, name, email, picture, idToken, createdAt, expiresAt}: a UI login. The cookie holds the random id, the key only its hash. The ID token is kept as the id_token_hint for logout. Expired sessions are dropped when read and swept on the blob GC interval.

The organization that owns records without an org field (written before multi-tenancy) and records of the single-org org. Startup moves the old slugs/, template-names/ and editor/user keys under it and refuses to start when oidc.legacy_org names a different organization than the stored one.

App metas, sandbox, volume, snapshot and template records carry org, the owning organization id. Every API resolves ids and slugs within the caller's organization, so an id of another organization reads as not found.

{"blob", "size", "createdAt"}: a COPY archive uploaded by the e2b SDK, stored in blob storage under its own hash.

{"settings.json"?, "keybindings.json"?}: the raw text (comments kept) of the VS Code user files of one user in one organization (admin for the admin token), at most 256 KiB each. Written into every VS Code that user opens from the UI and updated when one of them changes the files.

{"id"} of a volume or snapshot. Volumes and snapshots of an organization share one slug namespace, as in the Deno Sandbox API. The slug is claimed with create before anything else is written and released again if creation fails, so two objects never share a slug. Lookups by slug go through it.

BtrfsVolumeStorage keeps every volume as a btrfs subvolume (btrfs subvolume create), bind-mounted read-write into the sandboxes that attach it. A snapshot is a read-only snapshot of that subvolume (btrfs subvolume snapshot -r). A volume created from a snapshot is a writable snapshot of it, so it shares data copy-on-write with its base and outlives it. Snapshots of a volume in use are crash-consistent: sandbox volume mounts use runsc's default --file-access-mounts=shared, so gVisor writes through to the host and btrfs flushes pending writes when it takes the snapshot.