AUTHSY BACKEND PLATFORM AURADB ENGINE MIT
Draw your backend on a canvas, deploy it, and talk to it from one client library. One rule per table decides who can read a row, and the database enforces it — so your code never has to remember to filter, and a route that forgets cannot leak anything.
none / owner / authenticated / public
The database comes with the platform
Users, queries, files, one install
From an empty account, in the quickstart
It does not have to. A table whose rule is owner returns
that caller's rows and nothing else — for every route, every query, and
the endpoint somebody adds next year and forgets to filter. The rule
belongs to the table, so it applies everywhere the table is read.
// your app's own users, your app's own rows import { createClient } from '@authsy/client'; const authsy = createClient(host, 'lsk_…'); await authsy.auth.signUp({ email, password }); await authsy.from('notes').insert({ body: 'mine' }); const { data } = await authsy.from('notes').select(); // → only theirs. Sign in as somebody // else and find nothing.
The same call, signed in as somebody else, comes back empty. Not filtered down to empty — never read in the first place, because the rule is checked where the row is decoded rather than in a predicate the query had to remember to carry.
Nothing reaches a client. Server-side work only — the table is not readable through the API at all.
Each caller sees the rows they own. It stays fast as the table grows, because the rest are never read.
Any signed-in user of this project. A signed-in stranger from another project is not one of them.
Readable without signing in. Writing is still governed by the rule, so “public” never means “editable by anyone”.
Access rules usually fail one of two ways: the rule is right but something connects in a way that skips it, or the rule is right but a new endpoint never goes through it. Neither can happen here. There is one place a rule is applied, every read goes through it, and there is no setting anywhere that turns it off.
Two projects on one account cannot reach each other's data, even by asking for a record by its exact id. Staging cannot read production, a client's project cannot read another client's, and neither of those depends on anybody remembering to keep them apart.
“The rule looks right” is how access control fails. So the access review does not read your rules back to you. It signs in as each kind of caller in turn — nobody, a signed-in stranger, the person who owns the row — and reports what each one was actually given. Nothing it does is kept: the whole check is undone when it finishes.
| Caller | Read | Insert | Update | Delete |
|---|---|---|---|---|
| Case 01anonymous | Deny0 rows | Deny | Deny | Deny |
| Case 02signed-in stranger | Deny0 rows | Passown only | Deny | Deny |
| Case 03the row's owner | Pass3 rows | Pass | Pass | Pass |
CHECK COMPLETE · NOTHING CHANGED FINDINGS: rule_drifted FINDINGS: not_deployed Open the docs
The rule on your canvas and the rule the live table is using are not the same. Editing a rule and not deploying it changes nothing, which is the safe direction — and still worth being told about.
A table exists on your canvas but has never been deployed. There is nothing live to review, and nothing live to leak.
Every number comes from what is actually live, not from what is open in an editor. A draft is a draft, and the review says so rather than counting it.
A project is a canvas, the tables and documents on it, its own users, and the keys that reach it. What comes with it is the week of admin screens you were going to build anyway — editable top to bottom, with your own columns and each person's licence already on their record.
01 · USERS TABLE
The screen you run support from. Edit a record, add columns of your own, see the licence somebody bought sitting on their row, ban an account. It shows what a user owns beside what they can actually see, and you can look at the app as one of them without any risk of changing their data by accident.
02 · APP USERS
Sign-up, sign-in, sessions and rotating refresh tokens, separate from your Authsy account and from every other project.
03 · DOCUMENTS
Store JSON documents and query them the way you already know — find, count and aggregate, with the filters and grouping you would expect. The same access rules apply.
04 · LUMEN
Our own query language, for when a person is writing the query rather than a program building it. A collection, then a run of steps, in the order they happen.
05 · STORAGE & REALTIME
Files under the same access rules as your rows, updates pushed to clients as they happen, and a REST endpoint for everything you deploy without writing one.
06 · LICENSING, KEYS & PAY
Licence keys with device binding, activation limits, trials, subscriptions and floating seats; a key gateway with checkpoints and issued-key statistics; and Authsy Pay for checkout, payment links, charges and payouts. If you are only building a web backend you can ignore all of it — it is a section inside a project, not something you have to set up first.
07 · REFERENCE
The client library, the row rules, collections, storage, the key system and the licensing API — with the request and response for each.
There is nothing to provision, nothing to connect and nothing to keep in sync. Your projects, their users, their rows and their files all live in one place, which is what lets a change that touches several of them either happen completely or not at all.
| Setup | None. No database to create, no connection string to paste, no credentials to rotate. It is running the moment your account is. |
|---|---|
| Durability | When a write comes back, it is saved. Not queued, not cached, not probably — saved, including through a sudden restart. |
| Access | Your access rules are applied by the database itself. Every read goes through them, so there is no path around them and no setting that disables them. |
| Isolation | Projects cannot reach each other's data. Staging cannot read production, and one client's project cannot read another's. |
| Backups | Take a copy at any time, without stopping anything and without a maintenance window. |
| Portability | Export a project whole — its structure and its data — and import it somewhere else. Nothing you store is trapped here. |
| Self-hosting | Run the whole platform yourself: one service and one directory to back up. It is MIT licensed. |
Most of the work in standing up a backend is not the code — it is the database you have to create, the credentials you have to store, the pool you have to size, the migration you have to run, and the second service you have to keep alive next to the first.
None of that exists here. You draw what you want, deploy it, and it is there. When you need to move, the whole project exports and imports again, so choosing us is not a door that locks behind you.
Licence keys are unlimited on every tier, including the free one, because counting them would charge you for the ones nobody redeemed. Top up in packs when you run out, and plans lapse back to free on their own rather than failing closed on your users.
$0/ month
$9/ month
$29/ month
$99/ month
ALL TIERS · UNLIMITED LICENCE KEYS TOP-UP PACKS AVAILABLE PLANS LAPSE TO FREE Or self-host it — MIT
Nothing, which is the point. The filter was never the mechanism — the rule on the table is. An endpoint that asks for a whole table and forgets to narrow it gets back exactly what its caller was allowed to see, which on an owner table is that caller's own rows and no more.
Run the access review. It signs in as each kind of caller in turn — nobody, a signed-in stranger, the person who owns the row — and reports what each one was actually given. It tells you what happened rather than that a rule exists, and it measures what is live rather than what is open in an editor. Nothing it does is kept.
No. It comes with the platform and is running the moment your account is. Nothing to create, nothing to connect, no credentials to store and no second service to keep alive next to the first.
Same account, same project, reached as a section rather than a second dashboard. You choose what a project is for when you create it, so a licensing project opens on licensing and a backend project never shows you a payments panel you did not ask for.
Yes. The whole platform is MIT licensed and self-hosting is one service and one directory to back up. You can also start hosted and move later — a project exports whole, with its structure and its data.
Ending with the part where you sign in as somebody else and find nothing.