Database inrichten

Rollout bewaart alles in een eigen Supabase-project: planning, medewerkers en het auditlog. In deze stap maak je dat project aan, zet je de tabellen en beveiligingsregels erin en leg je vast wie de eerste beheerder wordt.

Wat je na deze stap hebt

Een database in de EU met Row Level Security op elke tabel, een vastgelegde eerste beheerder, en twee waarden voor stap 4: de Project URL en de anon key.

Project aanmaken

Nieuw project in de EU
Ga naar supabase.com → New project. Kies als regio Frankfurt (eu-central-1). Zet een sterk databasewachtwoord en bewaar het meteen in je wachtwoordkluis.
Kies het Pro-plan
Organization → Billing → Pro. Pas dan zijn er dagelijkse back-ups, en wordt je project niet gepauzeerd na een week zonder gebruik. Voor een livegang is dit niet optioneel.
Alleen inloggen met Microsoft
Authentication → Sign In / Providers → Email: zet dit uit. Engineers loggen straks alleen in met hun Microsoft-account (stap 2). Zo bestaat er geen tweede, zwakkere manier om binnen te komen.

Migraties uitvoeren

Migraties zijn SQL-bestanden die de tabellen, beveiligingsregels en functies aanmaken. Er zijn er zeventien (0001 t/m 0017) en ze moeten allemaal, in volgorde. Je hebt twee manieren.

Manier A: met het script (aanbevolen)

Het script deploy/migrate.sh voert elke migratie precies één keer uit, elk in een eigen transactie, en onthoudt wat al gedaan is. Draai het later na elke update opnieuw: het doet dan alleen wat nieuw is.

Beheerwerkplek

De verbindingsgegevens vind je onder Project Settings → Database → Connection string. Je hebt psql nodig (de PostgreSQL-client).

Manier B: in de SQL Editor

Geen terminal bij de hand? Open SQL Editor → New query en plak de bestanden één voor één, in deze volgorde, en klik telkens op Run:

supabase/migrations/0001_init.sql
supabase/setup-0002-0008.sql
supabase/setup-0009-0010.sql
supabase/setup-0011.sql t/m supabase/setup-0017.sql, één voor één

Elke keer hoort er Success te staan. Zie je een foutmelding, ga dan niet verder: meestal is een bestand overgeslagen.

Niet half doen

Een database zonder de nieuwste migraties mist beveiligingsfixes. Na stap 4 kun je dat controleren op de pagina Beveiliging in Rollout: daar moet alles groen zijn.

De eerste beheerder vastleggen

De eerste persoon die inlogt, maakt de organisatie aan en wordt beheerder. Daarna kan niemand meer een organisatie aanmaken. Leg daarom nu vast wie dat mag zijn, anders wordt het degene die als eerste inlogt.

Supabase → SQL Editor → New query

Untitled query

ResultsNog niets uitgevoerd

Collega's komen er daarna alleen in met een eenmalige uitnodigingscode die jij als beheerder maakt.

Waarden noteren voor later

Onder Project Settings → API:

Wat	Wordt in stap 4	Geheim?
Project URL	`NEXT_PUBLIC_SUPABASE_URL`	Nee, staat in de browser
anon / publishable key	`NEXT_PUBLIC_SUPABASE_ANON_KEY`	Nee, publiek bedoeld; alle toegang loopt via Row Level Security
service_role key	nergens	Ja. Rollout heeft hem niet nodig. Zet hem nooit in Vercel

Waarom dit veilig is

De anon key mag openbaar zijn omdat de database zelf bepaalt wat iemand mag: elke tabel heeft Row Level Security, en een organisatie ziet nooit data van een andere. De service_role key omzeilt die regels. Daarom weigert npm run check:env een configuratie waarin hij staat.

Optioneel: meldingen en dagoverzicht

Database → Extensions → pg_net aanzetten: nodig voor meldingen naar Teams vanuit het beveiligingscentrum.
pg_cron: alleen als je elke middag een overzicht wilt van medewerkers die morgen een afspraak hebben en nog niet klaar zijn.

Controleren

Het project staat in Frankfurt en op het Pro-plan
Alle migraties t/m 0017 zijn uitgevoerd zonder fouten
bootstrap_admin_email is gezet
Inloggen met e-mail staat uit
Project URL en anon key staan klaar; de service_role key staat nergens