Skip to main content
Capell home
My account

Manage cookie preferences

Choose which optional cookies Capell may use.

Essential
Always on

Required for Capell to work — login, security, page rendering.

Analytics

Anonymous usage telemetry to improve editor performance.

Marketing

Personalization for the Capell marketing site.

Cookie policy

Capell vs a custom Filament admin

Both run on Filament. The difference is how much of a content platform already exists on day one — and how much of it your team has to keep owning.

Pages + LayoutBuilder + redirects + cache Composer packages, no core forks Public render covered by tests

A custom Filament admin is a strong choice when your application needs bespoke internal workflows. It gives Laravel teams speed, control, and a familiar way to manage domain data. For a few editable records, it may be the right answer.

The strain starts when that admin quietly becomes a CMS. First it is one editable page. Then it needs slugs, previews, redirects, media reuse, layouts, translations, publishing checks, URL history, search, and a way for editors to compose landing pages without creating a new frontend problem.

Stick with custom Filament when

  • You only need a few admin-managed records.
  • Public routing is simple or not part of the work.
  • Editors do not need page composition, previews, scheduling, or publishing workflow.
  • Your team is comfortable owning every CMS edge case locally.

Move toward Capell when

  • The same CMS foundation is being rebuilt across projects.
  • URLs, layouts, media, previews, publishing, and redirects have become real requirements.
  • Optional CMS features should arrive as packages rather than local patches.
  • The public frontend needs to stay inside Laravel and testable as content grows.

Capell does not replace Filament. It gives Filament-based CMS work a standard shape so the next site, redesign, or editor request does not start from scratch.

Video overview

How the Capell platform is shaped

Before the side-by-side, here is how Capell splits Core, Admin, Frontend, and packages. It is the shape a custom Filament CMS ends up reinventing.

Capell vs a custom build, side by side

Both run on Filament. The difference is how much of a content platform already exists on day one.

Area Capell A custom Filament admin
Starting point A maintained CMS on Filament An empty Filament panel you extend
Pages and layouts Page records, URL history, LayoutBuilder blocks You design and build the schema
Publishing Draft / preview / publish states, scheduled publish, revisions You implement states and previews
Operations Redirects table, cache tags, SEO fields, diagnostics dashboard Wired up per project
Public output Public render covered by a test suite Your responsibility to get right
Maintenance Updated as packages with compatibility notes and visible impact Owned and maintained by your team forever
Questions about adopting Capell

Common questions from teams comparing Capell with a custom Filament admin

Can I keep my existing Filament resources alongside Capell pages?
Yes. Capell adds its own resources to the Filament panel for pages, layouts, redirects, media, and settings. Your existing resources stay where they are — Capell does not rewrite them.
Does Capell take over my Filament panel, or add to it?
It adds to it. Capell registers as a Filament plugin on the same panel, so your custom resources, pages, widgets, and navigation remain. Editors get CMS tooling next to your domain resources.
How do my custom policies and middleware interact with Capell?
Capell respects standard Laravel policies and middleware. Admin access stays driven by your Filament auth and your gates; public routes still run through your route middleware stack.
What happens to my routes and public frontend?
Capell adds a public render path for its page records and exposes the Blade, Livewire, Inertia, or Vue stack you already use. Your existing app routes are untouched unless you point a slug at them.
Can I adopt Capell for new pages while leaving the old admin alone?
Yes. Many teams ship Capell pages alongside a long-standing custom admin and migrate sections only when there is real reason to. The two coexist on the same panel and the same Laravel app.
What does installing Capell actually do to my app?
You install Core, Admin, and Frontend as Composer packages, run the migrations, and verify the Filament workspace plus public render. LayoutBuilder, themes, and other extensions are added only when a site needs them.
How is Capell upgraded — will my custom resources break?
Capell upgrades arrive as ordinary Composer package versions with compatibility notes. Your custom Filament resources are not part of Capell's surface, so they are not changed by upgrades.
How do I decide if it is time to stop hand-building?
If the same CMS work — slugs, previews, redirects, media reuse, layouts, publishing checks, URL history — is being rebuilt across projects, Capell gives that work a standard shape so you stop owning the foundation locally.
Can someone help me weigh the trade-off?
Yes. Use the contact path when you want a second opinion on whether your custom Filament admin should keep growing or sit alongside Capell.
Loading footer