AuthTemplate

You're helping me take my copy of the AuthTemplate repo (Next.js + Supabase auth starter) from a fresh clone to a deployed app. Work through these in order. Before moving from one numbered section to the next, check that section off in SETUP_CHECKLIST.md (edit the actual checkbox, don't just tell me it's done) and check in with me — do this at every single section, not just some of them, it's the same step as moving on, not a separate thing to remember. Rule for the whole thing: never ask me to paste an API key, access token, or password directly into this chat. When a step needs a real secret, either have me paste it straight into a dashboard myself, or run the tool's own secure prompt (`gh secret set`, `vercel env add`, etc.) — those ask for the value directly in the terminal, hidden, without it ever passing through you. Another rule for the whole thing: never run `git commit` or `git push` on your own. Stage changes and show me what's about to be committed (`git status` / `git diff`), then wait for me to say go ahead — every time, not just once at the start. This applies to SETUP_CHECKLIST.md same as any other file. Whenever you're about to share more than one link with me in a message, put them in a small markdown table (columns: Link, What it's for) instead of a bare list — easier to scan. Before doing anything else, read SETUP_CHECKLIST.md at the repo root — it ships with every checkbox unchecked and mirrors every step below. If any boxes are already checked, resume from the first unchecked one instead of starting over or re-asking me things it already answered (check its Notes section too — that's where earlier facts like my project ref or deployed URL should already be). Whenever you check something off, also add anything later steps will need to the Notes section, and stage that file's changes along with whatever else you're about to commit at each step, same as any other file — it's meant to be real project history, not scratch state. ## 1. Get the code Check whether the current directory is already this repo (look for "auth-template" in package.json, or check `git remote -v`). If not, ask me for the repo URL — the copy I created by clicking "Use this template" on https://github.com/rl3020/AuthTemplate, not the template itself — then clone it and cd in. ## 2. Local setup 1. Run `npm install`. 2. Confirm Docker is installed and running (`docker info`). If not, tell me to install/start Docker Desktop and wait for me. 3. Run `npx supabase start` and read the local API URL and Publishable key it prints. 4. Copy `.env.example` to `.env.local`, fill in NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY with those local values, and leave NEXT_PUBLIC_SITE_URL as http://localhost:3000. 5. Run `npm run dev` and confirm http://localhost:3000 loads. Ask me to confirm it looks right before continuing. 6. Ask me for a short project name (e.g. "my-app"), then rename it from the template's own identity to mine, now rather than at final cleanup: in supabase/config.toml, change the top-level `project_id` on line 5 from "auth-template" to that name (purely a local dev label — it's why `supabase start` printed "auth-template" before this, not a bug, just confusing to leave). Then update the title and description in src/app/layout.tsx's metadata to match. Leave the `[remotes.production]` block further down in config.toml alone for now — that's a separate placeholder (the template author's own Supabase ref and domain) that only matters if I pick the Production path in step 8. ## 3. Create a hosted Supabase project This part is manual on my end — walk me through it, don't try to do it yourself: - Tell me to go to https://supabase.com/dashboard, click "New project", pick an org/region, and set a database password when prompted — tell me to write that password down myself, Supabase won't show it again, and not to paste it here. - Ask me for the Project URL and Publishable key (Project Settings → API) once it finishes provisioning — those aren't secret, safe to paste here. - Ask me for the project ref too (the string in the dashboard URL, supabase.com/dashboard/project/<ref>, also under Project Settings → General) — I'll reuse this in steps 5 and (if I go with Production) later. Not secret, safe to paste here. ## 4. Generate a Supabase access token Manual: tell me to create one at https://supabase.com/dashboard/account/tokens, scoped to this project. This is a real secret — tell me to hold onto it for step 5, not paste it here. ## 5. Add the GitHub repository secrets Three are needed: SUPABASE_ACCESS_TOKEN (from step 4), SUPABASE_PROJECT_REF (from step 3), and SUPABASE_DB_PASSWORD (from step 3). If the `gh` CLI is installed and authenticated against my repo, run `gh secret set SUPABASE_ACCESS_TOKEN --repo <owner>/<repo>` for each one — it prompts for the value directly in the terminal. If `gh` isn't available, tell me to add them manually at my repo → Settings → Secrets and variables → Actions → New repository secret, and wait for me to confirm. ## 6. First migrations supabase/migrations/ already has two — nothing to create. One creates the profiles table with RLS policies; the other grants the authenticated role actual table-level access to it (RLS alone doesn't grant that — without it, every fresh hosted project hits "permission denied for table profiles" the moment anything touches it, even though local dev looks completely fine, since supabase start/db reset bootstraps default grants locally that a hosted project doesn't get). Both apply automatically the first time the "Deploy Supabase Migrations" GitHub Actions workflow runs after step 5. Tell me to trigger it: repo's Actions tab → "Deploy Supabase Migrations" → "Run workflow" button (it has a manual trigger built in, no new commit needed). This workflow only handles migrations — auth/email config is a separate "Deploy Supabase Config" workflow, covered in the Production path below. Before moving on, check my repo's Settings → Secrets and variables → Actions → Variables tab for an `SMTP_CONFIGURED` variable — there shouldn't be one yet (some copies of this template were generated from an earlier version that hardcoded "true" straight into .github/workflows/config.yml, which makes that workflow try to push email config on a Free-tier project with no SMTP set up, and Supabase rejects it with a 403). If you find one already set to "true" and I haven't set up SMTP yet, delete it before continuing. If I ever ask you to add a new table later: enable RLS, add policies, *and* explicitly grant select/insert/update/delete on it to authenticated in the same migration — db reset won't catch a missing grant, only a real deploy will, so this is easy to miss. ## 7. Deploy to Vercel Prefer the Vercel CLI so this stays scriptable: 1. `npx vercel login` if I'm not already logged in. 2. `npx vercel link` to connect this project (create a new Vercel project if prompted). 3. `npx vercel env add NEXT_PUBLIC_SUPABASE_URL production` and the same for NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY — each prompts for the value in the terminal; use the hosted values from step 3. Don't bother with NEXT_PUBLIC_SITE_URL — src/lib/site.ts already falls back to Vercel's own VERCEL_PROJECT_PRODUCTION_URL/VERCEL_URL when it's unset, so it's only needed if I'm using a custom domain. 4. `npx vercel --prod` to deploy. 5. Ask if I want a custom domain instead of the default *.vercel.app one — optional, skip if not. If yes: manual on my end, tell me to add it under the Vercel project → Settings → Domains, add the DNS records Vercel shows at my registrar, and wait for it to verify. Once it's set as the Production domain, VERCEL_PROJECT_PRODUCTION_URL picks it up automatically — no code change needed. ## 8. You're done — nothing else to set up There's no SMTP_CONFIGURED repo variable set, and that's correct as-is — don't add one. Confirm with me that: - Sign-up, login, sessions, protected routes, and the settings page all work end to end. - Forgot/reset password does *not* work yet — that's expected on this path, not a bug. It only needs Supabase's free tier and no domain purchase, which is the whole point of this path. There's nothing to touch in supabase/config.toml on this path either — site_url and the redirect-URL list only matter for email flows (confirmation/recovery), and this path doesn't send any, so the localhost defaults there are harmless. Tell me this is revisitable any time — if I ever want working forgot/reset password, the fix is running through the Production version of this prompt, not redoing anything above. ## 9. Clean up Once everything above is confirmed working: delete the entire src/app/(deleteWhenReady)/ folder — onboarding content only (this landing page, the setup guide, an example dashboard), safe to remove since it's an isolated route group and won't break /auth/*, /settings, or src/lib/. (Project naming and layout.tsx's metadata were already handled back in step 2 — nothing left to rename here.) Also delete SETUP_CHECKLIST.md — it was only ever meant to track this setup, not stick around afterward. Then clean up README.md, which still describes this as the template rather than my app: rewrite the title and the "Quickstart" intro section (tech stack / "What's already wired" / "What's not" — that's template-pitch copy, not documentation of my app) to describe what I'm actually building. Also update the "Routing" table — drop the /dashboard row once that example page is deleted, and adjust anything else there that no longer matches reality. Throughout: ask before anything destructive, and stop and tell me plainly if a command fails instead of guessing around it.