Getting started

Running it on your own machine

A local Supabase in Docker, a filesystem asset store, a seeded dataset and the Studio on localhost — the setup the test suites use.

Local development runs the same code as a deployment, against a local Supabase stack. Two things differ, and both are explicit rather than inferred.

The stack

bash
npm install
supabase start          # Postgres, Auth, Realtime, in Docker
npm run build           # the packages, in dependency order
npm run bootstrap:deploy   # migrations, administrator, demo content
npm run dev -w web      # http://localhost:3000

Asset bytes go to a directory

There is no Blob emulator, so a separate variable points the asset layer at a directory on disk:

bash
CMS_LOCAL_BLOB_DIR=.blob-local

Set it and the filesystem store is mounted; leave it unset and every path uses the Blob token exactly as a deployment does. It is deliberately a separate variable rather than a sentinel inside the Blob token: a token is a credential, credentials get pasted between environments, and nothing on a deployment platform produces this one.

The environment file

The local values are the ones every supabase start produces — they are well-known defaults, not secrets. The contract itself is validated on every run, and it reports every missing or malformed variable at once, naming where each one comes from, rather than failing at the first.

Running the tests

bash
npm test                # every package, then a skip census
npm run typecheck
npm run lint
npm run build:cold      # clean, then build — the only form that proves build order

The integration suites skip only when nothing is listening on the local stack. A stack that is up but unmigrated or misconfigured fails the run rather than skipping it, because a skip that looks like a pass is how a broken environment ships.