Supabase Auth boilerplate for Next.js (magic link + Google OAuth)
Auth is the boilerplate decision that ripples the longest. Pick wrong on day one and you spend month six wiring around it. Supabase Auth is the choice across BoilerlyKit because it gives you a Postgres-native identity layer that pairs naturally with Row Level Security, supports the providers buyers actually ask for, and stays out of the way of Next.js Server Components.
What ships in SaaSForge Starter (the minimal version)
SaaSForge Starter is the smallest version: magic-link email sign-in, Google OAuth, a `/dashboard` route gated by session, and a sign-out flow. No workspaces, no roles, no billing, just identity. The intent is that you bring your own database schema and product surface; the auth layer does not assume what you are building.
Sessions are read with the Supabase server client inside Server Components, so protected routes do not need a client-side useEffect to discover the user. This matters for first paint and for code review: the session is a server-side fact, not a client-side guess.
What SaaSForge AI, Core, and Agency add on top
SaaSForge AI keeps the same Supabase Auth wiring and adds per-user data ownership for chat threads, uploads, and credit balances. SaaSForge Core extends it with workspaces, four-role RBAC, invitations via Resend, 2FA, and SAML SSO hooks for enterprise procurement. SaaSForge Agency uses Supabase for the contact-form persistence layer alongside the Directus-driven marketing site.
The common substrate matters for upgrade paths: if you start on Starter and graduate to Core, you are not throwing away the auth flow, you are adding workspace membership on top of the same `auth.users` table.
Magic link vs Google OAuth: when each one wins
Magic link is the default because it removes the password surface entirely. No password storage, no reset flow, no breached-credentials risk on your side. The trade-off is that every sign-in is an email round trip; that is fine for most B2B and B2C SaaS, less fine for products where users sign in many times a day.
Google OAuth is the second provider because that is what business buyers actually use. Adding Microsoft, GitHub, or Apple OAuth in Supabase is a config-and-callback exercise, not a code rewrite. The boilerplate's auth UI is structured so adding a third provider button is one component change.
The Server Component pattern, the one bit that matters
Next.js App Router pushes you to read auth state on the server. The Supabase server client wraps cookies/`next/headers` so a Server Component can call `getUser()` and gate render decisions without flashing unauthenticated content to the user.
Client Components that need the session use a thin context provider hydrated from the server. The pattern is documented in each product's setup docs; the goal is that you never have a route where the auth check lives in a `useEffect` waiting for the client to load.
import { createClient } from "@/lib/supabase/server";
import { redirect } from "next/navigation";
export default async function DashboardPage() {
const supabase = await createClient();
const { data: { user } } = await supabase.auth.getUser();
if (!user) redirect("/sign-in");
return <Dashboard userId={user.id} />;
}