NextBase Starter: a Next.js 16 and Supabase boilerplate with RLS already done

The problem it names is auth and RLS breaking quietly

The README makes its case as a list of failures that every SaaS team hits twice. A simple Supabase auth integration that quietly breaks SSR cookies after a refresh, then again after a deploy. An RLS policy that looked right in review and silently leaked a row in production. A server-action layer that was supposed to be type-safe but ended up as three subtly different patterns across the codebase. A monorepo that started clean and devolved into a tangle of relative imports and untyped envs. And a we'll add caching later that turns into a revalidatePath archaeology dig six months in. That framing is the useful part of the project, because it tells you what you are buying. You are not buying a design system, you are buying the decisions that have already failed in production somewhere else, so that they do not have to fail in yours. The audience is explicit too: SaaS teams building on Next.js 16 and Supabase who want an opinionated and tested starting point.

Auth clients for every render boundary, with cookies that survive

The authentication layer uses @supabase/ssr clients for browser, server components, server actions and middleware, and the claim is that they are wired so cookies survive every render boundary in Next.js 16. That is the specific failure the README names first, so it is the specific thing to verify. On top of the clients there is sign-in by email and password, passwordless magic link, and OAuth with Google, GitHub and Twitter and more to add. The middleware is described as hardened, with a single source of truth for protected routes such as /dashboard, /private-item and /private-items, using path-to-regexp matching and a supabase.auth.getUser() re-verification on every request. The flows implemented are sign-up, sign-in, sign-out, email confirmation, forgot-password, update-password and OAuth callback and code-error pages, all written as Server Actions and tested. The detail that matters for review is that re-verification happens on every request rather than trusting a token read from a cookie without a round trip.

Row level security is a starting assumption, not a later task

The database section starts from the position that every user-owned table ships with SELECT, INSERT, UPDATE and DELETE policies keyed off auth.uid(). Migrations are real timestamped SQL files under apps/database/supabase/migrations rather than a hand-edited single file, which means the schema history is reviewable and the policies are versioned alongside it. Type generation is wired to two scripts, pnpm gen-types for a remote database and pnpm gen-types-local for a local one, regenerating database.types.ts so queries are end to end typed. There is a pgTAP-ready test scaffold under apps/database/supabase/tests for asserting policies, triggers and constraints, and updated_at triggers are standardised through a single public.set_updated_at() function applied per table rather than duplicated. The open question the README does not answer is the tenancy model. The project description mentions multi-tenancy only as a premium kit, so the open source starter gives you the mechanism for row level security without specifying how your rows are scoped to an organisation.

Server actions split by trust boundary, not by feature

All mutating endpoints go through next-safe-action and are Zod-validated and typed end to end, with two pre-built clients. The actionClient is the base with development-time performance and payload logging middleware, and the authActionClient extends it and injects ctx.userId for the current user while refusing unauthenticated calls. The data access layer is partitioned by trust boundary into src/data/anon for anonymous public reads, src/data/auth for the authentication flows, src/data/user for authenticated user data under RLS, and src/rsc-data for React Server Component fetchers. This is the part that answers the README's complaint about three subtly different patterns, because the partition is enforced by directory rather than by convention. There is also optional effect-ts integration with composable Effect-based query helpers and typed Supabase error mapping under src/utils/effect-*, positioned as something for teams that want railway-oriented data flow without it leaking into every file.

Cache Components and a written guide to using them

The caching section uses Next.js 16 Cache Components with cacheComponents: true, which the README describes as static by default rendering with surgical use cache boundaries, and it points at a written guide, docs/NEXTJS_CACHE_COMPONENTS.md, explaining exactly when and how to use each primitive. Shipping the guide matters more than the feature here, because use cache is exactly the kind of primitive that is easy to adopt wrongly and hard to debug later. Data fetching is described as Suspense-first, through createSuspenseResource and TanStack Query, with clean loading boundaries and no waterfall fetches, and the dev server is Turbopack for fast hot reload on real component trees. Remote image patterns for next/image are preconfigured for Supabase Storage and Unsplash. The README describes the caching story as the cure for the revalidatePath archaeology dig, and the honest reading is that it removes one failure mode, the six-months-later forgetting, and introduces a different one, which is why the guide exists.

