@volter/twin-supabase

Supabase

Version

volter-aiVolter maintainedSelected defaultv1.0.3

Local Supabase twin: a project's Postgres database, the World's own managed Postgres, whose URL the twin hands the application; the Management API, PostgREST, Storage and Auth answer the gap. Built on @volter/world-core.

Set up 1.0.3 Run this twin in your app Source README

Publisher README included in @volter/twin-supabase 1.0.3. Setup gives the installation instructions for this selected 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.

Install the exact twin and World CLI in your app:

npm install --save-dev --save-exact @volter/world@3.0.92 @volter/twin-supabase@1.0.3

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.

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

Use Node 22.6 or newer. Install the CLI, then the exact packages shown alongside:

npm install -g @volter/world@3.0.108

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

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.3"
  }
}

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.

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

volter world up
volter world run -- npm test
volter world log
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.3	volter-ai	Selected default	Not measured

Evidence for 1.0.3

Installed first use · Not measured

Installed first use was not measured for this release. HTTP coverage and publisher trust do not establish this result.

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: ba3aa19f2b582e8c4cf941384c51cdd40ac0d0b1
Catalog record commit: 834ee6a370ea2a8fa9a39d009de40009d14c5cca
Package integrity: sha512-UO5MsMinW6IeZhG92HewkmYVhlM6I4lH8EWMOhNks5Dax0IUQjYJPWdPo9TSqXj0IzDI7luE2nge+p1+5F9Fjw==
Admission mode: Trusted internal publisher · maintainer merge
Catalog assessment: Bundled report checksum verified
Assessed at: Not recorded
Assessment input head: 834ee6a370ea2a8fa9a39d009de40009d14c5cca
Evidence: Assessment and admission

Read the catalog snapshot

Install this version

npm install --save-dev --save-exact \
  @volter/world-core@3.0.108 \
  @volter/twin-supabase@1.0.3

In your app’s folder. Full setup guide

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