The backend /Security & RLS
Secured by the database.
Not by middleware.
Authorization in Rebase is Postgres row-level security, enforced by the database itself — and it fails closed: a table without RLS is refused, never leaked. That holds today when you self-host the open-source stack, and it holds on Rebase Cloud, which runs the same server.
Check the database you already have
You do not have to take any of this on faith. rls-check reads your database's own catalog and reports what is actually exposed: tables served with row-level security switched off, policies that evaluate to true for everyone, views that read straight past the RLS on their base tables. It works on any Postgres — Supabase, Neon, RDS or your own server.
Read-only by construction: it opens a read-only transaction and runs catalog queries. It writes nothing, and no data leaves your machine.
Row-level security, written where the collection is
Define who can read, create, update, and delete each row — enforced directly by PostgreSQL. Policies are written as code in your schema, version-controlled, and applied via migrations. No middleware, no ORM hacks. And it fails closed: a table without RLS has no authorization model, so Rebase refuses to serve it — and prints the exact SQL to protect it at boot. There is no auth check to forget.
The default
A table with no policy serves no rows
Most systems in this category are permissive until you remember to lock them down. Rebase is the other way round: requests run as a restricted Postgres role that owns nothing, so a table you forgot to write a policy for is refused rather than leaked.
That applies to every entrance at once — the REST API, the typed SDK, the admin panel, an agent's scoped key and a psql session all meet the same policies, because the policies are not in the server.
No blanket bypass role
User traffic never runs as the table owner. There is no "service" key that quietly turns policies off for convenience.
Privileged columns protected by default
Auth collections get policies injected so a user cannot promote themselves by writing their own roles column. Opting out is explicit and named.
Junction tables inherit their endpoints
Many-to-many joins are the classic hole. Their policies are derived from both sides of the relation rather than left for you to remember.
One database, no second copy
Rebase talks to your Postgres directly and never ingests your rows into a store of its own. There is one place the policies have to hold, and it is the place the data lives.
You can read the whole thing
The server is MIT-licensed end to end. Audit the code, inspect the SQL it emits, and read the policies back out of your own database with
rls-check.Drift is detectable
The policy editor compares what is in your code with what is in the database and flags anything that has moved — including permissive rules that look safe and are not.
Roles your policies can read
Define roles in your schema — admin, editor, viewer, or any custom role you need. Each role gets granular permissions per collection.
Per-collection permissions — SELECT, INSERT, UPDATE, DELETE per role per collection.
RLS integration — Policies can reference the current user's role for row-level filtering.
JWT authentication — Stateless token-based auth with configurable expiry and refresh.
Your data, your infrastructure
This section describes the self-hosted model. Unlike SaaS platforms that ingest and control your data, the open-source Rebase server connects directly to your own PostgreSQL database, on infrastructure you operate. If you would rather we ran it, skip to the Rebase Cloud section below.
No data migration required
Rebase introspects and adapts to your existing schema.
Zero vendor lock-in
Stop using Rebase anytime — your data stays exactly where it is.
Direct infrastructure access
Full control over your PostgreSQL database, backups, and infrastructure.
Deploy on your terms
Run Rebase wherever you want. No proprietary cloud required.
Your database
Run PostgreSQL anywhere — AWS RDS, Supabase, Neon, a VPS, or your own hardware. Rebase connects to it; you own it.
Your server
Deploy the Rebase backend as a Node.js process or Docker container. Railway, Render, Fly.io, or bare metal — your call.
Your rules
Auth, RLS policies, and API permissions live in your codebase. Review them in PRs, version them in Git, enforce them in CI.
Two deployment models, two security stories
Read this first — almost every claim on this page depends on which one you run. Self-hosted, we never see your data. On Rebase Cloud we host it for you, which makes us a processor. Rebase Cloud is in private beta: it runs real tenants today and opens in batches, and everything below describes what runs now.
You run everything
You install the open-source Rebase server and point it at a PostgreSQL database you own. Your data never touches our servers, there is no third-party processor in the path, and you are the sole data controller.
The Data Sovereignty and Deploy on Your Terms sections below describe this model.
We run it for you
Rebase Cloud is our managed hosting. We host your database and your application on our infrastructure, which means Rebase acts as a data processor on your behalf, with Google Cloud as a sub-processor. Nothing on this page pretends otherwise.
The Rebase Cloud section below describes exactly where that data lives and how it is isolated.
When we host it, here is what that means
This is the architecture running today: your database and your application on infrastructure we operate, with Rebase as a data processor for the data you put in it and you as the controller. Rebase Cloud is in private beta — it runs real tenants today and opens in batches. Request access.
Hosted in the EU
Rebase Cloud runs on a Google Kubernetes Engine Autopilot cluster in Google Cloud europe-west1 (Belgium). Your database and your application containers run there. Rebase Cloud does not currently offer a choice of region.
Processor and sub-processor
You are the data controller for the data your users put into your project. Rebase is the processor, and Google Cloud is a sub-processor because it provides the compute, storage and network Rebase Cloud runs on.
One database per tenant
This is not shared-schema multi-tenancy. Every project gets a PostgreSQL database of its own — there is no tenant_id column separating you from another customer, and a connection is bound to one database, so a cross-tenant read is unreachable rather than policy-gated. That database is a CloudNativePG cluster of its own, in its own Kubernetes namespace, with its own backups — not a database on a cluster shared with other customers.
Network isolation between tenants
Every tenant namespace is created with a Kubernetes NetworkPolicy covering both ingress and egress, so one project's pods cannot open connections to another project's pods or database. Tenant applications are served from *.rebase.website — a separate registrable domain, deliberately never sharing one with the console, so browser cookie and same-site boundaries fall between them.
Encryption in transit and for secrets
Traffic to the console and to every tenant domain is served over TLS, with certificates issued automatically (Let's Encrypt via cert-manager for tenant domains). Secrets the control plane stores for you — project environment variables, database connection strings, cluster credentials, backup credentials — are encrypted at rest with AES-256-GCM. The control plane refuses to start without a valid encryption key; there is no plaintext fallback.
Nightly backups, 30-day retention
Managed databases are provisioned with a nightly base backup plus continuous write-ahead-log archiving to object storage, under a 30-day retention policy — which is also what makes point-in-time recovery possible. Backup state is reported per project in the console, so you can see whether archiving is actually running rather than assume it.
Rebase Cloud will also be able to connect to a PostgreSQL database you already own instead of provisioning one. In that case the database stays entirely under your control and the notes above about the managed database — isolation, backups, retention — do not apply to it.
Where you stand on GDPR
The answer differs by deployment model, so here are both.
You are the controller, and the only processor
- No third-party processor involved. The software runs on your infrastructure; we receive no customer data.
- Direct data access. Fulfill access and deletion requests straight from your own database — no support ticket, no vendor in the loop.
- Residency is your choice. Deploy PostgreSQL in whatever region your obligations require.
You are the controller, we are your processor
- Rebase processes on your instructions. You stay the controller for your end users' data.
- Google Cloud is a sub-processor, providing the compute, storage and network in europe-west1 (Belgium).
- Data stays in the EU by default, because that is the only region Rebase Cloud provisions into.
Need a signed data processing agreement or a formal sub-processor list before you can buy? Email sales@rebase.pro and we will tell you honestly where that paperwork stands.
Found a vulnerability?
Report it privately to security@rebase.pro. Please do not open a public GitHub issue for a security problem, and please give us a chance to ship a fix before disclosing it publicly. We aim to acknowledge reports within a few business days.
Read the policies it writes.
Scaffold a project and inspect the Postgres row-level security generated from your collection definitions — before you trust it with anything.