shadcn CMS vs Payload: Honest Admin UX Comparison

Two CMS options keep coming up when a developer wants shadcn/ui and a working admin: UnfoldCMS and Payload. They share a target audience and almost nothing else. UnfoldCMS is a Laravel monolith where the entire admin runs on shadcn/ui. Payload is a Node.js headless CMS whose admin runs on Payload's own React UI library.

I've shipped production work on both. This is the honest side-by-side — not "X kills Y," but where each one fits, and where I've watched teams pick the wrong one and pay for it three months later.

Disclosure: I work on UnfoldCMS. I'll mark our own listing clearly and try to keep the verdicts fair. Payload is a good product. The headline question isn't "which is better" — it's "headless or monolith for this project?"

TL;DR — UnfoldCMS vs Payload at a glance

UnfoldCMS is a monolith — Laravel + React + Inertia, admin built entirely on shadcn/ui (51 components, 205 admin pages). Payload is a headless CMS — Node.js backend, your separate Next.js / Astro / SvelteKit front-end consumes its API. Pick UnfoldCMS when you want one deployable thing and the admin should match your shadcn front-end. Pick Payload when you need a hard split between content service and front-end app, or when Node.js is non-negotiable on your stack.

Architecture — the decision before the decision

Before you compare features, decide whether you want a monolith or a headless split. Most "Payload vs X" arguments are really monolith-vs-headless arguments in disguise.

Monolith (UnfoldCMS): one codebase, one deploy, the admin and the public site share the same templates. You add a feature once and it's live everywhere. Easiest to host — a single PHP-FPM + MySQL on a $5 VPS works. The trade-off: the front-end is rendered by Laravel via Inertia. If you want a separate Next.js app on Vercel calling a content API, that's not the shape.

Headless (Payload): the CMS is one service, your front-end is another. Editors log into Payload's admin at one domain; your Next.js app at another domain calls Payload's API to fetch posts. Maximum flexibility — swap your front-end framework without touching content. Trade-off: two deploys, two domains, two hosting bills, two sets of monitoring.

If you've never wished for that split, you don't need it. If you've fought monolith limits before — separate teams on separate stacks, multiple front-ends consuming the same content — headless earns its complexity.

The shadcn/ui question

This is where most "I want shadcn" buyers get surprised.

UnfoldCMS admin = shadcn/ui. Every screen — the post editor, sidebar, command palette, data tables, dropdowns, sheets, toasts — renders via shadcn components. You can npx shadcn add a new component into the admin without fighting a foreign design system. Fork the admin the way you'd fork a shadcn component: copy the file, edit it, ship it.

Payload admin = Payload UI. It's a thoughtful, polished React UI library — but it's not shadcn. If you want the admin to visually match a shadcn front-end, you're rebuilding chunks of the admin yourself. It's not a config flag. Payload's docs are honest about this; the marketing of "Payload + shadcn" almost always refers to using shadcn on your separate front-end app, not inside Payload's admin.

So if the question is "I want a CMS where the admin itself looks like my shadcn site," UnfoldCMS is the only option in this comparison. If "shadcn on the public site, Payload UI in the admin is fine," Payload works.

For the long version, see The CMS Built on shadcn/ui: Why It Matters and Why Your shadcn/ui Admin Template Should Be a Full CMS.

Stack and runtime

Stack matters because it sets your hosting bill, your DevOps surface area, and your hiring pool.

The blunt difference: PHP monolith vs Node service. If your team already runs Node services, Payload slots in. If your team runs PHP (Laravel agencies, indie devs on $5 VPS), UnfoldCMS slots in. Pain Point #3 — Node.js deployment complexity — is the most common reason teams bounce off Payload to a PHP CMS. See Laravel + React + shadcn/ui: The Modern CMS Stack for the full deployment-cost breakdown.

Hosting and deployment

This is the unsexy section that decides whether a project ships on time.

UnfoldCMS runs anywhere PHP runs: shared cPanel hosting, a $5 DigitalOcean droplet, a Hetzner CX11, your own server. There's no Docker requirement, no Node services to keep alive, no serverless cold starts. One database, one PHP process, one cron entry. Deploy = git pull && composer install && php artisan migrate. That's the whole story.

Payload is a Node service. The realistic deploy options are: Docker on a Node-friendly host, Vercel/Railway/Fly serverless functions, or a managed Payload Cloud tier. None are hard, but all assume your team is comfortable with the Node/Docker workflow. Add MongoDB Atlas (or self-hosted Mongo) and that's a second service to monitor. Add a separate Next.js front-end and you're up to three.

