Configuration

Where you run code (your app, CI, or a script), you supply the Supabase URL and keys yourself. Deployed Edge Functions are different: Supabase injects every variable whose name starts with SUPABASE_; you never set those as custom secrets.

See the repo .env.example for names used in this project.

SDK and CI

Point createDbClient, tests, and scripts at your project using values from Project Settings → API in the Supabase dashboard. Do not commit real keys.

Edge Functions

Built-in SUPABASE_* variables

On Supabase-hosted functions, the runtime provides SUPABASE_URL, SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY, and any other reserved SUPABASE_* names for your project. Read them with Deno.env.get(...) as usual.

You cannot create dashboard secrets or supabase secrets set entries that start with SUPABASE_. Those prefixes are reserved. Nothing to configure for them in production.

Your own secrets

Only use Edge Functions → Secrets or supabase secrets set for names that do not start with SUPABASE_ (feature flags, third-party API keys, and so on).

ingest-meter-reading

Relies on the injected SUPABASE_URL and SUPABASE_SERVICE_ROLE_KEY for service-role access. No manual SUPABASE_* setup.

Local development

1. From the repo root: pnpm start or pnpm supabase:start (Supabase CLI project in apps/supabase).
2. After migrations: pnpm gen-types so the SDK matches the database.
3. pnpm supabase:functions (or cd apps/supabase && supabase functions serve …) exposes the same built-in SUPABASE_* names locally; anything else your function needs goes in your env file or CLI flags. See local Edge Functions.

Tests

pnpm test and pnpm test:ci read SUPABASE_URL, SUPABASE_ANON_KEY, and when needed SUPABASE_SERVICE_ROLE_KEY from the environment (same as the SDK table above). Details: tests/README.md in the repo.