Gatsby CMS Options: Choosing the Content Layer

Gatsby pulls content from a headless CMS at build time through a source plugin, turns it into a GraphQL layer, and generates static pages - which means the CMS choice is really a question about your content model and your publishing rhythm.

The plugin ecosystem here is broad enough that almost any CMS works, so the comparison rarely comes down to technical compatibility. What it comes down to is who edits the content, how structured it needs to be, and how quickly a change has to appear.

Table of contents

• The headless model, briefly
• The categories worth distinguishing
• The build-time constraint, which is the real decision
• Modelling content so it survives
• Where the pieces run
• How this fits the rest of the stack
• FAQ

The headless model, briefly

A traditional CMS owns both the content and the presentation: it stores your pages and renders the HTML. A headless CMS stores structured content and returns it as JSON or GraphQL, leaving presentation entirely to whatever consumes it.

That decoupling is the whole point. The same content can feed a website, a mobile app, and an email system without being duplicated. The frontend team picks its own tools. And the editing interface can be optimised for editors rather than for rendering.

The cost is that you now operate two things instead of one, and content that used to be a page is now a set of fields that somebody has to model deliberately.

The categories worth distinguishing

• Git-based. Content lives as Markdown or MDX in your repository, edited either in files or through a light admin layer over Git. Free, versioned alongside code, reviewable in pull requests, and perfect when the editors are developers. Poor for non-technical editors and for content that needs to be reused across multiple products.
• API-first hosted. Structured content models, a good editing interface, hosted infrastructure, priced per seat or per record. The right answer when non-technical people publish regularly and the content has real structure.
• Self-hosted headless. Open source, running on your infrastructure, with content in a database you control. Full control and full operational responsibility.
• Traditional CMS in headless mode. WordPress or Drupal serving content through their REST or GraphQL APIs. Frequently the correct answer when the organisation already runs one and the editors already know it - migrating a content team is far more expensive than migrating a frontend.

The last one is underrated. A great deal of headless migration effort has been spent replacing an editing interface that was working fine, when only the rendering layer needed to change.

The build-time constraint, which is the real decision

Static generation means content is fetched when the site builds, not when a visitor arrives. Publishing a change requires a build.

For a site publishing a few times a week, this is entirely fine and the trade is excellent: pages are static files served from a CDN, there is no database in the request path, and nothing to attack at runtime.

For a site publishing hourly, or with hundreds of editors, or with content that must appear immediately, build times become the bottleneck. A full rebuild of a large site takes minutes, and an editor fixing a typo does not want to wait for it. The mitigations are incremental builds, on-demand revalidation of specific pages, or rendering the frequently-changing sections client-side against the API.

This is the question to answer before choosing anything: how quickly must a content change be live, and how many pages does a change affect? Everything else follows from the answer, including whether static generation is the right architecture at all.

Modelling content so it survives

The most common regret in this area is not the CMS choice. It is a content model designed around the first design, which then has to be reworked when the design changes.

1. Model the content, not the page. An article has a title, an author, a body, and a publication date. It does not have a hero section with a background colour. Presentation concerns in the content model make the content unusable anywhere else and awkward to redesign.
2. Use references rather than duplication. An author is an entity that articles point at, not a name typed into every article. This becomes obvious the first time someone changes their name.
3. Keep images in the CMS’s media handling where possible, so editors can manage them and transformations happen without a developer.
4. Decide about drafts and previews early. Editors will want to see unpublished content before it goes live, and retrofitting a preview mechanism is considerably more work than including one.

Where the pieces run

A generated site is static files, and static files want a CDN with a build pipeline in front of them - build from the repository on push, and on a webhook from the CMS when content changes.

That webhook is the piece people forget. Without it, publishing means asking a developer to trigger a build, which is a poor experience and undermines the whole arrangement. Most headless CMS products can call a build hook on publish, and wiring it takes minutes.

If the CMS is self-hosted, it also needs somewhere to run: a container, a database, a certificate, and backups of the content, which is now the most valuable thing you own. A managed database behind a self-hosted CMS is not a luxury - losing the content is a different order of problem from losing the site, because the site can be rebuilt from the repository and the content cannot.

How this fits the rest of the stack

A headless setup is usually two bills - the static site and whatever runs the content layer - and it is worth seeing both before committing. The RunxBuild hosting calculator prices static hosting, a service, a database, and bandwidth as separate items so a self-hosted CMS can be compared against a hosted one. RunxBuild builds static sites from a repository with custom domains and redirects and 120GB of bandwidth included, and runs self-hosted CMS containers with managed MySQL or Postgres behind them, backed up and on a private network.

Useful related references:

• Static Site CMS: The Git-Based, the API-Based, and the One That Beats Both for Most Teams
• Next.js CMS: Choosing Between Git, Headless, and Something You Already Have
• Services on RunxBuild

FAQ

Which CMS works best with Gatsby?

Technically almost any, since the plugin ecosystem is broad. The real choice is by category: Git-based Markdown when developers are the editors, an API-first hosted CMS when non-technical people publish regularly, or a traditional CMS in headless mode when the organisation already runs one.

What is a headless CMS?

A content system that stores structured content and serves it as JSON or GraphQL without owning the presentation layer. The same content can then feed a website, a mobile app, and email, and the frontend team chooses its own tools independently.

Does content update immediately on a static site?

No. Static generation fetches content at build time, so a change requires a build. That is fine for sites publishing a few times a week and becomes a bottleneck at hourly publishing or with large page counts. Incremental builds and on-demand revalidation are the mitigations.

How should I model content in a headless CMS?

Around the content rather than the page: an article has a title, author, body, and date, not a hero section with a background colour. Use references instead of duplicating values like author names, and decide how drafts and previews work before launch rather than after.

How does the site rebuild when content changes?

Through a build hook: the CMS calls a webhook on publish, which triggers a new build and deploy. Without it, publishing requires a developer to trigger a build manually, which undermines the entire point of giving editors their own interface.