The Best CMS for an HTMX Project (Server-Rendered)

HTMX brought server-rendered HTML back into fashion — you send HTML over the wire, not JSON, and let the server do the work. That's a great fit for content sites, but it changes what you want from a CMS. You don't need a headless JSON API and a heavy JavaScript front end. You want a CMS that renders HTML on the server, that you can extend in the same backend language, and that doesn't force a decoupled architecture you didn't ask for.

This guide covers what an HTMX project needs from a CMS and why a server-rendered, Laravel-based CMS is often a better match than a headless one.

What an HTMX project wants from a CMS

HTMX flips the usual headless assumptions:

• Server-rendered HTML — HTMX swaps HTML fragments, so a CMS that renders HTML server-side fits naturally.
• Same-language extensibility — HTMX projects are backend-centric; you want to extend the CMS in that backend, not maintain a separate JS app.
• No forced decoupling — you don't need (or want) a JSON API and a React front end just to show content.
• Fast, cacheable pages — server-rendered HTML is easy to cache.

HTMX is a reaction against heavy SPAs. Your CMS choice should match that philosophy, not fight it.

The short answer

For an HTMX project, a server-rendered, backend-native CMS usually fits better than a headless one. You want the CMS to render HTML, live in a backend you can extend, and serve pages HTMX can enhance with partial swaps.

UnfoldCMS is built on Laravel 12 and renders pages server-side with Blade templates. If your HTMX project is already in Laravel (or PHP), UnfoldCMS is a natural fit — it's the same stack, renders HTML, and you extend it in the language you're already writing. Below is why that beats bolting a headless CMS onto an HTMX app.

Why server-rendered fits HTMX better than headless

HTMX's whole model is server-rendered HTML fragments. A headless CMS gives you JSON, which means you'd have to render that JSON to HTML yourself — adding the very layer HTMX exists to avoid. A server-rendered CMS gives you HTML directly:

• UnfoldCMS renders pages with Blade templates server-side. Your HTMX interactions can request and swap HTML fragments from routes you control.
• You're not maintaining a separate JavaScript front-end app to consume an API — the thing HTMX developers deliberately avoid.
• Server-rendered pages are easy to cache, which UnfoldCMS does with a page-cache layer that serves pre-rendered HTML before the framework even boots.

For content-driven HTMX sites, this is the aligned architecture. See when not to use a headless CMS.

Same-stack extensibility (if you're on Laravel)

HTMX projects are backend-centric. The best CMS is one you can extend in that backend. If your project is Laravel:

• UnfoldCMS is a Laravel app — you extend it with Laravel controllers, routes, Blade views, and Eloquent models, the same tools you're already using.
• You can add HTMX-driven routes that return Blade partials, wire them to CMS content, and keep everything in one codebase and one language.
• No context-switching to a separate JS build, no API contract to maintain between two apps.

This is the real advantage for a Laravel + HTMX team: the CMS isn't a foreign system you integrate with — it's the same framework. See what makes a CMS developer-friendly.

If your HTMX project isn't in PHP

Be honest about fit. If your HTMX backend is in Go, Python, Rust, or Node, UnfoldCMS (a Laravel app) isn't the same-stack win — you'd run it as a separate service. In that case you have two options:

• Run UnfoldCMS as a content service and fetch content over its REST API (/api/v1) to render server-side in your backend. This works, but you lose the same-language advantage.
• Use a CMS native to your backend's language, or a flat-file/Git-based CMS your backend reads directly.

The strong case for UnfoldCMS + HTMX is specifically a Laravel/PHP project. Outside that, weigh the integration cost.

The API is still there if you want it

Even in a server-rendered HTMX setup, having an API is useful — for a mobile app later, or a partner integration. UnfoldCMS ships a REST API at /api/v1 alongside its server-rendered pages, so you're not locked into one delivery mode. You render HTML for HTMX today and expose JSON when you need it, from the same install. See CMS with a REST API.

When headless still makes sense

Reach for a headless CMS with your HTMX app instead if:

• Your backend isn't PHP and you'd rather consume a language-agnostic API than run a Laravel service.
• You're already committed to a headless architecture for other reasons.
• You need the CMS content in multiple non-web clients where server-rendered HTML doesn't help.

Frequently asked questions

What is the best CMS for an HTMX project?

A server-rendered, backend-native CMS usually fits an HTMX project better than a headless one — HTMX swaps HTML fragments, so a CMS that renders HTML server-side aligns with it. UnfoldCMS, built on Laravel 12 with Blade, is a strong fit for HTMX projects already in Laravel/PHP. For non-PHP backends, weigh running it as a service versus a language-native CMS.

Why not use a headless CMS with HTMX?

A headless CMS returns JSON, which you'd have to render to HTML yourself — adding the front-end rendering layer HTMX exists to avoid. A server-rendered CMS gives you HTML directly, matching HTMX's model. That said, headless still fits if your backend isn't PHP.

Does UnfoldCMS render HTML server-side?

Yes. It's a Laravel app that renders pages with Blade templates server-side, and it has a page-cache layer that serves pre-rendered HTML before the framework boots. Your HTMX interactions can request and swap HTML fragments from routes you control.

Can I still get a JSON API if I need one?

Yes. UnfoldCMS ships a REST API at /api/v1 alongside its server-rendered pages, so you render HTML for HTMX now and expose JSON later for a mobile app or partner — from the same install.

The takeaway

HTMX is a bet on server-rendered HTML, and a server-rendered CMS matches that bet better than a headless one. For a Laravel/PHP + HTMX project, UnfoldCMS is a natural fit — same stack, renders HTML, extend it in the language you already use, with a REST API available if you ever need it. If your backend isn't PHP, weigh the integration cost against a language-native option.

Related: When not to use a headless CMS · What makes a CMS developer-friendly · CMS with a REST API