Best CMS for SolidStart in 2026

SolidStart sits in an awkward spot for CMS shopping. It's new enough that no headless platform ships a "SolidStart starter," yet mature enough (1.0 landed in 2024) that people are building real content sites on it. Search "CMS for SolidStart" and you get React tutorials with the framework name swapped in, or forum threads that trail off. The good news is that the honest answer is simpler than the noise suggests: SolidStart consumes any content API the same way it consumes any other data, so your real decision is about editing, cost, and ownership — not about SolidStart compatibility.

Here's the field in 2026, from a SolidStart and SolidJS perspective specifically.

TL;DR: SolidStart has no framework-specific CMS, and it doesn't need one. It fetches content through query and createAsync from any REST endpoint, so the shortlist is the general headless field judged on non-framework criteria: a git-based option (Markdown in your repo) for developer-authored sites, a SaaS with visual editing (Storyblok, Sanity) when editors need it and budget exists, and a self-hosted API CMS (UnfoldCMS, Strapi, Directus) when you want owned data and flat costs. Pick Markdown for docs and dev blogs, a SaaS for editor-heavy marketing sites, and a self-hosted REST CMS when cost predictability and data ownership matter most.

What SolidStart Actually Needs From a CMS

Less than the marketing implies. SolidStart is a meta-framework: file-based routing, server functions, and SSR/SSG/streaming on top of SolidJS's fine-grained reactivity. A CMS feeds it JSON over HTTP, and that JSON lands in a query wrapper that SolidStart caches and dedupes across the server/client boundary. Any REST or GraphQL API qualifies. There is no "SolidStart SDK" requirement because there's almost nothing an SDK would abstract.

// SolidStart: the whole CMS integration, using query + createAsync
import { query, createAsync } from "@solidjs/router";

const getPosts = query(async () => {
  const res = await fetch("https://yoursite.com/api/v1/posts");
  return res.json();
}, "posts");

export default function Blog() {
  const posts = createAsync(() => getPosts());
  return <For each={posts()?.data}>{(p) => <PostCard post={p} />}</For>;
}

What's worth demanding instead of framework badges: webhook support so a publish can trigger your SolidStart rebuild or revalidation, a preview flow you can point at a SolidStart preview route rather than one hardcoded to Next.js, and — if non-developers publish — an actual editing UI. That last requirement, not the framework, is what narrows the field.

The Options Worth Shortlisting

Markdown in your repo: stay in the codebase

For a docs site, a technical blog, or a portfolio where developers author everything, a content/ directory of Markdown parsed at build time is the leanest path. No external service, versioned with your code, and SolidStart's SSG mode turns it into static HTML. Solid doesn't have a Nuxt-Content-style official package, so you wire it yourself with a Markdown library and vite-plugin-style imports, which is a small amount of glue. The ceiling is the usual one: the first time a non-developer needs to publish, the git workflow stops being a feature. Our Markdown vs CMS for docs guide maps exactly where that line sits.

Storyblok or Sanity: the visual-editing picks

If editors need to see what they're changing, a SaaS with a real visual editor is the honest recommendation, and SolidStart consumes both fine. Storyblok's visual editor renders your live pages with click-to-edit overlays; Sanity's Studio is a customizable editing environment with a well-documented content API. Both are subscriptions with per-seat or per-usage meters, and your content lives on their infrastructure — the trade every SaaS CMS asks you to make. If Sanity is on your list, our self-hosted Sanity alternative piece covers what changes when you want the same model on your own box.

Strapi and Directus: self-hosted with custom modeling

When your content model is app-shaped — many custom types, relations, structured fields — Strapi and Directus are the deep self-hosted options. Strapi has the larger plugin ecosystem and a visual content-type builder; Directus is database-first, turning an existing SQL schema into an API. Both are Node services you operate (plan for a 2 GB VPS and process management), and Directus's BSL license is free only under $5M organizational revenue. Our self-hosted Strapi alternative walks the operational cost honestly.

UnfoldCMS: flat-cost REST for SolidStart content sites

Ours, bias noted. It isn't the pick for app-shaped custom schemas — content modeling is four built-in types (post, page, landing, block), so a project needing dozens of custom relations belongs with Directus or Strapi. What it offers a SolidStart content site is a clean REST API (/api/v1 for posts, pages, categories, menus, search) that the createAsync snippet above consumes directly, HMAC-signed outgoing webhooks for triggering SolidStart rebuilds on publish, and a cost profile built for owning your stack: runs on a $5/month VPS, one-time license from $0, no per-seat or per-request meters. The admin is React and self-hosted, so your data stays on your server.

