safi/filament-atelier
A visual page builder plugin for Filament. Developers define section blocks in PHP with a Blade view and a settings schema; clients assemble pages in a full-screen editor with a live, responsive iframe preview. Pages are stored as JSON and rendered server-side by Blade. Multi-language.
Architecture fit. Atelier inverts the usual page-builder model in the way that matters most for a Laravel shop: block types are code (one PHP class declaring key, label, icon, category and a Filament schema, plus one Blade view), and a page is a JSON tree of typed block references rendered server-side by Blade at request time. No HTML in the database, no block validation chain, no deprecation chain, and — critically — the editor preview loads the real public layout and stylesheet, so the preview cannot drift from production. Design tokens are CSS custom properties read by both the editor and the public page, which closes the other common drift channel. For a team already fluent in Blade and Filament this is the lowest-friction option available; nothing is fought against.
The trade is explicit and architectural: the content model is developer-gated. Clients compose pages from a section library we author; they cannot create block types from the panel. The maintainer states this is design, not stopgap, with panel-authored blocks parked for v2. That is a feature for agency/brand work and a constraint for product teams that want self-service section creation.
Integration feasibility. Feasible, but stack-pinned. It requires Laravel 12/13, Filament 5, Livewire 4, Alpine 3 and Tailwind 4. The practical gate is the Filament major: any host application on Filament 3 or 4 needs a panel upgrade before this is even installable. Greenfield marketing sites inside a modern Laravel app are the natural landing zone.
Technical risk. Three concentrated risks. (1) Supply chain and longevity: single maintainer, 34 stars, zero dependents, self-declared MVP, and a "Not built yet" list that removes header, footer, contact-form and raw-HTML blocks, the revisions UI, drag reordering, per-block asset loading and any page cache or measured performance budget. (2) Surface area: Atelier owns the page model, slug resolution, routing, rendering, sitemap and 301 redirects — a large amount of behaviour to delegate to a v0.x package. Exit cost is bounded, though: blocks are our classes, views are our Blade, and the JSON tree is portable. (3) Silent-failure installation: the README itself flags steps that "fail silently if you skip them" — Tailwind content paths pointing at the package views, migration publishing after each update, and storage:link.
Key questions to resolve before commitment. Is there any multi-tenancy or per-role authorization model beyond Filament panel access, and does it hold at the page and locale level? Does the public layout need specific headers for the preview iframe to load — a default X-Frame-Options: SAMEORIGIN or CSP frame-ancestors would break the editor. What is the query cost of loading page JSON per request, and is caching expected at the edge or the app? What happens to existing page JSON when a block class is deleted or renamed? What are revision snapshot retention and pruning policies? How does a catch-all page route coexist with the app's existing routes and route-model binding?
Stack fit. Best fit: a Laravel 12/13 application already on Filament 5, with a marketing/brochure/docs surface that a non-technical editor maintains, and a design system we want enforced rather than suggested. Poor fit: applications on older Filament majors, stores with heavy structured product data, or any app that already has a CMS — running two content systems duplicates the SEO, sitemap and slug-redirect concerns Atelier already solves.
Migration path. Install via Composer, publish the filament-atelier-migrations tag, migrate, run storage:link, register AtelierPlugin::make()->blocks(...) in the panel, and point Tailwind at the package's views. Then the real work: authoring the block library against our actual design tokens, and mapping existing URLs to Atelier pages.
Compatibility. Pin the Composer constraint to an exact minor version and commit the lockfile — this is not a package to float. Re-publishing migrations is mandatory after every upgrade; the additive-migration design means a skipped publish surfaces later as a runtime "no such table" error in whichever feature first touches the new table. Treat vendor:publish --tag=filament-atelier-migrations && php artisan migrate as a fixed step in the deploy pipeline, not a manual one.
Sequencing.
supports() controls, and wire Tailwind content paths plus design tokens in the same change.hreflang, sitemap entries, JSON-LD graph — against current pages before migrating any of them.Maintenance. Assume you are effectively maintaining a fork-adjacent dependency. MIT licence and clean separation (our blocks, our views, portable JSON) make a maintained internal fork credible if the upstream stalls. Budget for one engineer reading the package source, not just the wiki, in the first quarter.
Support. No SLA, no commercial backing, one author, 34 stars. The wiki is unusually good — installation, blocks, layouts, tokens, multi-language, publishing, SEO, structured data, configuration, troubleshooting, plus an agent quickstart — but it is written by the same person who wrote the code, so it documents intent as much as observed behaviour. Name an internal owner before adopting; "the package maintainer will fix it" is not a support plan.
Scaling. Server-rendered Blade is the cheapest rendering path available, so page weight is not the concern. The unmeasured concern is per-request JSON load plus the sitemap regenerated on every request with no cache to clear, plus JSON-LD built at render. At hundreds of pages this is fine; at thousands, put response caching at the edge or introduce an application-level cache keyed on the page's updated_at, and cache the sitemap explicitly. The README records no Lighthouse numbers and no performance budget — run our own before committing to a traffic forecast.
Failure modes to instrument.
storage:link missing → image and gallery blocks 404.X-Frame-Options or restrictive CSP → preview iframe blank; editor looks broken while the site is fine.Ramp-up. Developer ramp is short for anyone who knows Filament schemas — the block API is one class plus one view — but the wiki names "five things that bite," so budget a half-day of reading plus the spike. Editor ramp is a single training session on the three-pane flow, with one recurring complaint: reordering is up/down buttons, not drag, and new sections always land at the end. That is a real friction cost for long pages and should be socialised with stakeholders before launch rather than discovered in week two.
Recommendation. Adopt for internal and agency-style marketing surfaces where the section library is ours and the blast radius of a defect is a marketing page. Trial it on a bounded page cluster before extending to revenue-critical pages. Do not put it behind a client commitment that depends on header/footer/contact-form blocks, revisable content, or drag reordering without either scheduling that work ourselves or negotiating it upstream first.
How can I help you explore Laravel packages today?