Set up the database

Rollout stores everything in its own Supabase project: planning, employees and the audit log. In this step you create that project, put the tables and security rules in it, and record who becomes the first administrator.

What you have after this step

A database in the EU with Row Level Security on every table, a recorded first administrator, and two values for step 4: the Project URL and the anon key.

Create the project

New project in the EU
Go to supabase.com → New project. Choose Frankfurt (eu-central-1) as the region. Set a strong database password and store it in your password vault right away.
Choose the Pro plan
Organization → Billing → Pro. Only then are there daily backups and is your project not paused after a week without use. For a go-live this isn't optional.
Microsoft sign-in only
Authentication → Sign In / Providers → Email: turn this off. Engineers will only sign in with their Microsoft account (step 2). That way there's no second, weaker way in.

Run the migrations

Migrations are SQL files that create the tables, security rules and functions. There are seventeen (0001 to 0017) and they all have to run, in order. There are two ways.

Option A: with the script (recommended)

The script deploy/migrate.sh runs each migration exactly once, each in its own transaction, and remembers what's done. Run it again after every update: it then only applies what's new. (Its messages are in Dutch.)

Admin workstation

You'll find the connection details under Project Settings → Database → Connection string. You need psql (the PostgreSQL client).

Option B: in the SQL Editor

No terminal at hand? Open SQL Editor → New query and paste the files one by one, in this order, clicking Run each time:

supabase/migrations/0001_init.sql
supabase/setup-0002-0008.sql
supabase/setup-0009-0010.sql
supabase/setup-0011.sql to supabase/setup-0017.sql, one at a time

Each time it should say Success. If you see an error, stop: usually a file was skipped.

Don't do half of it

A database without the latest migrations is missing security fixes. After step 4 you can check this on the Security page in Rollout: everything there should be green.

Record the first administrator

The first person to sign in creates the organization and becomes administrator. After that nobody can create an organization any more. So record now who that may be; otherwise it's whoever signs in first.

Supabase → SQL Editor → New query

Untitled query

ResultsNothing run yet

After that, colleagues only get in with a one-time invitation code that you create as administrator.

Note the values for later

Under Project Settings → API:

What	Becomes in step 4	Secret?
Project URL	`NEXT_PUBLIC_SUPABASE_URL`	No, it's in the browser
anon / publishable key	`NEXT_PUBLIC_SUPABASE_ANON_KEY`	No, public by design; all access goes through Row Level Security
service_role key	nowhere	Yes. Rollout doesn't need it. Never put it in Vercel

Why this is secure

The anon key may be public because the database itself decides what someone may do: every table has Row Level Security, and an organization never sees another's data. The service_role key bypasses those rules. That's why npm run check:env refuses a configuration that contains it.

Optional: alerts and daily digest

Database → Extensions → pg_net on: needed for alerts to Teams from the security center.
pg_cron: only if you want an overview every afternoon of employees with an appointment tomorrow who aren't ready yet.

Check

The project is in Frankfurt and on the Pro plan
All migrations up to 0017 ran without errors
bootstrap_admin_email is set
Email sign-in is off
Project URL and anon key are ready; the service_role key is nowhere