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 will hold on Rebase Cloud when it launches.
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
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.
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.
Role-Based Access Control
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.
Security Principles
Three pillars that define how Rebase handles your data.
One Database, No Copies
Rebase talks to a PostgreSQL database directly — it never ingests a second copy of your data into a proprietary store. Self-hosted, that database is yours and never leaves your infrastructure. On Rebase Cloud, once it launches, it will be a dedicated Postgres cluster we run for you and nobody else.
Database-Level Enforcement
Row-Level Security policies, role-based access control, and JWT authentication — defined in code, enforced by PostgreSQL.
Fully Auditable
The Rebase server is open-source under the MIT license. Audit the code, inspect every query, verify every permission check. No black boxes.
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. It is the only model available today. If you are waiting on Rebase Cloud instead, 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. Rebase Cloud, where we would host it for you,has not launched yet — everything below describes how it is being built, so you can evaluate it before you join the waitlist.
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 would run it for you
Rebase Cloud is our managed hosting, still in development and not yet open to customers. When it launches we will host your database and your application on our infrastructure, which means Rebase would act 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
Rebase Cloud is not open to customers yet — we are running our own products on it while we build it. This is the architecture it is being built on: 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. Join the waitlist in the footer for early access.
Hosted in the EU
Rebase Cloud runs on a Google Kubernetes Engine Autopilot cluster inGoogle 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. Each project gets its own CloudNativePG PostgreSQL cluster, running in its own Kubernetes namespace. There is notenant_id column separating you from another customer — there is a different database.
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 would be the controller, we your processor
- Rebase would process 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.
Audit yours in ten seconds
npx @rebasepro/rls-check $DATABASE_URL — no signup, nothing installed, and it works whether or not you ever adopt Rebase.
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.
