A no-limits CMS built for design engineers
A fully-extensible CMS built with Laravel and Filament. As customizable and unique as you can make it.
Features at a glance...
- 40+
- Built-in blocks
- 6
- Layouts
- 5
- Skins
- 32
- MCP tools
Created for design engineers
Blocks are PHP classes and Blade views, and every colour and measurement is a design token declared once. The content model is code rather than a screen of configuration, so the people who build the site decide how it renders and what an editor is offered.
Built-in AI agent MCP server
An MCP server ships with the package, reachable over stdio or an authenticated HTTP endpoint. An agent drafts pages, rearranges blocks and publishes through the same domain services the panel uses, so the same validation and block permissions apply and every write lands in version history against the user whose token made it.
Completely customizable and extensible
Any block's markup is replaced by putting a file in your own views directory, with no config entry and no publish step. The class behind a block key can be swapped, and content types and layouts of your own sit alongside the built-in ones. Content already stored keeps working through all of it.
Start with the developer guide!!
Installation, the data model, authoring blocks and layouts, regions, skins, caching, search and the MCP server.
Questions
Can I make my own theme?
Of course! You can make custom templates, blocks, and skins using standard Laravel Blade components and CSS. We use auto-discovery, so as soon as you load your code, your creation is ready to use.
Can I change the markup of the built-in components?
Yes, without forking it. Creating resources/views/vendor/cms/blocks/hero.blade.php replaces the Hero template, because Laravel resolves that directory ahead of the package. There is no config entry and no publish step. The class behind a block key can be swapped the same way, and stored content keeps working.
What happens to old pages when a block changes?
They keep rendering. Versions are immutable, so a block that gains or renames a field migrates the stored shape on read in cast() rather than through a database migration. A page saved a year ago renders through today's code.
How is the front end styled?
The views carry semantic cms-* classes only, with the utilities behind @apply in one stylesheet. Tailwind never has to scan the package's views, and a rule written after the import wins on source order, so restyling rarely means forking markup.
How do you handle page caching?
Rendered pages are cached for best performance. A page block declares itself uncacheable when its output depends on the request or on data outside its own version, and that propagates to every page embedding it through a snippet. Publishing, moving or deleting content invalidates the cache for that page.