Build your app from a description
Describe your app to Sovariq: it writes the migration with row-level security, access rules, functions and rules tests, checks them on your project without changing it, and opens a pull request.
Tell Sovariq what your app does — who uses it, what they own, what they share, what must never happen — and it writes the backend as a build: a migration (tables, row-level security, helper functions, triggers), access rules, functions and rules tests. The build is checked against your project without changing it, then opened as a pull request on your linked GitHub repository. You review, merge and apply it like any other change.
Start
Link a repository
Functions › GitHub (or the Builds tab on Build › Templates): the repository, branch, and the folders for functions and migrations. Connect GitHub with repository access so Sovaria can open pull requests — your usual connection only reads.
Describe your app to Sovariq
From Build › Templates › Build from a description › Ask Sovariq, or anywhere in the console: "People share recipes; everyone signed in reads them; authors edit their own; notify the author on a like." Sovariq asks when something decides the design.
Read the checks
Sovariq shows each check and what the pull request would add, and fixes failures before it goes further.
Open the pull request
With your go-ahead. Merge it, then sync and apply as below.
What is checked
| Check | How | Fails when |
|---|---|---|
| Migration | Run on your project as up, down, up again in one transaction that is rolled back. | It doesn't apply, its down script doesn't undo it, or it can't apply again after the undo. No down script is a warning. |
| Access rules | Compiled and simulated: every kind of caller against every table, bucket and channel, before and after. | A rule doesn't compile, or visitors who aren't signed in could change data. |
| Rules tests | Each case decided by your access rules with the build's rules standing in, exactly like sov rules test --drafts. | A case gets a different answer than it expects. |
| Functions | Names, entry files (main.py, index.mjs), sizes; Python must compile. | Something is missing or doesn't compile. |
Every check runs with your own permissions, so nothing a build checks is beyond what you could do by hand. The pull request is refused while any check fails, and the build is checked again right before the pull request opens.
What the pull request adds
| File | What it is |
|---|---|
<migrations folder>/<timestamp>_<name>.sql | The migration with its -- migrate:down section. Sync now fetches it; you apply it from Database › Migrations. |
<functions folder>/<name>/… | Each function. Sync (or a push, with deploy on push) deploys it. |
sovaria/policies/<id>.spl | Access rules, for example letting signed-in users call a function (fn:<name>) or listen to a table's changes. |
sovaria/tests/<name>.rules.test.yaml | Rules tests for CI: sov rules test sovaria/tests/<name>.rules.test.yaml --drafts sovaria/policies. |
The pull request's description lists the files, the check report and the steps to ship it.
Without Sovariq
A build is plain JSON or YAML, so you can write or edit one yourself and use the same checks.
sov builds check build.yaml # every check; exit 1 if one fails
sov builds pr <build id> # check again, open the pull request
sov builds listPlans
Checking a build is free; its access-rule and rules-test checks are simulations and count toward your simulations (skipped, not failed, on a plan without them). Opening pull requests is counted per month:
| Free | Pro | Ultra | Team | Enterprise | |
|---|---|---|---|---|---|
| App build pull requests per month (Sovariq) | 5 | 100 | 300 | 1,000 | 5,000 |
| Policy simulations per month | — | 300 | 1,000 | 3,000 | 20,000 |