The backend · and the panel that comes with it

One definition.
Everything it produces.

Rebase turns a Postgres database into a product backend — REST, a typed SDK, realtime, auth, storage and access control the database itself enforces. The admin panel renders from the same file, and only if you ask for it.

The admin panel

Built for the way
you actually work

Not another tool to learn — Rebase works with your existing database and your existing workflow.

Every view. Zero code.

SQL stays first-class

Visual editor, real TypeScript

What you write, what you get

This file becomes the API and the admin panel.

Fields, types, what is required — you write them once, in TypeScript. From that one file Rebase creates the database table, serves the data over an API with a typed client, and renders the screens where your team browses and edits the rows.

The backend

The part that runs without a browser

A Rebase project is a Hono server and a Drizzle schema. It serves your data over REST, streams changes over WebSocket, issues and rotates tokens, stores files, runs your scheduled jobs, and publishes an OpenAPI document that is always current because nobody writes it.

Every one of those requests executes as a restricted Postgres role. That is the part worth reading twice: authorization is a property of your database, not of this process.

What you stop maintaining

  • CRUD controllers, serializers and request validation
  • A hand-rolled back office, and the sprint it costs every quarter
  • JWT plumbing, refresh rotation and password-reset email
  • Permission checks scattered across route handlers
  • File-upload endpoints and signed-URL helpers
  • A cron runner, a webhook dispatcher and an audit-log table
  • The OpenAPI document nobody remembered to update
  • A second data model, kept in sync with the first by hand

One definition

One definition, every surface.

A spreadsheet, a kanban board, a gallery, a block editor, a custom React view — every screen below reads the same collection through the same API, under the same policies. Nothing here is a second data model.

The whole product

Everything Rebase ships, on one screen

The left column runs with nothing else installed. The right column is one dependency away, and deleting it does not move a single API response.

Layer 01

The backend

always on
  • REST API/api/data/:collection

    CRUD, filtering, sorting, pagination, relations

  • Typed SDK@rebasepro/client

    Generated from your collections, checked at compile time

  • Realtimelisten()

    Row subscriptions, channels and presence over WebSocket

  • Auth/api/auth/*

    JWT access and refresh, OAuth, MFA, roles, API keys

  • Storage/api/storage/*

    Local, S3-compatible or GCS, routed per field

  • Functions & cronfunctions/

    Your own Hono routes and scheduled jobs, auto-mounted

  • Row-level securitysecurityRules

    Policies compiled into Postgres — closed by default

  • OpenAPI/api/docs

    A spec and an explorer, regenerated with the schema

Layer 02

The admin panel

included
  • Collection viewsenabledViews

    Table, cards, list and Kanban over the same rows

  • Entity formsproperties

    Generated from properties, with validation and relations

  • Your Reactadmin.Field

    Custom fields, previews, views and entity actions

  • Users & rolesRBAC

    The same roles your policies read, managed by humans

  • Rebase Studio/studio

    Studio is the developer workspace. It registers inside the same panel as CMS.

The panel is a React app that talks to the endpoints on the left, under the same row-level security as your own client. There is no private back channel for data.

Both layers, one command.

Scaffold a project against your own Postgres and see exactly which parts you keep.

~pnpm dlx @rebasepro/cli init