Two systems, one truth
A headless CMS means every content change crosses a network boundary and every type is hand-written on the far side.
Publishing tools usually arrive as a second system with its own database, its own login, and an API in the middle. Stacks ships posts, authors, pages, categories, tags, and comments as models in the same application, so an editor screen and a public page are two views over one row.
The work that arrives whether you planned for it or not.
A headless CMS means every content change crosses a network boundary and every type is hand-written on the far side.
Drafts, scheduling, roles, and previews need auth that the public site already has.
A missing sitemap or a broken canonical tag never throws; it just costs traffic for months.
Uploads, variants, and CDN URLs need somewhere to live that works the same locally and in production.
All of it in the same install, typed against the rest of your application.
Posts, pages, authors, categories, tags, and comments ship as first-party models, extendable in app/Models/.
Dashboard content views cover drafts, scheduling, and moderation without a bespoke admin build.
Long-form content lives in content/ as markdown or renders through STX views, with the same layouts as the rest of the site.
RSS, sitemap, canonical, and Open Graph output come from the same content, generated rather than typed.
@stacksjs/storage handles uploads locally and on S3 behind one API, with image variants generated on demand.
The useSearch trait indexes posts as they publish, so site search is a trait flag rather than a service.
Every one of these ships in the same install. Follow one to see what it covers.
Buddy scaffolds, runs, and ships this the same way it does the rest of the app.
Projects of this shape usually grow into one of these.