Skip to main content
Variables with the NEXT_PUBLIC_ prefix are exposed to the browser. Do not place server-only secrets behind that prefix.

Core app and Supabase

For local setup, keep secrets in .env.local. npm run env:check now reads .env and .env.local the same way Next.js does, so the output is closer to the app’s real behavior.

Feature toggles

If a toggle is not set, the repository treats that feature as enabled. Set false, 0, no, or off to disable it.
For auth, setting the toggle to true is not enough by itself. If NEXT_PUBLIC_SUPABASE_URL or NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY is empty, the auth pages will fall back to a notice state instead of forcing a broken client initialization.

Payments

Email and contact

Admin and access control

ADMIN_EMAILS is not the final source of truth. After the user signs in, the repository manages real access through the user_roles table.

AI

Optional env for operations

Common toggle profiles

This section helps when you want to start from a realistic feature combination instead of keeping everything enabled at once.
Good when you are still validating demand.
You still need NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY because waitlist depends on Supabase. If contact is enabled, you also need RESEND_API_KEY.
Good for most classic SaaS products.
Make sure Supabase public env, SUPABASE_SERVICE_ROLE_KEY, and the chosen payment provider credentials are filled in.
Good when AI is a core product feature.
In addition to payment env, you also need OPENAI_API_KEY or ANTHROPIC_API_KEY depending on the default provider.
Good for gated product areas, internal dashboards, or client workspaces.
The minimum setup is just Supabase. You can enable admin later if you need an internal operations panel.

Minimal .env.local example

Use this if you only want auth, dashboard, and one payment provider:

Quick way to verify env values

  1. Make sure the latest values are already in .env.local or .env.
  2. Run npm run env:check.
  3. Read the status for each feature: ready, fallback mode, or disabled by ....
  4. After the app is live, open GET /api/health for a more detailed readiness summary.
  5. If you just changed env values, restart npm run dev and check again.
If a feature is not part of your product yet, it is better to disable it explicitly than to leave it half-configured.