CMS for Gatsby in 2026: Options for a Framework in Maintenance Mode

Choosing a CMS for Gatsby in 2026 comes with a question nobody asked in 2020: should new content work target Gatsby at all? Netlify acquired the company in 2023, the framework has been in maintenance mode since, and the ecosystem's energy moved to Astro and Next.js. Plenty of production Gatsby sites still run beautifully and will for years. But "which CMS" and "should we stay" are now the same conversation, so this post handles both honestly.

TL;DR: For an existing Gatsby site staying put, the practical CMS choices are anything with a solid REST or GraphQL API: WordPress via WPGraphQL, Contentful through its mature source plugin, or a self-hosted API CMS (UnfoldCMS, Strapi, Payload) sourced through Gatsby's node APIs. Gatsby's GraphQL data layer flattens the differences, so pick on cost and editor experience. For a new project, seriously evaluate Astro first; the CMS advice transfers almost unchanged.

How Gatsby Talks to Any CMS

Gatsby's defining design is its internal GraphQL layer. Source plugins pull content from anywhere at build time, normalize it into Gatsby's node system, and every page queries that layer rather than the CMS directly. Two consequences matter for the CMS decision.

First, the CMS's own API style matters less than elsewhere: REST sources normalize into Gatsby's GraphQL just like GraphQL sources do. Second, build-time sourcing means every content change requires a rebuild, so webhook-triggered builds are the difference between a publish appearing in minutes versus whenever someone remembers to deploy.

Sourcing a REST CMS without a dedicated plugin takes one function in gatsby-node.js:

exports.sourceNodes = async ({ actions, createNodeId, createContentDigest }) => {
  const res = await fetch('https://yoursite.com/api/v1/posts');
  const { data } = await res.json();

  data.forEach((post) => {
    actions.createNode({
      ...post,
      id: createNodeId(`post-${post.id}`),
      internal: {
        type: 'BlogPost',
        contentDigest: createContentDigest(post),
      },
    });
  });
};

Twenty lines and any JSON API becomes allBlogPost in your page queries. This is the honest answer to "is there a source plugin for X": for REST CMSs, you barely need one.

The CMS Options, Ranked by Situation

Already on WordPress: WPGraphQL plus gatsby-source-wordpress remains the most-traveled path. It works, the incremental build story is decent, and you inherit the WordPress maintenance stack we've costed elsewhere (the hidden costs breakdown). Teams here are usually keeping Gatsby precisely because this pairing is stable; changing either half reopens the whole architecture.

Budget for SaaS: Contentful's source plugin is among the oldest and most polished in the ecosystem, with preview support and incremental sourcing. Price the API-call meters and the $300/month Lite tier against your traffic before committing; the free tier's 100k monthly calls disappear fast under Gatsby's build patterns, which re-fetch aggressively.

Self-hosted, content-shaped: UnfoldCMS (ours, bias noted) pairs with Gatsby through exactly the sourceNodes pattern above: REST endpoints for posts, pages, categories, and menus, publicly readable so builds need no secrets, plus HMAC-signed webhooks pointed at your build hook so publishes trigger rebuilds automatically. One-time pricing and $5/month hosting keep the "static site economics" promise Gatsby started with. Four content types, no custom schemas; app-shaped content models should look one entry down.

Self-hosted, custom models: Strapi and Payload both expose REST and GraphQL, model arbitrary content types, and run on your VPS. Gatsby sources either without drama. Our self-hosted headless comparison covers their running costs and license terms.

Git-based: Markdown in the repo with Decap or Tina still works fine with Gatsby's filesystem sourcing, with the editor-experience ceiling we described in the Jamstack CMS guide.

The Elephant: Should New Projects Pick Gatsby?

I'll say it plainly rather than around: probably not. Framework commits slowed sharply after the Netlify acquisition, major ecosystem plugins have unaddressed issue backlogs, and the static-content niche Gatsby defined is now served by Astro with faster builds and no GraphQL indirection for teams that never wanted it. Next.js took the app-shaped remainder.

