Getting started

Baselyra is a self-hosted backend that runs as two containers: one Node process and one Postgres. This page is the orientation — what the pieces are, which one decides who may read a row, and where to go next. If you would rather type than read, go straight to the quickstart.

What you get

One Node 22 process serves every API prefix and the admin Studio. It talks to one Postgres 17 server, which holds two databases: the project database with your tables, and the control database with Baselyra's own operating data.

Postgres decides, not JavaScript

This is the single idea the rest of the product is built on. Baselyra performs no authorisation in JavaScript. No route handler checks ownership and no query is narrowed for security reasons in the server process. Every request that touches your data runs inside a transaction that has switched to the caller's Postgres role and published their verified JWT claims to the session; row level security policies do the rest.

The anon key is public and is meant to be. It is not a password; it only names the role a request runs as. The service key is the opposite: it reads and writes every row in the project database, so it belongs on a server and nowhere else.

Two identities that are not the same

Baselyra keeps operators and application users in two unrelated tables in two unrelated databases. Conflating them is the mistake this project most wants you not to make.

Consequences worth knowing on day one:

• No row in auth.users can ever open the Studio, however it is configured. Studio tokens carry a typ: "platform" claim inside the signature, and exactly one endpoint mints it.
• select * from control.platform_users in the SQL editor fails with relation does not exist. That is the correct outcome: the hashes are in a database that connection cannot address.
• There is no is_admin column and no auth.is_admin() function. Both were removed. An application's own admin role lives in app_metadata and is read in a policy as (auth.jwt() -> 'app_metadata' ->> 'role') = 'admin'.

The shortest real example

A table, a policy, a user, a query. Every line of this works against a fresh install.

create table public.posts (
  id         bigint generated always as identity primary key,
  author     uuid not null default auth.uid() references auth.users(id) on delete cascade,
  title      text not null,
  published  boolean not null default false,
  created_at timestamptz not null default now()
);

alter table public.posts enable row level security;

create policy posts_read on public.posts
  for select to anon, authenticated
  using (published or author = (select auth.uid()));

create policy posts_write_own on public.posts
  for insert to authenticated
  with check (author = (select auth.uid()));

curl -s "$URL/rest/v1/posts?select=id,title&published=eq.true" -H "apikey: $ANON_KEY"

[{"id":1,"title":"Hello"}]

Nobody sent an author. The column defaults to auth.uid(), and the policy's with check would refuse anything else — ownership is established by the database, not by trusting the client.

What Baselyra does not do

Stated plainly, because finding out on day two is worse.

Database webhooks and cron-scheduled jobs are built — they run in-process with their queue in the project database, under /admin/v1/hooks/* — but the Studio has no page for either yet.

Read in this order

Edit this page Report a problem