If "spin up a $5 VPS and ship" is your operating mode, UnfoldCMS is the lower-friction option. If "Vercel for everything" is yours, Payload pairs cleanly with a Next.js front-end on the same dashboard.

Pricing

The pricing models are very different.

UnfoldCMS — one-time license per tier. You pay once, host yourself, no monthly bill. The Core tier is free; Pro and Agency unlock additional features. There's no managed cloud, so hosting is your own cost — typically $5-20/mo for a small project.

Payload — open source (MIT). Free to self-host. Payload Cloud is a separate paid hosted tier. The trade-off for "free": you pay in DevOps time when self-hosting. Three or four developer-hours fixing a Node deployment costs more than a one-time CMS license at most rates.

Neither pricing model is better in the abstract. Indie devs and agencies on tight margins tend to prefer one-time. Teams with serious DevOps budgets and Node infrastructure already in place tend to prefer open-source + self-host.

When Payload is the better fit

I'm including this section because the rest of the post leans toward UnfoldCMS by virtue of disclosure, but Payload genuinely wins for some shapes of project:

• Headless-first from day one — the public front-end and the CMS need to be separate services for organisational or scaling reasons.
• Multiple front-ends consuming the same content — a Next.js site plus a React Native app plus a third-party integration. Payload's API-first shape is genuinely good here.
• Node-only stack — your team is Node, your hosting is Node, your CI is Node. Adding PHP would be the friction, not removing it.
• Open-source preferred — you want MIT license, source on GitHub, ability to fork the entire CMS. Payload is OSS; UnfoldCMS is source-available with a paid commercial license.

These are real use cases. Pick Payload for them.

When UnfoldCMS is the better fit

Conversely, UnfoldCMS wins when:

• You want the admin itself to be shadcn/ui — not just the public site.
• One-deploy, one-database simplicity matters more than API flexibility — most content sites, marketing sites, agency client builds.
• Hosting cost matters — $5/mo PHP host vs $20+/mo Node + DB + front-end.
• Laravel already in your stack — you don't want to add Node services next to it.
• One-time licensing fits your budget better than "free + DevOps time."

Most ICP-A devs evaluating "shadcn CMS" land in this bucket. The headless complexity Payload optimises for isn't a requirement they actually have.

People Also Ask

Is Payload built on shadcn/ui?

No. Payload's admin runs on its own React UI library. You can use shadcn on your separate front-end app that calls Payload's API, but the admin itself is Payload UI.

Can I use UnfoldCMS as a headless CMS?

Partly. UnfoldCMS ships a public read-only JSON API (/api/blog/posts, /api/v1/*) for fetching content from a separate front-end. The admin is still a Laravel monolith. If you need full headless with both read and write APIs and a hard service split, Payload is the better fit.

Which is faster to set up?

UnfoldCMS — install PHP, run migrations, you're live. Payload's install is also fast, but you also need to set up the front-end app, the database (Mongo or Postgres), and the hosting for both. Expect 10 minutes for UnfoldCMS vs an hour or two for a full Payload + Next.js stack.

Is Payload more flexible than UnfoldCMS?

For "swap the front-end framework without touching content" — yes. For "fork the admin to look exactly the way I want" — no, that's where shadcn-everywhere wins. The flexibility is on different axes.

Which scales better?

Both scale well for normal content-site loads (hundreds of thousands of monthly views). At very large scale (millions of API requests / day), Payload's headless shape and PostgreSQL or Mongo backing let you scale the content service separately from the front-end. UnfoldCMS scales fine for the workloads most agencies and SaaS marketing sites ever hit.

Bottom line

If you want the admin built on shadcn/ui — UnfoldCMS. If you want a headless CMS with shadcn living only on your front-end — Payload. Both are good products serving different jobs.

Try the UnfoldCMS demo if you want to see the shadcn admin in production. See pricing for the one-time tiers. For more on the shadcn/ui case, the cornerstone post walks through the 51-components-205-pages breakdown.

Sources and methodology

• UnfoldCMS counts — find cms/resources/js/components/ui -name "*.tsx" \| wc -l = 51; find cms/resources/js/pages/admin -name "*.tsx" \| wc -l = 205. Verified at write time.
• Payload admin UI — confirmed via Payload docs.
• Payload database support — Mongo + Postgres confirmed via Payload database docs.
• UnfoldCMS public API — GET /api/blog/posts and /api/v1/* confirmed via cms/routes/web.php and cms/routes/api.php in the source tree.
• Production tests run between April and June 2026 on current stable releases.