Configuration

All configuration is environment variables — there’s no separate settings file. See .env.example in the repository root for the full list.

Client-safe

These two are the only variables meant to be public (NEXT_PUBLIC_*):

Variable	Purpose
`NEXT_PUBLIC_SUPABASE_URL`	Your Supabase project’s URL.
`NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY`	Supabase’s publishable (anon) key.

If these are unset, the app still runs, but auth is disabled — useful for working on marketing/UI changes without a Supabase project configured.

Server-only

Never expose these to the client

Neither of these should ever be prefixed with NEXT_PUBLIC_ or passed into a Client Component’s props.

Variable	Purpose
`SUPABASE_SERVICE_ROLE_KEY`	Bypasses RLS for trusted server-side code, e.g. `POST /api/projects/register` (see API Keys).
`SUPABASE_SECRET_KEY`	Invokes deployed Edge Functions that require `auth: "secret"` (the “run check now” Server Action, and manual testing). The same value also seeds the `prober_secret_key` vault secret the scheduled cron jobs authenticate with — see Getting Started.

Edge Function secrets

Separate from the .env variables above: RESEND_API_KEY (and the optional RESEND_FROM_ADDRESS override) are Edge Function secrets, only needed for the email notification channel, set via the Supabase CLI — never as .env values, never committed:

pnpm supabase secrets set RESEND_API_KEY=<your resend api key>

Until RESEND_API_KEY is set, an email channel simply fails gracefully (logged, not thrown) on every dispatch attempt.

Database schema

The schema itself is version-controlled, not dashboard-authored: supabase/migrations/ is the source of truth, applied via the Supabase CLI:

pnpm supabase migration new <name>   # create a new migration
pnpm supabase db push --dry-run      # preview what would apply
pnpm supabase db push                # apply it