SolidJS CMS: Self-Host a Headless Backend

SolidJS won people over by doing less at runtime — fine-grained reactivity, no virtual DOM, signals that update exactly what changed. Then you reach for a CMS and the ecosystem points you back at the same hosted SaaS boxes everyone else uses, where your content lives on someone else's server. There's a cleaner fit.

What is a SolidJS CMS?

A "SolidJS CMS" isn't a special product — it's any headless CMS that hands your Solid app content over an API. Solid renders the UI; the CMS stores posts, pages, and media and returns them as JSON. Because Solid is a client-rendered (or SolidStart server-rendered) app, you want a CMS with no frontend of its own — just a clean API that createResource can fetch.

The part most guides skip: headless doesn't have to mean hosted. You can run a headless CMS on your own server so the content lives in your own database. That's the difference between owning your content and renting access to it.

The usual SolidJS CMS picks — and their catch

Search "SolidJS CMS" and you get Hygraph and Strapi. Both work. Both share the traits Solid developers tend to dislike:

• Hosted SaaS keeps your content on their infrastructure. Export exists, but the API you build against is theirs to price and change.
• Metered pricing. A Solid app that fetches per route can burn a free tier quickly, then you're on a usage plan to read your own content.
• A black-box editor. You get the dashboard they ship — no forking the login, adding a field type, or restyling the admin.

For a quick side project none of that bites. For anything you'll run for years, or content you must keep on your own servers, it does.

Self-hosted: the option the listicles skip

UnfoldCMS is a self-hosted headless CMS built on Laravel 12. You run it, it stores content in your own MySQL database, and it exposes a versioned REST API at /api/v1/*. Your Solid app reads it with plain fetch() inside createResource — no SDK, no account, no meter.

Straight facts so there's no surprise later:

• The API is REST only — no GraphQL. If your team is set on GraphQL, Hygraph fits better.
• There's no official Solid package. You call the JSON API directly, which with createResource is a few lines.
• It's self-hosted — you run the server. That's the whole point, but it's real work.

Wiring SolidJS to a self-hosted CMS

Solid's createResource is built for exactly this. First a typed fetcher:

// cms.ts
export interface Post {
  id: number;
  title: string;
  slug: string;
  body: string;
  short_description: string;
  posted_at: string;
}

const BASE = "https://your-cms.example.com/api/v1";

export async function fetchPosts(): Promise<Post[]> {
  const res = await fetch(`${BASE}/posts`);
  if (!res.ok) throw new Error(`CMS error: ${res.status}`);
  const json = await res.json();
  return json.data; // Respond::success envelope — data under .data
}

export async function fetchPost(slug: string): Promise<Post> {
  const res = await fetch(`${BASE}/posts/${slug}`);
  if (!res.ok) throw new Error(`CMS error: ${res.status}`);
  return (await res.json()).data;
}

Then a component that renders the list with Solid's <For> and <Suspense>:

// BlogList.tsx
import { createResource, For, Suspense } from "solid-js";
import { fetchPosts } from "./cms";

export default function BlogList() {
  const [posts] = createResource(fetchPosts);

  return (
    <Suspense fallback={<p>Loading…</p>}>
      <For each={posts()}>
        {(post) => (
          <article>
            <a href={`/blog/${post.slug}`}>{post.title}</a>
            <p>{post.short_description}</p>
          </article>
        )}
      </For>
    </Suspense>
  );
}

createResource handles loading and error states, <Suspense> shows the fallback, and Solid re-renders only what changed. No SDK abstraction to learn — just the fetch you'd write anyway.

Rebuild on publish with webhooks

If you deploy your Solid app (or SolidStart site) as static output, you don't want to redeploy by hand every time an editor hits publish. UnfoldCMS ships outgoing webhooks signed with HMAC-SHA256 that fire on content events. Point one at your host's deploy hook, and a publish triggers a fresh build. Subscriptions are managed from the admin API at /api/v1/admin/webhooks.

SolidJS CMS options compared

Committed to GraphQL? Hygraph or self-hosted Strapi. Want to own your data and cap cost while keeping Solid's clean fetch model? UnfoldCMS or self-hosted Strapi.

FAQ

Can I use a headless CMS with SolidJS?

Yes. Any headless CMS with a REST or GraphQL API works with SolidJS — you fetch content with createResource (or plain fetch) and render it with <For>. Solid is backend-agnostic, so the CMS choice comes down to hosting, pricing, and data ownership.

Does SolidStart change the CMS choice?

Not really. SolidStart adds server-side rendering and routing, so you can fetch CMS content in a server function or a route loader instead of the client. The CMS still just serves JSON over HTTP — the same REST or GraphQL endpoints work either way.

What's the best self-hosted CMS for SolidJS?

If you want content in your own database and no per-request pricing, a self-hosted headless CMS like UnfoldCMS fits, read with createResource. Self-hosted Strapi is the other main option and adds GraphQL, on a Node stack rather than PHP.

Do I need a SolidJS SDK to connect to a CMS?

No. An SDK is a wrapper over HTTP calls. Solid's createResource plus typed fetch functions gives you loading states, error handling, and full types without one. UnfoldCMS has no Solid SDK by design — you call /api/v1/* directly.

The bottom line

SolidJS is built to do less and own more of what it does. Pairing it with a CMS you don't control undercuts that. A self-hosted headless CMS keeps content in your database and stays one createResource call away. See the live demo or the headless CMS guide.

Related: Angular CMS: Self-Host Your Content · Best CMS for React Developers · What Is a Headless CMS?