Self-installing
Four steps, in one build
The Supabase project this deployment provisioned had zero tables. The build is therefore self-installing, and runs the same four steps on every build, in this order — idempotently, because preview and production builds share one database.
What runs, in order
Migrations, under an advisory lock
Ordered, idempotent SQL files applied inside a Postgres advisory lock, so two builds of the same commit cannot interleave and half-apply a schema.
The administrator
Created and confirmed once, never re-created, and its password never rewritten. A build step that silently reset a password would be indistinguishable from an account takeover.
The demo content, and its images
Only into a dataset with no content documents, and always with createIfNotExists on fixed ids — so a later build cannot overwrite an edit you made.
A sign-up posture check
A fresh project should not leave the front door open. The build asserts the posture and warns loudly in the log when it cannot close it automatically.
Why re-running it is safe
Preview and production builds share one database and the pipeline runs on every build, so every step has to be idempotent in two independent ways.
- The gate. The content seed runs only when the dataset holds no content documents. A second build writes nothing and pays no storage operation.
- The mutation. Every seeded document has a fixed id and is written with
createIfNotExists. So even when the gate opens — two builds racing, or a dataset somebody emptied — an existing document is returned untouched, including every field an author changed.
The second is not belt and braces. The gate is a read followed by writes in separate transactions, so two concurrent builds can both pass it; fixed ids make that race converge on one copy instead of two.
Questions this usually raises
What happens to my edits when I redeploy?
Nothing. The seed sees content in the dataset and stops before writing anything. Even with the gate open, createIfNotExists on a fixed id is a no-op for a document that exists.
Can I delete the demo content?
Yes — delete the documents from the Studio. The one thing to know is that emptying the dataset entirely re-opens the seed gate, so the next build will seed it again. That is the documented meaning of “runs when the dataset is empty”.
Where do the demo images come from?
They are committed bytes in the repository — deterministic gradients, generated as indexed-colour PNGs so a 1200×630 image costs a few kilobytes. A build that downloaded its demo imagery would fail in a way a deployer cannot fix.
Do it on your own account
The whole pipeline is in the repository, and the deployment it produces belongs to you.