Blog

How to choose a headless CMS for Next.js when you also need end-user auth

Raşit ApalakJuly 16, 2026

If you search for a headless CMS for Next.js in 2026, you will find the same comparison posts. They weigh Sanity, Payload, Contentful, and Storyblok on schema modeling, pricing, and how fast you get to a rendered page. That is useful, but it skips a question many product teams hit on week two: who handles end-user auth?

A marketing site might only need CMS editors. A SaaS app, membership site, or customer portal needs both: structured content and signup, login, and sessions for your users. This post adds that lens to the Next.js CMS decision. It is not a ranking of every tool on the market. It is a practical way to narrow the field before you commit.

Start with three questions

Before you compare feature tables, answer these:

1. Who edits content day to day?

If developers own the schema and most entries, a code-first CMS that lives in your repo can feel natural. Payload is a common pick here because it installs inside your Next.js app and shares your TypeScript types.

If marketers or clients edit daily, you may want a hosted dashboard with a visual editor. Sanity, Contentful, and Storyblok all target that workflow. The right answer depends on who will actually open the CMS every week, not who builds the first version.

2. Who runs the infrastructure?

Self-hosted options (Payload, Strapi, and similar) give you control. You own the database, deployments, and security patches. That is powerful, but it is also ongoing work: migrations, backups, auth hardening, and keeping the admin online.

Hosted SaaS CMS products remove that ops layer. You trade some control for speed. For solo devs and small teams, that trade is often worth it early on.

3. Where does end-user auth live?

This is the question most roundups skip.

Many Next.js apps are not just blogs. They need:

A signup and login flow for customers or members
Session refresh and logout
Sometimes social login or email verification
A way to gate content or features behind a logged-in user

A headless CMS handles editor access. It does not automatically solve end-user auth. Teams usually add Clerk, Auth0, Supabase Auth, or a custom JWT layer on top. That means a second product to configure, document, secure, and bill for.

If your app needs logged-in users, ask explicitly: is auth part of the CMS platform, or is it a separate integration you own forever?

The two common shapes

Most Next.js + CMS stacks look like one of these:

Shape A: CMS + separate auth vendor

You pick a headless CMS for content. You pick an auth provider for users. Your Next.js app wires both together.

Pros: Each tool is mature in its lane. You can swap auth vendors without moving content.

Cons: Two dashboards, two docs, two billing lines. Your Route Handlers or server actions bridge tokens between systems. Every new hire (and every AI coding session) needs context on both stacks.

This shape is common and it works. It is just more glue than teams expect when they only needed "a CMS for Next.js."

Shape B: CMS with project auth built in

A smaller set of platforms ship end-user auth in the same product as the content API. NomaCMS is one example: structured content over REST and @nomacms/js-sdk, plus project auth for signup, login, refresh, logout, profile, sessions, email verification, and user-owned API keys. Social login is available via OIDC id_token (Google today).

Pros: One platform for content and logged-in users. One project ID, one SDK, one set of docs. Auth is isolated per project, so the same email in two projects is two separate accounts.

Cons: You are betting on one vendor for two core concerns. If you need deep custom auth logic that goes far beyond standard flows, you may still want a dedicated auth product.

Shape B is not a replacement for Payload-in-repo or Sanity's content lake. It is a different tradeoff: less integration work, more reliance on a hosted platform.

When NomaCMS fits a Next.js project

NomaCMS is worth a look when most of these are true:

You are building on Next.js (App Router or Route Handlers)
You need both CMS content and end-user auth, not just editor accounts
You want a hosted backend so you can ship without running Postgres and an admin server
Your team is small (solo dev, indie builder, or early-stage product team)
You are fine keeping CMS credentials on the server (no NEXT_PUBLIC_ API keys in the browser)

It is probably not the right fit if you need the CMS inside your repo as TypeScript schema files, or if you require hundreds of editorial seats and complex approval workflows on day one.

How it looks in Next.js

The integration pattern is straightforward and matches how most headless CMS + Next.js guides recommend working:

Content on the server. Create a helper with createClient from @nomacms/js-sdk. Call noma.content.list() and noma.content.get() from Server Components or Route Handlers. Keep NOMA_PROJECT_ID and NOMA_API_KEY in server-only env vars.
Auth on the server too. End-user sign-in uses the same SDK with projectUserAuth configured. Store access and refresh tokens in HTTP-only cookies from a Route Handler or server action. Call noma.me() before rendering protected pages.
Refresh content after CMS updates. Use Next.js revalidation (revalidate, revalidatePath, or revalidateTag) when entries change. NomaCMS webhooks can notify your app on publish, update, and delete so you do not need a full rebuild for every edit.

That is the same server-first model as the official Next.js guide. The difference is you do not add a second auth SDK alongside the CMS client.

Here is a minimal content fetch in a Server Component:

// app/posts/page.tsx
import { getNomaCMSServerClient } from "@/lib/nomacms"

export default async function PostsPage() {
  const noma = getNomaCMSServerClient()
  const result = await noma.content.list("posts", {
    state: "published",
    paginate: 12,
    sort: "created_at:desc",
  })

  const posts = "data" in result ? result.data : result

  return (
    <ul>
      {posts.map((post) => (
        <li key={post.uuid}>
          <a href={`/posts/${post.uuid}`}>
            {String(post.fields?.title ?? post.uuid)}
          </a>
        </li>
      ))}
    </ul>
  )
}

For auth, keep token exchange in Route Handlers and check the session before rendering member-only routes. Full patterns are in the project auth overview and Auth for Next.js.

A quick decision shortcut

Your situation	Reasonable direction
Developers own content, want CMS in the repo	Payload or similar code-first option
Marketers need visual editing, auth is separate	Sanity, Contentful, or Storyblok + auth vendor
Small team, need content + logged-in users fast	Hosted CMS with project auth (e.g. NomaCMS)
Enterprise governance, many editorial seats	Contentful or similar enterprise CMS + your auth layer

No row is universal. The point is to name the auth decision early, not discover it after you have already chosen a CMS.

What to try before you commit

Whatever direction you lean toward:

Model one real collection (blog posts, docs, or landing page blocks) and fetch it in a Server Component.
Build one auth flow (signup or login) and protect one route.
Publish an entry and confirm your cache or rebuild strategy updates the page.

For NomaCMS, you can do all three on the 7-day free trial without committing to a plan. Start at app.nomacms.com, follow the quickstart, then open the Next.js guide for copy-paste patterns.

If you use Cursor or Claude Code, the MCP server and agent skills can help your editor work with your schema and auth setup while you build the frontend.

Bottom line

Choosing a headless CMS for Next.js is not only about GROQ vs REST or where the admin UI lives. If your product needs logged-in users, ask where auth lives before you pick the CMS.

Teams that want maximum control will keep stitching a CMS and an auth vendor. Teams that want to ship a content-driven app with members or customers can look for platforms where both live in one place.

NomaCMS is built for that second path: headless CMS with auth built in, a typed SDK for Next.js, and server-first patterns that keep secrets off the client.