When a Filament admin starts becoming a CMS

See the Filament workspace Add Capell Foundation

Filament already solves the admin surface. Adopt Capell when public pages are making your team rebuild URLs, previews, layouts and publishing conventions resource by resource.

Actual Capell CMS pages index showing records, SEO overview metrics, thumbnails, layouts, and editor actions. — CMS capture · Content index **Structured content stays visible in the admin.** The screenshot comes from the Capell CMS admin, where page records, preview images, layouts, SEO status, and editor actions stay visible without opening every page.

Actual Capell CMS page types screen showing registered content structures and their available editor actions. — CMS capture: page structure **Page families are defined once.** A real Filament screen showing the registered page structures editors use instead of rebuilding content rules inside each page.

Redacted terminal capture of Composer showing the installed Capell core package, its PSR-4 namespace, PHP requirement, Filament support, and Laravel dependencies. — Composer output: core package **Capell installs as Laravel packages.** Actual composer show output captured from this application, with the local repository path and build reference omitted.

Filament 5 workspace Shared page and URL model Public Packagist foundation

Filament is an excellent admin foundation. A few editable records, internal tools or stable settings do not need a full CMS. Custom resources keep that work direct and easy to understand.

The maintenance problem begins when those records become public pages. URLs need history, editors need previews, layouts repeat, translations have to line up, and the application needs a dependable route from stored content to public HTML.

Custom resources remain enough when

The work is mainly internal CRUD or a small set of settings.
Public routing and presentation are simple and stable.
Your team is comfortable owning each CMS convention locally.

Adopt a shared model when

Several page families need the same URL, preview, layout and publishing behaviour. Capell keeps the Filament workspace while giving those concerns one implementation. Developers can then spend their custom code on the parts of the site that are actually unusual.

What to inspect

Compare one existing resource with the demo workflow. Count the route, form, preview, history, metadata and rendering code around it. Capell earns its place only if the shared model removes more maintenance than it introduces.

Ownership map

Move the repeated work out of individual resources

A page can look like any other Filament record to an editor while the application applies consistent CMS behaviour around it. Developers stop inventing a new route, preview and metadata convention for each resource.

Keep custom resources for internal records and stable settings. Reach for Capell when those records become public page families that should change together and produce responses your tests can inspect.

Pages behave like pages

Editors manage content, URLs, translations and metadata without each page family learning different rules.

View system map

Layouts use tested components

LayoutBuilder lets editors assemble a page from components the team has designed, shipped and can update later.

See LayoutBuilder

Add a feature for a real job

SEO, search and publishing workflow can be installed as packages after the team reviews their migrations and public impact.

Browse packages

Test what visitors receive

Capell Frontend connects approved content to project themes and Blade components without exposing admin state in the response.

See the rendering path

Comparison

Capell vs a custom Filament admin

Best fit

Capell: Large Laravel websites that need CMS structure and public output.
Custom Filament admin: Internal tools or bespoke admin screens where CRUD covers the whole need.
Headless CMS: Teams that want content APIs outside the Laravel app.
WordPress: Sites where the plugin and theme ecosystem matters most.
Hosted builder: Hosted visual site builds where the frontend can be owned by the builder.

Admin surface

Capell: Filament admin plus Capell page, layout, package, and publishing concepts.
Custom Filament admin: Raw Filament resources the team designs and maintains.
Headless CMS: A separate CMS admin away from Laravel.
WordPress: A familiar admin with plugin-shaped structure.
Hosted builder: A hosted designer and editor.

CMS model

Capell: Pages, URLs, translations, layouts, navigation, themes, media, metadata, and extension points.
Custom Filament admin: Whatever tables, resources, and conventions the team creates.
Headless CMS: Remote content models queried over APIs.
WordPress: Posts, pages, custom fields, and plugins.
Hosted builder: Hosted pages and collections.

Public rendering

Capell: Blade in your Laravel app, Livewire, cache, hooks, APIs, and route-backed output.
Custom Filament admin: Whatever render path the team builds around admin data.
Headless CMS: A consuming frontend renders remote content.
WordPress: Theme and plugin output.
Hosted builder: Hosted output controlled by the builder.