That's not a demolition notice for existing sites. A working Gatsby site with a wired CMS has no urgent reason to move; rebuilds cost real money and "the framework is quiet" is not an outage. The sensible posture: keep running it, keep the CMS decoupled (every option above outlives your framework choice), and when a redesign lands on the roadmap anyway, evaluate Astro against Next.js for the rebuild. A CMS chosen for its API rather than its Gatsby plugin makes that future migration a frontend project instead of a content migration.

That decoupling argument, more than any feature, is why I'd steer Gatsby teams toward API-first CMSs over deeply Gatsby-integrated sourcing today.

When the Rebuild Comes: Gatsby to Astro, With the CMS Intact

Since the honest advice above points rebuild-bound teams at Astro, here's what that move looks like when a CMS is already wired in, because the CMS is precisely what makes it manageable.

The data layer translates cleanly. Gatsby's sourceNodes pulls from your CMS API at build time; Astro's content loaders do the same job with less ceremony. The fetch code you wrote against /api/v1/posts moves almost verbatim, minus the node-creation boilerplate Gatsby required around it. GraphQL page queries become plain data access in Astro components, which most teams experience as deleting code.

Components need real porting: React components become Astro components or stay React inside Astro's islands where interactivity justifies them. This is the bulk of the effort, and it's proportional to how much client-side interactivity the site really has, which for content sites is usually less than the component count implies.

What transfers for free is everything CMS-side: content, media, editorial workflow, webhook plumbing (repoint the URL at the new build hook), and your editors' training. A team that chose a decoupled CMS gets to run the rebuild as a purely frontend project with content untouched, often shipping section by section behind a reverse proxy.

The strategic takeaway sits a level up: framework migrations are now routine events (Gatsby's arc proves it), so weight your CMS choice toward API cleanliness and data ownership over deep framework integration. The plugin that made sourcing effortless in 2020 is the coupling you're unwinding in 2026.

FAQ

What is the best CMS for an existing Gatsby site?

Whatever exposes a clean API and fits your editors and budget: WordPress + WPGraphQL if you're already there, Contentful if SaaS pricing suits you, UnfoldCMS or Strapi self-hosted if you want flat costs. Gatsby's data layer normalizes them all; the differentiators are cost and editing experience, not compatibility.

Is Gatsby dead in 2026?

Maintained but quiet. Production sites keep working and security patches land, while feature development and community energy have moved elsewhere. Treat it as stable legacy: fine to run, hard to recommend for new builds.

How do content updates trigger Gatsby rebuilds?

Point your CMS's webhook at a build hook URL from your host (Netlify, Gatsby Cloud successors, Cloudflare Pages). Editor publishes, webhook fires, build runs, CDN updates. Verify webhook signatures where your CMS supports them so outsiders can't burn your build minutes.

Can I use a REST-only CMS with Gatsby's GraphQL layer?

Yes, that's what source plugins do: normalize any upstream API into Gatsby's internal GraphQL. The sourceNodes snippet above covers most REST APIs in about twenty lines, no dedicated plugin required.

Does gatsby-source-wordpress still work in 2026?

It works and receives maintenance, with a slower issue-response cadence than its peak years. Existing WPGraphQL pairings keep running; test plugin updates in staging before production, which was always good advice and is now essential advice.

Is Gatsby Cloud still available?

Netlify wound down Gatsby Cloud as a separate product after the acquisition; its features (build hooks, previews, incremental builds) map onto Netlify's own platform. Any host with build hooks (Netlify, Vercel, Cloudflare Pages) serves the webhook-rebuild pattern this post describes.

Methodology

Framework status reflects public repository activity and Netlify's communications through July 2026. Contentful pricing and free-tier limits were read from their pricing page (Lite: $300/month; free tier: 100k API calls/month). Code targets Gatsby 5's node APIs per official documentation. UnfoldCMS claims (public read REST API, HMAC webhooks, one-time tiers) reflect the live product at unfoldcms.com. We build UnfoldCMS; the recommendation to evaluate Astro for new projects stands regardless of which CMS you pair with it.