Headless CMS
Term 44 of 68 in the ERPStack technical glossary
What is Headless CMS?
A Headless CMS is a backend-only content management system built from the ground up as a content repository that makes content accessible via an API for display on any device.
Headless CMS at a glance
- Split
- Content stored once, delivered to N front ends over 1 API instead of 1 coupled template layer
- Reference stack
- Payload CMS on PostgreSQL 18, consumed by a Next.js 16 and React 19 front end
- Caching
- Incremental Static Regeneration so a content edit invalidates 1 route, not the whole site
- Trade-off
- You own the presentation layer — 0 themes included, full control of markup and performance
- Built with
- Payload CMS on PostgreSQL 18, rendered by Next.js 16 and React 19 with Tailwind CSS 4, cached at the edge on Vercel, content models reviewed in GitHub Actions
- Numbers that matter
- 1 content model, N channels; publishing invalidates 2 or 3 routes, not 10,000; 0 bundled themes; 2 delivery APIs, REST and GraphQL
- Compare with
- Coupled platforms, and other headless options against Payload CMS
- Commonly paired with
- Next.js 16, React 19, Tailwind CSS 4, a CDN, Vercel hosting and a PostgreSQL 18 database behind the CMS
- Where it is chosen
- retail and media teams publishing to a web front end and an app from 1 content model, with Storybook holding the component contract between them.
How Headless CMS works in production
The ERPStack approach to Headless CMS
We connect decoupled Next.js websites to Headless CMS engines, keeping frontend load times low and page cache updates instant via webhooks.
Frequently asked questions about Headless CMS
What makes a CMS Headless?
The absence of a bundled presentation layer. A Headless system stores structured content and exposes it over an API, leaving rendering entirely to whatever consumes it. That is what allows 1 content model to serve a marketing site, a mobile app and an in-product help centre simultaneously. A traditional CMS couples content to templates, so a second channel means duplicating the content or fighting the theme system.
What do you give up by going Headless?
Turnkey theming and, if you are careless, editor preview. A Headless setup ships 0 templates, so someone has to build the front end. Editors also lose the WYSIWYG-on-the-real-page experience unless preview is deliberately implemented. Both are solvable, but a team that wanted a website next week and got an API is entitled to feel the trade was not explained.
How does content stay fast without full rebuilds?
By invalidating precisely. A Headless architecture on Next.js 16 uses Incremental Static Regeneration and cache tags so publishing 1 article regenerates that route and its index, rather than triggering a full site build. The result is static-file performance for readers with near-immediate updates for editors — the combination that pure static generation and pure server rendering each fail to deliver alone.
Why does ERPStack use Payload CMS for this?
Because it is Headless, self-hosted and stores content in the same PostgreSQL 18 database as the rest of the application. That removes a network hop and a second source of truth, and it means content is covered by the same backup, access-control and audit arrangements as business data. Configuration lives in TypeScript 5.9 in your repository, so content models are reviewed like code.