@volter/twin-supabase

Supabase

Version

volter-aiVolter maintainedSelected defaultv1.0.4

Local Postgres for apps using Supabase database connections. Supabase Auth, Storage, REST APIs and supabase-js are not supported by this release.

Set up 1.0.4 Managed app database Source README

The example uses Supabase 1.0.3. Setup installs the selected 1.0.4 release; keep the example's own pins when following it.

Setup gives the current installation instructions for @volter/twin-supabase 1.0.4. Open the published README for credentials, seeds, supported operations and limits.

README shipped with @volter/twin-supabase 1.0.4

These instructions were published with this package. Their tool versions may differ from the current starter cohort. Use Setup to install this version.

A local Supabase project's Postgres database: in a World it is the World's own managed Postgres, and the twin hands the application its URL. A Protocol 3 derived pack (twin-world's architecture, "Protocol 3: the derived pack"); no real Supabase is contacted.

Use Node 22.6 or newer. Install the exact twin and World CLI in your app:

npm install --save-dev --save-exact @volter/world@3.0.147 @volter/twin-supabase@1.0.4

Follow Run a full stack to configure the World-owned Postgres and run your migrations and app inside the World. Keep your native Postgres client unchanged. This release does not implement Supabase's HTTP APIs or make supabase-js calls work.

The managed-database example supplies a complete SQL client and stop/resume workflow. It pins its own example releases; keep the selected release above when adopting this twin in your app.

For an operator calling the server directly:

bun run src/cli.ts serve --database <postgres url>   # without --database the project has no database to hand out (503)

For whom

RH2 (Volter's product), whose authority store is a Supabase project's Postgres, reached over the Postgres wire alone: "no PostgREST, no Supabase client library, no anon session" (journeys/demand.json). Its release migrates the database and its Worker queries it; both are answered by Postgres itself, the World's database (journeys/customer-life.json walks RH2's own statements on it).

What is served

The database. The runtime binds the twin to the World's managed Postgres (managedDatabase: serve --database <url>), and the application connects to that database with any Postgres client. Under the containerless backing its clock follows the World clock. Database-generated randomness belongs to the backing and is not pinned; use explicit stable fixture IDs when comparing fresh Worlds (twin-world architecture, SQL steps).
The door. POST /_twin/app-credentials (the descriptor's credentialDoor, called by the runtime at every boot): makes the World's project world the first time and answers { ref, database_url }, filling SUPABASE_DB_URL.
Not served (the gap): every operation of the Management API (api.supabase.com/v1), PostgREST (/rest/v1), Storage (/storage/v1) and Auth (/auth/v1), each answering its unit's own unknown-route error (journeys/decisions.json); Realtime and Edge Functions (their paths are not claimed, so the injector refuses them).

Units

Unit	Spec	Serves
`supabase` (`src/`)	`spec/openapi.json.gz`, api.supabase.com's own document (170 operations)	the door; the Management API is the gap
`supabase/rest`	`rest/spec/client-ops.json`, the calls `@supabase/postgrest-js` makes	the gap
`supabase/storage`	`storage/spec/openapi.json`, storage-api's document as Supabase's docs publish it	the gap
`supabase/auth`	`auth/spec/openapi.yaml`, GoTrue v2.197.0's document	the gap

Evidence

The vendor's documents and recordings are under each unit's spec/ (its SOURCE.md).

Set up this release

The example uses Supabase 1.0.3. Setup installs the selected 1.0.4 release; keep the example's own pins when following it.

For a complete example, follow Managed app database. It includes the application code and its own exact dependency pins.

Use Node 22.6 or newer. Install this exact starter cohort in your app folder:

npm install --save-dev --save-exact @volter/world@3.0.158 @volter/world-core@3.0.148 @volter/world-runtime@3.0.156 @volter/world-console@3.0.149 @volter/twin-supabase@1.0.4

In your app’s folder, initialize a World with this implementation:

./node_modules/.bin/volter world init --name my-app --twins supabase --source supabase=@volter/twin-supabase

Review the detected vendor and retain the generated bindings. The supabase service’s source must select this version:

{
  "source": {
    "package": "@volter/twin-supabase",
    "version": "1.0.4"
  }
}

This is the source field, not a complete config. Keep the installed version, lockfile and generated service source in agreement. Use the release README for throwaway SDK credentials, seeds and limits.

The assessment records its own earlier tool versions under Measurements. This setup uses the current starter cohort.

Run your app’s own test command inside the World:

./node_modules/.bin/volter world up
./node_modules/.bin/volter world run -- npm test
./node_modules/.bin/volter world log
./node_modules/.bin/volter world down

down stops compute and retains state.

Bring an existing app Recover a failed call Trial an update

Versions and implementations

Package / version	Publisher	Status	First use
@volter/twin-supabase1.0.4	volter-ai	Selected default	Passed
@volter/twin-supabase1.0.3	volter-ai	live	Not measured

Evidence for 1.0.4

Installed first use · Passed

Installed first use: Passed
Fresh app installation: Verified
Workflow scope: Exact installed artifact; normal CLI initialization, unchanged SDK, result assertions and retained-state read-only resume where applicable
Customer SDK versions: pg@8.16.3
CLI, kernel and runtime versions: @volter/world@3.0.147 · @volter/world-core@3.0.147 · @volter/world-runtime@3.0.147
World clock: {"mode":"wall"}
Retained-state readback: Verified
Stopped compute: Verified
Customer journey failures: 0

API coverage, replay and browser measurements

Counts describe the declared HTTP surface, not separate command tables or other protocols. Consult the release README for those workflows.

Assessment scope: packaged-customer-journey; in-process
Declared HTTP surface: 0 served · 330 gaps · 330 declared operations
Exercised HTTP operation coverage: 0 / 330 declared operations (0%)
Journey steps: 182 answered / 184 steps
Replay: Equal across 2 runs
Journey failures: 0
Browser target: Not measured
HTTP operations exercised through Chromium: Not measured
Chromium journey replay: Not measured
Browser response observation: Not recorded
Application-origin CORS coverage: Not measured
Native cookie-jar coverage: Not measured
DOM coverage: Not measured
Source code coverage: Not measured
State transition coverage: Not measured

Operations not exercised

Conformance results

decided: 0 failures · every served operation is decided with its demand; every demanded and every refreshed operation is served
published: 0 failures · what a release publishes holds every unit: its manifest, its spec and its journeys
cited: 0 failures · every vendor fact cited is recorded as a page that answered, each quote found on it
refresh: 0 failures · every stored resource of a vendor-backed unit declares how it is read back, and a unit that sends events ingests the vendor's
registered: 0 failures · a vendor-backed unit, lane or not, reaches the registered pack's state system
allowance: 0 failures · a rate budget above the fallback rests on the vendor's documented allowance, cited in its manifest
client: 0 failures · driven by the vendor's own client (its official SDK), served as a World runs it, the vendor's documented behaviour holds · supabase owes no client case: The demand's application uses node-postgres over the project's native Postgres connection, not a Supabase SDK (journeys/demand.json). The customer life drives that wire; recognized Supabase SDK dependencies do not establish support for Management, Auth, Storage or PostgREST, which remain explicit gaps.
life: 0 failures · the life walked over HTTP against the pack served as a World runs it, with its scenario: every check held
standalone: 0 failures · served by its server.ts as a World runs it, the pack answers HTTP and the boot probe, and each declared socket upgrades

Publisher, admission and provenance

Publisher: volter-ai/twin-packs-open
Source commit: aa8fdf214742cc2bd955d7a5d9d297a995726258
Catalog record commit: 674f488979d7a2c9b8427e39ec259a4eb5beb1ad
Package integrity: sha512-nABAOt9JIS+e5KsG0HtcgdQiKx3BLkD1vp3v3OdsiPC9aCHRCJGf+FX92YWeCWj/hJISmBQkZtRu+Iw2Hmks4A==
Admission mode: Trusted internal publisher · maintainer merge
Catalog assessment: Bundled report checksum verified
Assessed at: Not recorded
Assessment input head: 6b50a8e6367de273865e4b6d201c1698c9432190
Evidence: Assessment and admission

Read the catalog snapshot

Install this version

npm install --save-dev --save-exact @volter/world@3.0.158 @volter/world-core@3.0.148 @volter/world-runtime@3.0.156 @volter/world-console@3.0.149 @volter/twin-supabase@1.0.4

In your app’s folder. Setup instructions

License: Apache-2.0
Node: >=22.3
World kernel: ^3.0.92