Start
How Stableship works
The private copy, audits and checks, kinds of user and rules, findings, verdicts, and who fixes what.
The private copy
Stableship never tests your live app. For each run it builds a private copy: your code on a throwaway sandbox, and a temporary Supabase project built from your migrations and Edge Functions, with sign-in set up for testing. Every active test runs on that copy, and the copy is deleted after the run. Your production database is read for its structure, plus any settings tables you approve (products, plans, flags), and is never written to.
Audits and checks
A full audit tests your whole app: row level security on every table, whether one customer can reach another's records, sign-in, your critical flows clicked through as every kind of user, a phone-size pass, accessibility, a code review against your rules, and Supabase's own advisors. It runs for up to 60 minutes. Your first audit starts when you add the app to a plan; each plan includes more every month.
A check runs on every push and pull request. Stableship picks its scope from what the change touched:
| Scope | When | What runs |
|---|---|---|
| Quick | Ordinary app code, styles, or nothing risky | Replays the flows your audit saved |
| Security | Sign-in, payments, migrations, policies, SQL | Access and security checks |
| QA | Signup, checkout, onboarding, routes, API code | Your flows, as every kind of user |
| Full | Both of the above, or Edge Functions | Everything a check can run |
| Skipped | Only docs, text or CI files | Nothing needs checking |
A project's policy can set a minimum scope for some paths, so a change to sign-in code never gets less than you decided. Checks on pushes and pull requests are not counted against the app's plan, within a fair monthly limit; past it, pushes replay your saved flows until the 1st. A check you or your coding agent ask for at security, QA or full scope is a deep check, and uses one of the app's deep checks for the month (Plans and pricing).
Kinds of user and rules
A kind of user is someone your app treats differently: a customer, a teammate on the same account, an admin, a guest who is not signed in. The rules say who should see what: who may open, create, change or delete each kind of record. Stableship drafts both from your code and database during setup, and you confirm them.
Every test runs as each kind of user and checks the result against the rules. When Stableship or your coding agent finds a table, role or route the rules do not cover, it becomes a rule suggestion for you to accept, edit or dismiss.
Findings
A finding is something a kind of user could do that the rules say they should not, or a flow that does not work. Each one says what happened in plain words ("A member of one company opened another company's invoice"), how severe it is, where to look, and what must be true once it is fixed.
- Reproduced: Stableship proved it. A problem found in the browser is replayed twice on a fresh copy before it can block a release.
- Suspected: a lead Stableship could not prove. It shows as a note and never blocks.
A finding is Fixed once a re-check passes, and Not seen lately when later checks covered it twice without seeing it. See What an audit checks for exactly what can block.
Verdicts
Every run ends with one verdict:
- Cleared: nothing blocks the release. There may be notes to read.
- Held: a proven problem blocks the release.
- Overridden: a person chose to ship anyway. Their name and reason are kept in the activity log.
- Skipped: nothing needed checking.
Holds and ship anyway
On Protect, a held release stays held at your host until the problem is fixed or someone ships it anyway. Holds go through GitHub deployment protection. Lovable, Bolt and Replit publish when you click publish, so for them Stableship says "don't publish yet" instead. On Essentials, every push is checked and you get alerts, but nothing is held. See Held releases and ship anyway.
When Stableship itself fails
An error on Stableship's side never holds a low-risk release: it goes out. A change that touches sign-in, data or payments stays held when the check could not finish, and you can always ship it anyway. Runs that fail on our side never count against your plan.
Who fixes what
Stableship finds the problem, explains it and checks the fix. Your coding agent writes every fix. The fix plan, STABLESHIP_FIXES.md, lists every problem as an ordered task with where to look and when it is done. A connected agent can read the findings directly, fix them in order and ask Stableship to verify each one. Every push after a fix is re-checked. See Fixes, your coding agent and approvals.
For your coding agent: this page as Markdown