For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /docs/web/github-sign-in.md (or send Accept: text/markdown).
Add GitHub sign-in
Create a GitHub OAuth App per environment and wire Continue with GitHub into the app.
Beginner walkthrough
Prerequisites: the web app running locally and a migrated database for real accounts. You need a GitHub account — the same one that owns the repository is fine. Free, about 5 minutes per environment.
Quick terms: a GitHub OAuth App is the registration that lets GitHub sign users in for you. Unlike most providers, one OAuth App allows exactly one Authorization callback URL — so local (http://localhost:3000/…) and production (https://yourdomain.com/…) each need their own app. Reusing one app and editing its callback back and forth will break one side every time.
1. Create a local OAuth App under your account's Developer settings. 2. Copy its Client ID and generate a Client Secret. 3. Set the three environment values and restart. 4. Repeat once with your real domain before going live.
Create the local OAuth App
1. Open github.com and sign in. Click your profile photo in the top-right corner → Settings.
2. Scroll to the bottom of the left sidebar and open Developer settings → OAuth Apps → New OAuth App.
3. Application name: something like supastack local — users see this name on GitHub's authorization page. Homepage URL: http://localhost:3000. Authorization callback URL: http://localhost:3000/api/auth/callback/github. Click Register application.
4. On the app's page copy the Client ID, click Generate a new client secret, and copy the secret immediately — GitHub shows it only once, though you can always generate another.
Create the production OAuth App
Repeat the same New OAuth App steps with your product's name, Homepage URL https://yourdomain.com, and Authorization callback URL https://yourdomain.com/api/auth/callback/github.
Keep each app's credentials in its own environment: the local app's pair lives in apps/web/.env.local, the production app's pair lives in your host's secret store. The local secret must never reach production config and vice versa.
Add the values to the app
Set the three lines below in apps/web/.env.local using the local app's credentials. AUTH_GITHUB_ENABLED=true turns the button on; the pair identifies the OAuth App.
The client secret stays server-only — never in NEXT_PUBLIC_/EXPO_PUBLIC_ variables and never committed. Restart the dev server after editing.
Do not reuse any GITHUB_APP_* values you may see elsewhere — those belong to an unrelated GitHub App integration, not to user sign-in. The kit's docs/github-auth-setup.md walks this whole flow end to end if you want a second reference.
# apps/web/.env.local — from the LOCAL OAuth App
AUTH_GITHUB_ENABLED=true
GITHUB_CLIENT_ID=your-oauth-app-client-id
GITHUB_CLIENT_SECRET=your-oauth-app-secretVerify and troubleshoot
Open http://localhost:3000/auth and click the GitHub button. Authorize the app on github.com and confirm you return signed in.
Until AUTH_GITHUB_ENABLED=true is set, the GitHub option on /auth remains visible but disabled — check the env file names, then restart. Setting the flag without both GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET fails startup and names the missing variable.
A callback mismatch is the usual failure: the app's Authorization callback URL must equal {APP_URL}/api/auth/callback/github exactly — protocol, host, port, and path. A redirect_uri error after deploying usually means the request hit the local app's credentials while APP_URL says production, or the reverse.
Restart the dev server after every env edit; values are read at startup only.
If you want to continue setup, read Add Apple sign-in.