141
First-party package directories currently tracked in the Capell package library.
Choose which optional cookies Capell may use.
Required for Capell to work — login, security, page rendering.
Anonymous usage telemetry to improve editor performance.
Personalization for the Capell marketing site.
Developers should not have to rebuild pages, URLs, layouts, previews, publishing workflow, search, SEO, cache invalidation, media, package screens, and operational checks from scratch for every content-rich Laravel project.
Capell gives that work a standard shape. Core owns the content model, Admin gives editors a Filament workspace, Frontend connects clean data to public output, and packages add capability without patching the CMS foundation.
Developers should not have to choose between a maintainable Laravel app and a CMS editors can actually use. Capell keeps the CMS inside Laravel, with Filament for the admin and the application team owning the public frontend.
The useful part is the boundary. Editors get pages, layouts, widgets, media, previews, and publishing tools. Developers keep code, tests, routes, packages, render hooks, policies, and deployment under familiar Laravel control.
If a few Filament resources solve the job, use them. Capell is for the point where the CMS has become a real product surface and needs the same maintainability standards as the rest of the application.
For developers, the test is whether Capell behaves like Laravel work: packages, Filament boundaries, render hooks, tests, and frontend ownership.


Capell gives Laravel teams package-based CMS architecture for content structure, Filament editing, frontend delivery, workflow, operations, and extensions.
Start with the practical question: what does the visitor or editor need to do next? Capell keeps that answer tied to the Laravel app, with shared structures for repeated pages and enough room for custom work when the project genuinely needs it.
The value is not one extension point. It is the way repeated CMS work keeps landing in the same places: content structure in Core, editor workflow in Admin, public delivery in Frontend, and optional capability in packages.
That gives backend developers, frontend developers, and package authors a shared vocabulary before the site grows beyond a few editable pages.
Package authors are not asked to learn a parallel plugin language. A useful Capell package is a Laravel package with service providers, Actions, data objects, Filament surfaces, views, migrations, queues, policies, tests, docs, and a manifest that explains what the package changes.
That is why the marketplace can grow while core stays focused. Repeated CMS work gets packaged once, reviewed once, improved over time, and reused across sites.
The extension model is broader than hooks. A Capell package can own a real slice of CMS capability: the records it needs, the editor screens it exposes, the public output it contributes, the jobs it runs, the cache it invalidates, and the proof a buyer needs before installing it.
That is the pattern developers should recognise: package capability by responsibility, not one-off changes scattered through the host app.
Capell treats coding standards as product infrastructure: strict typing, PHPStan, Pest, Actions, data objects, and package-level checks keep CMS features clear to inspect before they reach editors or public pages.
141
First-party package directories currently tracked in the Capell package library.
76
Theme packages including Foundation Theme and premium theme packages.
9
Static analysis runs through the shared PHPStan configuration before release work is trusted.
91%
Test coverage across the full Pest suite.
7,570+
Combined test count reported by Capell and Capell package workflows.
42,114+
Combined assertion count reported by Capell and Capell package workflows.
142ms
Public render budget, cached output.
Capell learning journey
Role and job-based Capell paths.
Paths for owners, editors, developers, and agencies.