This is a Next.js project bootstrapped with create-next-app.

Getting Started

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

Supabase Setup

Set NEXT_PUBLIC_SUPABASE_URL and either NEXT_PUBLIC_SUPABASE_ANON_KEY or NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY in .env.local using the project URL and public key from Supabase. These public client credentials are not service-role secrets. Restart the dev server after changing them.

Apply the SQL migration in supabase/migrations to create the row-protected profiles table and the auth-user profile trigger.

For production, configure auth rate limits in Supabase Auth settings. Never expose a Supabase service-role or secret key.

Google Sign-In

Enable Google in Supabase Authentication's provider settings and configure its Google OAuth client. In Google Cloud, use the Supabase provider callback URL shown in those settings as an authorized redirect URI (not the application's /auth/callback URL). Configure the OAuth consent screen with your application's name and authorized domains; if the app is in testing mode, add the accounts that need to sign in as test users.

In Supabase Authentication's URL configuration, set the production Site URL to https://my-app-auth.netlify.app and allow https://my-app-auth.netlify.app/auth/callback as a redirect URL. Add the corresponding callback URL for each development or preview origin you use. The sign-in page starts authentication on its current origin, so the callback must be allowed for that same origin.

Google sign-in requests an account chooser instead of silently selecting a saved Google account. The dashboard displays the authenticated account's email so users can confirm which account they selected. Cancellation or an unsuccessful callback returns to the sign-in page with an error instead of granting dashboard access.

Supabase Auth performs server-side email and password validation. The profile migration applies a database length constraint and own-row RLS policies. This repository defines only profiles; review every other table in the live database and enable RLS with table-specific policies. @supabase/ssr manages auth cookies, but XSS prevention is still required because script execution in an authenticated page can perform actions as that user.

Runtime and database scaling

The browser Supabase client is initialized lazily and reused for the lifetime of the browser module. Browser and server Supabase requests have a 15-second timeout; auth forms show retryable errors and callback failures return users to sign-in. The Next.js proxy performs its auth lookup only for protected dashboard paths, not public pages or static assets. The OAuth callback creates its server client per request because its cookie adapter is request-specific. Do not share server clients across users or disable session persistence: this app relies on cookie-backed sessions to complete sign-in.

There are currently no application table reads, .select() calls, filters, ordering chains, or list endpoints to paginate. The profiles.id column is a primary key, so PostgreSQL already creates its lookup index. No additional query index or pagination migration is justified by the current code. Reassess selected columns, page sizes, and indexes when adding data-backed lists or filters.

Code changes alone cannot guarantee 10,000 concurrent users. Validate Netlify concurrency/function limits, Supabase Auth and API rate limits, database connection limits, and the deployed app with a representative load test before setting that target.

You can start editing the page by modifying app/page.js. The page auto-updates as you edit the file.

This project uses next/font to automatically optimize and load Geist, a new font family for Vercel.

Learn More

To learn more about Next.js, take a look at the following resources:

• Next.js Documentation - learn about Next.js features and API.
• Learn Next.js - an interactive Next.js tutorial.

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Netlify

Configure NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY in the Netlify dashboard environment variables before deploying. The existing client also supports NEXT_PUBLIC_SUPABASE_ANON_KEY as a legacy alternative. Store actual values in the dashboard, not in tracked files; use .env.local only for local development. Only the placeholder .env.example is tracked.

Next.js embeds NEXT_PUBLIC_ values into browser bundles at build time, even when they are configured only in the dashboard. The Supabase project URL and publishable/anon keys are intentionally public client configuration, not privileged credentials. netlify.toml excludes only these three variable names from Netlify's environment-value secrets scan so their expected presence in build output does not block deployment. Secrets scanning remains enabled for all other variables and files; no paths are excluded.

Never put a Supabase secret or service-role key into any NEXT_PUBLIC_ variable or add it to the exclusions. Keep Row Level Security enabled with appropriate policies for client-accessible tables. If a genuine private credential was exposed, revoke or rotate it and remove it from tracked files and history.

If a deploy still fails, inspect the scanner's reported variable names and file paths earlier in the deploy log. The provided log excerpt does not include those findings. Confirm that the resolved SECRETS_SCAN_OMIT_KEYS contains the three names in netlify.toml, and review any context-specific configuration overrides. Do not disable scanning or exclude entire build directories to suppress unrelated findings.

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.

Check out our Next.js deployment documentation for more details.