Growth path

Capell: Composer packages, manifests, install impact, marketplace trust, and optional extensions.
Custom Filament admin: Copied resources, local packages, or one-off service classes.
Headless CMS: Platform plugins and integrations.
WordPress: A large but uneven plugin ecosystem.
Hosted builder: Closed marketplace apps and scripts.

Scroll horizontally to view the full table.

Decision	Capell	Custom Filament admin	Headless CMS	WordPress	Hosted builder
Best fit	Large Laravel websites that need CMS structure and public output.	Internal tools or bespoke admin screens where CRUD covers the whole need.	Teams that want content APIs outside the Laravel app.	Sites where the plugin and theme ecosystem matters most.	Hosted visual site builds where the frontend can be owned by the builder.
Admin surface	Filament admin plus Capell page, layout, package, and publishing concepts.	Raw Filament resources the team designs and maintains.	A separate CMS admin away from Laravel.	A familiar admin with plugin-shaped structure.	A hosted designer and editor.
CMS model	Pages, URLs, translations, layouts, navigation, themes, media, metadata, and extension points.	Whatever tables, resources, and conventions the team creates.	Remote content models queried over APIs.	Posts, pages, custom fields, and plugins.	Hosted pages and collections.
Public rendering	Blade in your Laravel app, Livewire, cache, hooks, APIs, and route-backed output.	Whatever render path the team builds around admin data.	A consuming frontend renders remote content.	Theme and plugin output.	Hosted output controlled by the builder.
Growth path	Composer packages, manifests, install impact, marketplace trust, and optional extensions.	Copied resources, local packages, or one-off service classes.	Platform plugins and integrations.	A large but uneven plugin ecosystem.	Closed marketplace apps and scripts.

Next step

Compare the workflow with your current resources

Use the demo to judge whether one page model would remove enough maintenance from your Filament admin.

Inspect how an editor finds a page, changes it, previews it and follows it to public output. Keep your custom build if the extra model does not earn its place. Read why Capell keeps a shared Page model.

Walk the editor workflow Try the shared page model

Role scenarios

What to inspect in a Filament CMS

Checks for deciding when shared CMS structure earns its place beyond a custom admin.

Role-based checks drawn from product capabilities and fit boundaries.

Laravel developer representing this editorial scenario.

The day hand-built Filament stops scaling — what to verify

Model the same repeated content and URL rules first as copied Filament resources, then as a shared page type. Compare the changes required when a field or publishing transition is added across every instance.

Expected evidence: Capell gives that repeated content one shared model plus a real editorial state machine, so a page moves draft to approved to published through enforced transitions and the aggregate throws rather than let someone jump it straight to archived. The team keeps Filament while dropping the copy-paste resource work.

Choose a lighter option when: If their admin is genuinely one-off with no repeating content, plain Filament resources are lighter and teams should stay there. The shared model pays off with repetition, not novelty.

Content editor representing this editorial scenario.

Review and approve, built into the admin — what to verify

Submit a draft for review, request changes, approve it and attempt an illegal state jump. The admin should guide the normal sequence and reject a transition that bypasses the publishing rules.

Operational evidence to check: The draft-to-approved-to-published states are enforced, so a page cannot skip straight from draft to archived, and request-changes is a first-class step rather than a Slack message. It is the submit-review-approve loop that is usually a paid enterprise add-on, here as a core part of the daily flow.

Decision note: For a small, unusual admin, plain custom Filament is still simpler than adopting a whole CMS layer. This earns its place once repeated content types and a publishing flow are in play.

Agency team member representing this editorial scenario.

Build the content layer once, reuse it — what to verify

Register a typed package-settings panel, add a setting and run the upgrade path across two client sites. Both admins should reconcile the schema without bespoke configuration screens.

Evidence to request: Settings are registered as contract-enforced typed panels, not a loose config file, and a dedicated settings-migration step reconciles added or removed settings on upgrade. Across many clients that is the economics: the admin structure comes from one place instead of being re-solved per engagement.

Alternative fit: Custom Filament genuinely still wins for a small, unusual admin, and it is worth trusting a tool that says so rather than claiming to be the answer for everything.

Manage cookie preferences