Matching the Pick to the Project

1. Docs site or dev blog, developers author in Markdown: skip the CMS aisle, parse a content/ folder.
2. Marketing site, editors need visual editing, budget approved: Storyblok or Sanity.
3. App-shaped content, many custom types and relations: Directus (check the license clause) or Strapi.
4. Content site (blog, marketing, docs) wanting owned data at flat cost: UnfoldCMS on a small VPS.
5. Mixed: Markdown for the docs, an API CMS for the marketing blog, split along who authors what.

The pattern holds across every framework guide we write: SolidStart compatibility is table stakes because the CMS just serves JSON. The real differentiators are who edits, what the content model looks like, and whether costs should be flat or metered.

Rendering Strategy: Where CMS Content Meets SolidStart's Modes

The CMS choice interacts with a second decision you make almost immediately in SolidStart: which rendering mode serves the content. The pairing matters more than either choice in isolation.

Prerendering (static generation via SolidStart's prerender config) fits content that changes on editorial time — marketing pages, docs, the blog. The build pulls everything from the CMS once, emits static HTML, and hosting becomes trivially cheap on any static host. The requirement this puts on your CMS is webhook support: without a publish-triggered rebuild, editors wait on manual deploys and the CMS's editing speed stops mattering. Every option above clears that bar; point the webhook at your host's build hook and verify the HMAC signature so a forged request can't kick off builds.

Server-side rendering earns its place when content changes faster than you want to rebuild, or when pages personalize per request. Here the CMS API's latency joins your critical path on every request, so cache between them. SolidStart's query already dedupes and caches within a request; add an HTTP cache or a stale-while-revalidate layer at your host's edge and a $5-hosted REST API starts serving like a CDN. Solid's fine-grained reactivity means only the parts of the page bound to changed data re-render, which keeps the client cheap even when content is dynamic.

The hybrid most content sites land on: prerender the stable content sections, SSR the routes that need freshness or personalization, decided per-route. This is also the setup that makes CMS choice most forgiving — cached and prerendered content masks the performance differences between every platform above. What it can't mask is editor experience and cost structure, which is why those, not benchmark charts, drove the comparisons above.

One practical warning specific to SolidStart: keep CMS fetches inside query/server functions rather than firing them from client-side createEffect. Server-side data loading is the default for a reason — it keeps your "static" pages from waterfalling API calls out of every visitor's browser, which would resurrect both the latency and the metering problems you architected around.

FAQ

Is there a CMS built for SolidStart?

No, and you don't need one. SolidStart consumes any content API through query and createAsync, so the entire headless field is available. Judge options on editing experience, content model, and cost — not on whether they advertise SolidStart support.

How do I fetch CMS content in SolidStart?

Wrap the fetch in query for caching and deduplication, then read it with createAsync in your component. Do the fetch inside the query (which runs server-side during SSR), not in a client effect, so prerendered and server-rendered pages don't call the API from the browser.

Can SolidStart use a headless CMS built for React or Next.js?

Yes. "Built for React" is nearly always marketing focus rather than a technical dependency — the CMS serves JSON and SolidStart consumes it identically. The one thing to check is that preview and webhook flows aren't hardcoded to Next.js conventions, which is occasionally real.

What's the cheapest way to run a CMS with SolidStart?

Markdown in your repo is free if developers do the authoring. If you need an editing UI, a self-hosted REST CMS on a $5/month VPS with a one-time license (like UnfoldCMS) gives you an editor and owned data without a monthly per-seat bill.

Does SolidStart support static generation from CMS content?

Yes. SolidStart can prerender routes at build time, pulling content from the CMS once and emitting static HTML. Pair it with a publish webhook so new content triggers a rebuild instead of waiting for the next manual deploy.

Do I need GraphQL for SolidStart, or is REST fine?

REST is fine. query wraps any async function, so a plain fetch against a REST endpoint works exactly like a GraphQL client would. Choose based on what your CMS offers, not on a SolidStart requirement — there isn't one.

Methodology

Framework capabilities reference official documentation in August 2026: start.solidjs.com (SolidStart routing, data APIs query/createAsync, prerendering config), docs.solidjs.com (fine-grained reactivity). CMS capabilities reference storyblok.com, sanity.io, strapi.io, and directus.io (BSL license terms). UnfoldCMS claims reflect the live product and its /api/v1 REST surface. We build UnfoldCMS; Storyblok's and Sanity's visual editors, and Directus's custom-schema depth, are advantages we don't match and state plainly above.