A monorepo with a local Supabase stack you can start and stop

The repository is a Turborepo monorepo with apps/* and packages/* workspaces and pnpm, running pipelined build, lint, test, typecheck, gen-types and test:e2e tasks. The root scripts make the layout visible, and they are worth reading as a map of the project:

    "dev": "turbo run dev --parallel",
    "build": "turbo run build",
    "lint": "turbo run lint",
    "test": "turbo run test",
    "typecheck": "turbo run typecheck",
    "gen-types": "turbo run gen-types --filter=database",
    "database#start": "turbo run database#start",
    "test:e2e": "turbo run test:e2e --filter=web",

The local database lifecycle is a first-class part of that, with pnpm database#start, database#stop and database#status driving a local Supabase stack so a developer is not pointing at a shared remote database while testing RLS. The engines field requires Node 24 or newer and pnpm 11 or newer, with pnpm 11.1.2 pinned as the package manager, and there is a.node-version file and an.nvmrc in the repository root. Release handling is automated through Changesets: every shippable change carries a changeset, an automated Version Packages pull request rolls them into one bumped release, syncs the apps/web versions through a script, and cuts a GitHub release.

The version number is stale, and that is the main warning sign

Here is the fact that should shape your reading of everything else. The latest releases listed are v2.2.0 from 2023-11-25, v2.1.0 from 2023-09-21 and v2.0.1 from 2023-07-31, and the package.json still declares version 2.2.0 with the private flag set. The last push was on 2026-10-02, so the code is being worked on. But the code now targets Next.js 16, Node 24, pnpm 11, Tailwind CSS 4 through @tailwindcss/postcss, oxlint and oxfmt instead of ESLint and Prettier, Turborepo, and Changesets. That is a rewrite of the entire stack under an unchanged version number, and the release history in the repository does not describe the code you would clone today. The practical consequence is that you cannot use the tags to judge freshness, and a version comparison against 2.2.0 from 2023 tells you nothing about the Next.js 16 implementation. The CHANGELOG.md is the file to read, and so is TROUBLESHOOTING.md at the repository root.

An open baseline with a paid tier above it

The licence is MIT with the LICENSE file at the root, and the README calls the project a free and MIT-licensed starter that is ready to clone, with the open-source baseline of the NextBase family and a homepage at open-source-template.usenextbase.com. The commercial structure is stated in a callout near the top. Stripe billing, teams and orgs, RBAC admin, transactional emails, multi-tenancy and AI starter kits are described as premium NextBase kits built on the same patterns, available at usenextbase.com. That is a fair way to organise an open source project, and it is also a signal about where the gaps are. The features listed as free cover auth, RLS, migrations, server actions, caching, UI and tooling. The features listed as paid cover tenancy, billing, roles beyond the base auth client and email. If your product needs multi-tenancy, you are looking at the boundary of what the free starter covers, and the README does not document how the two halves fit together. The UI baseline is generous either way: shadcn/ui with more than 40 Radix components, Tailwind 4, Framer Motion, Embla Carousel, cmdk, input-otp, Lucide icons, date-fns and React Hot Toast, plus React Bits animated components installed through the shadcn registry.

Editorial conclusion

Adopt NextBase Starter if you are starting a SaaS product on Next.js 16 with Supabase and you would rather inherit working auth cookies, row level security policies and typed server actions than write them yourself. Do not adopt it expecting a maintained release line, because the version in package.json is still 2.2.0 from 2023 while the code targets Next.js 16, Node 24 and pnpm 11. Before you commit, read TROUBLESHOOTING.md and the docs folder, copy the .env.local.example and .env.development.local.example files and fill them in, and verify the RLS policies in apps/database/supabase/migrations against your own tenant model rather than assuming they fit.

Frequently asked questions

Official sources

1. imbhargav5/nextbase-nextjs-supabase-starter on GitHub
2. License: MIT
3. Project website
4. README
5. Releases