> TL;DR — I run four different domains off one Next.js codebase: a marketing site at pagestrike.com, an authenticated app at app.pagestrike.com, a public publishing domain at pagestrike.app, and customer-owned domains. The trick isn't deploying four apps — it's a single proxy.ts that reads the host and rewrites/redirects/passes-through per-request. This post walks through why I chose this shape, the parts I got wrong, and the cookie-domain trick that makes it all stick.
Stack: Next.js 16 App Router, Supabase, Vercel, one proxy.ts file (~370 lines).
This is the second post in my build-in-public series on PageStrike. Last week I wrote about the 6-CTA architecture — modeling conversion intent as a discriminated union so one launch could be a checkout, a COD form, or a calendar booking. This post is about a different primitive: modeling host as routing context so one codebase can serve four very different audiences.
Why four domains, not one
Most SaaS apps live at one domain — say myapp.com with /dashboard under it. That works until you grow into edge cases that don't fit:
