Skip to main content
Your Cloud key is your database. Threads, apps, records, blobs, grants, approvals, audit, and runs persist in Vendo Cloud’s Postgres.

​
The store slot fills itself

createVendo picks the store at composition time. With VENDO_API_KEY set and no store passed, the slot takes the hosted store.
app/api/vendo/[...vendo]/route.ts
The adapter never reads the environment. The composition does, then hands the adapter a key and a base URL. Your boot log says which one won:
vendo ready
Tenancy resolves server-side from the key’s organization on every call — nothing in your process picks a tenant. ensureSchema() is a no-op here, because the service owns its own migrations. Passing your own store adapter also works, and always wins.

​
What lands where

Blobs ride the same store unless you pass a files adapter, so rows and objects can never drift apart.

​
What the store refuses

Three writes are refused outright, each with a code rather than a silent no-op. Secrets never ride the hosted wire. The store has no secrets surface by construction: values resolve from your process environment first, and Cloud’s secrets provider answers only for names the environment leaves unset.

​
Racing writers

Two ticks, two retries, or two agent runs can land on the same record. The collection handle carries compare-and-set primitives for that case.
claim returns true for the single caller whose read of expected still matched. insertIfAbsent and compareAndSwap return null when another caller won. Both are optional on the handle, which is why the calls above are guarded. Your own collections expose them; Vendo’s internal tables vary.