Skip to main content
Capell home
Live demo

We use cookies for essential features and optional analytics.

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

Personalisation for the Capell marketing site.

Cookie policy

The CMS is Composer packages. The site is still your Laravel app.

A few custom resources are the right answer for a few stable screens. The maintenance problem starts when pages also need URLs, layouts, previews, revisions, media, publishing rules, multiple languages, and consistent public delivery.

That repeated work gets named owners: Core for the content model, Admin for editor concerns, Frontend for public delivery, and Composer packages for optional capability.

Shared Eloquent page model Filament admin boundary Testable public output
Plan the developer boundary See package boundaries
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.
CMS capture: package inventory Installed capabilities stay inspectable. The real extensions screen makes package ownership, version state, and operational actions visible inside the CMS.
Public output: cache hit Public HTML stays separate from the admin. This anonymous frontend capture shows the output boundary: cached public HTML with no editor selectors, model identifiers, or signed authoring URLs.

Redacted terminal capture of Composer showing the installed Capell core package, its PSR-4 namespace, PHP requirement, Filament support, and Laravel dependencies.

The first custom Filament resource is usually cheaper than adopting a CMS. The decision changes when the team keeps rebuilding the same page model, URL handling, layout rules, preview path, media workflow, revision history, and publishing controls across resources or projects.

Capell turns that repeated work into explicit boundaries. Core owns the shared Eloquent content model and page types. Admin gives editors a Filament workspace. Frontend connects hydrated data to project-owned presentation. Optional capability arrives as Composer packages through public extension points.

What to inspect before adoption

  • Whether repeated page structures can be expressed as page types and shared layouts.
  • Whether Filament is acceptable for the admin even though public presentation stays independent.
  • Whether anonymous public output excludes model IDs, field paths, permissions, package internals, and signed editor URLs.
  • Whether package migrations, routes, configuration, compatibility, tests, and upgrade guidance are visible before installation.

Capell does not ship a public delivery API, and it is the wrong fit for a non-Laravel stack or a team that rejects Filament. If a few custom resources still cover the work cleanly, keep them. Adopt the shared CMS layer when those resources have started recreating a product surface the team now has to maintain.

How the packages fit together

Capell uses Laravel concepts the team already knows: Eloquent models, service providers, Actions, data objects, policies, views, tests, queues, and Composer packages. The important question is whether each concern stays in its assigned layer as the site grows.

A slim core built to extend Core owns pages, URLs, layouts, and revisions. Capability arrives through public extension points instead of patches to host classes. See the platform map
Admin and Frontend are separate packages Filament editing lives in Admin; visitor output lives in Frontend. Authoring state never leaks into anonymous HTML. See the delivery boundary
Extend page schemas with blueprints Define a page type once, then extend its fields per project through blueprints instead of writing another bespoke resource. See the content model
Event-sourced page history Every save appends a full-state revision: compare a page field by field, roll back, and roll forward without erasing history. Test page recovery
Upgrades are a command, not a project capell:install, capell:upgrade --dry-run, and capell:doctor give every team the same repeatable operating path. Read the upgrade path
The admin your team already knows Capell Admin is standard Filament: resources, schemas, actions, so extending it feels like normal Laravel work. Compare Filament

Which boundary owns the change?

Pages remain Eloquent models. Core appends revisions after PageSaved; Admin provides Page History, field comparison, validated rollback, and roll-forward. Publishing Studio owns isolated workspaces, assignments, comments, approvals, scheduling, atomic releases, and cross-entity recovery.

Read the public event-history contract.

Reusable page structure
Outcome
Keep pages as Eloquent models and build the public site with normal Laravel conventions.
Source
Foundation
Maturity
Released
View evidence
Page history and recovery
Outcome
Keep page-only revision history in Core while pages remain Eloquent models.
Source
Foundation
Maturity
Released
View evidence
Team publishing workflow
Outcome
Keep deeper workflow isolated in an optional package.
Source
Optional package
Maturity
Released
View evidence
AI and agent delivery
Outcome
Track public-safe agent delivery with validation and application-owned boundaries.
Source
Roadmap
Maturity
Labs
View evidence
Automation and integrations
Outcome
Track Laravel-native automation and integration extension points.
Source
Roadmap
Maturity
Labs
View evidence
Experimentation and growth
Outcome
Track structured experimentation and measurement without presenting Labs work as shipped.
Source
Roadmap
Maturity
Labs
View evidence
Trust, compliance, and operations
Outcome
Track application-owned diagnostics, governance, and recovery capability.
Source
Roadmap
Maturity
Labs
View evidence
Customer self-service
Outcome
Track self-service capability built on the existing Laravel domain model.
Source
Roadmap
Maturity
Labs
View evidence

Strict coding standards

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.

Reliability comes from one release workflow

Capell packages are assessed together as one Laravel system rather than solely as isolated downloads.

Automated checks catch repeatable failures, AI-assisted analysis challenges cross-package behaviour and unsupported claims, and an authorised human owns the decision for the exact artifact.

22 of 46 eligible first-party releases currently carry exact-release review evidence.

  1. Boringly explicit package boundaries

    Dependencies, extension points, permissions and public rendering responsibilities stay declared and inspectable.

    Automated AI-assisted

  2. Behaviour before boot tests

    Primary workflows, failure paths, authorisation, public output and lifecycle behaviour need meaningful tests.

    Automated AI-assisted

  3. A human owns the release

    AI can find missed interactions; it cannot issue the public verdict or inherit approval across changed code.

    AI-assisted Human sign-off
Questions

Objections to settle in the code review

Does choosing Filament lock in the public frontend?
No. Filament is the admin UI. Public presentation remains in project-owned Blade, Livewire, Inertia, or custom views. If the team rejects Filament for admin work, Capell is the wrong fit. Compare the Filament boundary
When are custom Filament resources still enough?
Use custom resources for a few stable editable screens. Capell fits when URLs, page types, layouts, previews, revisions, media, and publishing rules have become repeated CMS infrastructure. Compare custom Filament
What is forbidden in anonymous public output?
Public output must not expose model IDs, field paths, permissions, package internals, or signed editor URLs. Tests should prove that boundary for anonymous and non-admin requests. See public-output guardrails
How do we verify an upgrade before release?
Review the package changes, migrations, compatibility notes, and upgrade guide; then run the supported upgrade, diagnostics, focused tests, and application release checks. Read upgrade guidance
What must we plan if we leave or export?
Migration Assistant supports Capell page and site archives. Moving to another CMS requires a tested transformation, a URL and redirect plan, and separate database and media backups. Read the export-and-exit runbook
Loading footer