Reference
Configure
What this page is: the post-setup configuration reference. What to do here: walk the checklist after the setup wizard finishes provisioning your deployment. Why it matters: the wizard creates the infrastructure; this page covers everything that needs setting on top — vendor identity, DNS, SMTP, auth allowlist — before real users see the deployment.
Environment variables
All of these are set automatically by the setup wizard for newly provisioned deployments. Re-visit them when migrating an existing database, swapping a provider, or rotating a key.
Vendor identity (white-label)
Every NEXT_PUBLIC_VENDOR_* var controls what your deployment looks like to end users. Set these per-deployment — the default state is vendor-neutral so the template never leaks identity across customers.
| NEXT_PUBLIC_VENDOR_NAME | Your company name in headers, footers, emails |
| NEXT_PUBLIC_VENDOR_EMAIL | Contact email shown in footer / support links |
| NEXT_PUBLIC_VENDOR_PHONE | Contact phone (optional, blank to omit) |
| NEXT_PUBLIC_VENDOR_CALENDLY | Calendly handle for 'Book a call' (optional) |
| NEXT_PUBLIC_VENDOR_LOGO_URL | URL to your logo (PNG or SVG, transparent background) |
Supabase
The setup wizard provisions a new Supabase project per deployment and writes these into Vercel automatically. You only edit them if you're migrating an existing database.
| NEXT_PUBLIC_SUPABASE_URL | Provisioned Supabase project URL |
| NEXT_PUBLIC_SUPABASE_ANON_KEY | Public anon key — safe for client |
| SUPABASE_SERVICE_ROLE_KEY | Server-only — bypasses RLS, never expose to client |
AI providers
BYOK (bring your own key). The orchestration layer passes these to each provisioned child app, so all LLM usage is billed to the deployment owner's account, not Corporate AI Solutions.
| ANTHROPIC_API_KEY | Claude (primary — used for coaching, scoring) |
| OPENAI_API_KEY | Fallback + optional voice transcription |
| ELEVENLABS_API_KEY | Voice agent — required if voice coaching is enabled |
Transactional and auth emails. Resend is the supported provider. Set the sender to a verified subdomain so deliverability stays clean.
| RESEND_API_KEY | Resend API key |
| RESEND_FROM_EMAIL | Verified sender (e.g. noreply@updates.yourdomain.com) |
Setup-only (server-side)
These protect the /api/setup/* infrastructure routes. They never appear in the client bundle. Rotate the setup secret after the deployment is live.
| SETUP_SECRET | Required header for /api/setup/* — rotate post-deploy |
| GITHUB_TOKEN | Used to create the child repo from template |
| VERCEL_TOKEN | Used to create the child Vercel project + initial deploy |
Post-setup checklist
Six items, ordered. Skipping any of them strands real users on the deployment.
- 1
Add a custom domain
Vercel dashboard → your project → Settings → Domains. Point your DNS at the Vercel nameservers, or add an A record to 76.76.21.21 and a CNAME for www. Domain verification usually completes inside 15 minutes.
- 2
Update Supabase Auth allowed redirect URLs
Supabase dashboard → Authentication → URL Configuration. Add your production domain + /auth/callback. Without this, magic-link logins on the custom domain will 401 silently.
- 3
Wire Resend custom SMTP into Supabase Auth
Supabase dashboard → Authentication → SMTP Settings. Use the Resend SMTP credentials so auth emails route through your verified sender domain. The default Supabase email service is heavily rate-limited (3-4 emails/hour) — production deployments must move off it.
- 4
Brand the Supabase email templates
Supabase dashboard → Authentication → Email Templates. Replace the default 'Follow this link' templates with your branded copy. The 5 templates to update: Confirm signup, Invite, Magic Link, Recovery, Email Change.
- 5
Test the four critical auth paths
Before you let real users in, run signup + login + forgot-password + magic-link end-to-end on the production domain. If any of the four breaks, the entire deployment is non-functional — auth is upstream of every other feature.
- 6
Rotate SETUP_SECRET
The secret that protected /api/setup/* during initial provisioning should be regenerated and never re-used. Setup routes don't get called again after the initial deploy.
Something not behaving?
The support page covers the most common post-setup issues.
Go to Support