A year ago I started building a CMS because I had three options for client work and none fit:

• WordPress — works, but 250+ plugin CVEs/week (Patchstack 2024). I patch sites every week. Tired of it.
• Contentful / Sanity — modern, but $300/mo entry pricing for SMB use cases. Vendor lock is real.
• Strapi / Payload — solid, but Node-only. I'm a PHP/Laravel shop.

So I built UnfoldCMS — a self-hosted Laravel CMS that ships as a single product, not a framework you assemble. This post is a tour of what's actually in there. Not the marketing version — the "here are the 183 admin pages" version.

If you're picking a CMS in 2026, this is the kind of breakdown I wish vendors actually published.

The stack, briefly

• Laravel 11 + Inertia 2 + React 19 + TypeScript
• Tailwind v4 + shadcn/ui (50+ components)
• MySQL / MariaDB
• Spatie Media Library, Spatie Permission (RBAC), Spatie Activity Log
• Runs on $5/mo Hetzner VPS at ~80MB RAM idle

The shadcn + Tailwind theming side I covered in my previous post. This post is about the CMS surface — the modules, the editor, the publishing pipeline.

What's in the box

Every module here is built-in. No "plugin marketplace" — Laravel has service providers, that's the extension model.

Posts and Pages

The core publishing primitives. Both share the same model (Post with a content_type enum), but render differently.

• Posts = blog entries, indexed under /blog/{slug}, listed on the blog index page.
• Pages = root-level content like /about, /pricing, /migrate-from-wordpress.
• Same editor, same media handling, same SEO fields. Only the URL routing differs.

The editor is a structured block editor built on Tiptap's foundation. Each block is a discrete field — heading, paragraph, image, code block, callout, table — not a free-form blob. Editors get predictable layouts; developers get clean data to query.

Scheduled publishing is built in. posted_at in the future + is_published = true = post appears at the scheduled time. A single Laravel scheduler entry runs every minute and flips visibility.

Media Library

Spatie Media Library under the hood. Three things made it worth using over a custom solution:

1. Polymorphic associations — any model can have media (posts, users, settings, custom models).
2. Conversions on demand — define large, medium, thumbnail once; conversions generate when first requested.
3. Featured-image collections — separate featured-image collection per post, separate from inline body images.

The trap I'd warn against: the legacy image_large text column on the post table looks tempting for "set the hero image." Don't. Use Spatie collections — the template renders them automatically with proper aspect ratio handling.

Menus

Tree-based menu builder. Drag-and-drop reorder. Each menu item links to internal routes (resolved via Laravel's named routes), external URLs, or content (auto-generates the URL from the slug).

Multiple menus per site — Header, Footer, Mobile, Sidebar — and they support nested children. The frontend templates pull menus by slug:

$mainMenu = Menu::bySlug('main');

Forms

A form builder with a JSON schema. Fields, validation rules, success/error messages, redirect targets — all configurable from the admin. Submissions go to a form_submissions table; admins see a list with filters, can export to CSV, and forward to email or webhooks.

The architecture choice: forms are a CMS feature, not a separate app. They share the auth, the rate limits, the spam filtering (Spatie honeypot), and the activity log with the rest of the system.

Settings

Key-value store with a config-driven schema. The schema lives in config/site.php — defaults set once, admin UI generates from the schema, frontend reads via Setting::get('key', $fallback).

Why this matters: if a customer wants a "show announcement banner" toggle, you don't write a migration, a form, a controller, and a Blade variable. You add a key to the schema and it shows up in the admin automatically.

Theming

Three themes ship — Default (blue), Purple, Unfold (soft purple). Switching is one CSS variable swap (covered in detail in the previous post). The theming primitive is data-theme="..." on the root element + Tailwind v4's @theme directive.

What's in scope for theming: colors, radius, font stack. Not in scope: layout, spacing, component shape. That's intentional — themes are visual, not structural.

Templates

Above themes is templates — full frontend designs that ship with the CMS. The active one on this site is "Aurora," which has its own seed data, blade templates, and section components. Templates are swappable at install time; runtime swap is harder because each ships its own homepage section data.

SEO

Built on the ralphjsmit/laravel-seo package, extended with site-wide defaults and per-post overrides.

What gets generated automatically:

• <title> and meta description (with explicit override fields)
• Open Graph + Twitter card tags
• JSON-LD schema: Article, BreadcrumbList, Organization
• Canonical URLs with proper trailing-slash handling
• hreflang tags for multi-language sites

The CMS fallback for SEO title is the post title — but it title-cases it, which corrupts proper nouns ("WordPress" → "Wordpress"). Lesson learned the hard way: always set seo_title and meta_desc explicitly, never rely on the fallback. There's now a hard rule in our content-publishing skill.

RBAC

Spatie Permission. Three default roles ship — Super Admin, Editor, Author — and you can add more from the admin. Permissions are granular (per-model + per-action), not just role-based.

The middleware story is straight Laravel:

Route::middleware(['auth', 'role:editor|admin'])->group(function () {
    Route::resource('posts', PostController::class);
});

No vendor magic. If you've used Spatie Permission, you know exactly what's happening.

Multi-language

spatie/laravel-translatable. Each translatable field (title, body, seo_title, meta_desc) stores a JSON map of {locale: value}. The admin shows a locale switcher; the frontend resolves based on URL prefix (/fr/about) or domain.

What's not in there yet: automatic translation (machine translation pipeline). Editors translate manually for now.

The publishing pipeline (the part that took the longest)

Building a "save post" button is a weekend. Building a publishing pipeline that handles drafts, scheduled publishes, sitemap regeneration, cache invalidation, and SEO updates without race conditions is a year.

What's behind a publish action:

1. Validation — required fields, slug uniqueness, meta-desc length
2. Markdown → HTML conversion (server-side; the body is stored as HTML so the template just renders it raw)
3. SEO record sync — seo_title, meta_desc, og_image written to a related table
4. Spatie media attachment — featured image moves from temp upload to permanent collection
5. Sitemap regeneration — php artisan sitemap:generate runs synchronously (no queue worker required for shared hosting)
6. Cache invalidation — view:clear, route:clear, edge cache purge if configured
7. Activity log — Spatie ActivityLog records who published what

All of this runs synchronously in the request because the CMS targets shared hosting where queue workers aren't a given. If you're on a real VPS, you can flip QUEUE_CONNECTION=database and it queues automatically. The synchronous fallback is what makes "deploy to a $5 VPS" actually work.

Deployment story

Single artisan command: php artisan deploy. It does:

1. Verifies clean working tree on the deploy branch
2. Pushes to git
3. Pulls on the server
4. Runs composer install --no-dev (skipped if composer.lock unchanged)
5. Runs php artisan migrate --force
6. Builds frontend assets locally with pnpm run build, syncs to server via rsync (skipped if no JS/CSS changed)
7. Clears config/view/route caches
8. Verifies HTTP 200

The lessons embedded in this command:

• Frontend builds locally, not on the server. Faster, and avoids needing Node on the server.
• Composer skip when lockfile unchanged saves ~30s per deploy.
• Rsync over SCP for assets — incremental, only uploads changed files.
• HTTP 200 verification at the end catches deploys that broke the site silently.

I've shipped enough Laravel apps that I now consider the deploy command part of the product, not a project.

What's not in the box (yet)

Honest list:

Public headless API

Internal REST works. Public endpoints + signed webhooks ship late 2026. Until then, if you want to use UnfoldCMS as a content backend for a Next.js site, you write a thin Laravel route that returns JSON:

Route::get('/api/blog/{slug}', function (string $slug) {
    return Post::published()->whereSlug($slug)->firstOrFail();
});

Three lines, but I get it — that's not the same as a polished public API. Late 2026.

Plugin marketplace

Not building one. Extension model is Laravel service providers + middleware. If you know Laravel, you know how to extend it. If you don't, the learning curve is "Laravel itself," which is a real cost but a transferable one.

Visual page builder

The block editor handles structured content well. It's not a Webflow-style drag-and-drop layout designer, and probably won't be — different category. If you need that, Webflow or Storyblok is the right tool.

Multi-site / multi-tenant

Single site per install today. Agencies running 20 client sites run 20 installs (cheap on Hetzner — $5 × 20 = $100/mo for hosting; the license is per-site too).

The numbers

Concrete, not aspirational:

• Lines of code: ~80K (PHP) + ~45K (TS/TSX) — a real product, not a toy
• Pages in admin: 183
• shadcn components: 50+
• Themes shipped: 3
• Memory footprint: ~80MB idle on Hetzner CX22
• Cold start: ~250ms first request, ~40ms after warm
• Build time: ~12 seconds (Vite + Inertia bundle)
• Tests: ~600 PHPUnit tests, ~80% coverage on the critical paths

Pricing decision

One-time license per site. $99 Solo, $199 Pro, $499 Agency.

The reasoning: subscriptions hold customers' data hostage. A one-time license means a customer can install it, never pay again, and still own the install — code, database, content. If I disappear tomorrow, the install keeps working.

The downside: ARR is harder to project. The upside: customers actually trust me. After two years, I'd pick this model again.

Why I built it (the short version)

WordPress works for some sites. Contentful works for enterprise teams. None of them work for the in-between — small agencies and SMBs running 5–20 sites who want owned data, sane DX, and no monthly bill that scales with their growth.

UnfoldCMS is what I built for that gap. It's not the right answer for everyone — the comparison pages are explicit about who it's for and who it isn't.

Try it

• Live demo (admin login on the page): https://unfoldcms.com/demo
• Source: https://github.com/hpakdaman/unfoldcms
• Docs: https://unfoldcms.com/docs
• Comparison vs WordPress / Contentful / Sanity / Payload: https://unfoldcms.com/compare

Honest critique welcome in the comments — that's how the product gets better.

— Hamed