Learn Capell

Capell CMS, in one place

Use this page as the canonical starting point. Capell is a Laravel and Filament CMS for teams that want structured pages, editor workflow, installable packages, and public output that stays inside the project.

The old overview, what-is, why, comparison, Laravel/Filament, and architecture pages now resolve here. Deeper guides still exist when a reader needs implementation detail, but the public path starts from one clear explanation.

What A CMS inside Laravel. Core stores sites, pages, URLs, translations, layouts, media, and content records. Admin gives editors a Filament surface. Frontend renders approved public output.

Why this matters

Capell is not a hosted page builder or a headless-only content store. It gives Laravel teams familiar CMS records, Filament administration, package extension points, and public rendering controlled by the project.

Overview

Why Repeated CMS work stops being one-off glue. Use Capell when every serious project needs pages, URLs, previews, media, publishing state, package fields, cache, redirects, and operational checks.

Fit check

Skip Capell for a one-page brochure, a free-form design canvas, a commerce-first store, or a hosted content API where Laravel is only one consumer. Choose it when the CMS belongs near Laravel policies, queues, deploys, and tests.

Check fit

Compare Narrower than a general CMS, deeper than CRUD. Statamic, Twill, October, Winter, WordPress, Webflow, and headless tools all solve real problems. Capell is for Filament-first Laravel teams that want package trust and frontend control.

Short version

The closest comparison is not just CMS versus CMS. The question is whether the team wants database records, Filament screens, LayoutBuilder, package manifests, install impact, cache, and operations to live in the Laravel application.

Compare

How The request path stays traceable. A site resolves from the domain, a URL points to a page, translations and layouts provide content, widgets shape output, and the frontend returns the visitor response.

Operational detail

That path is also the debugging path. Developers can inspect records, rerun seeders, test rendering, review package changes, invalidate cache, and change public Blade without reverse-engineering a page-builder blob.

How it works

Install Run the setup path. Install Capell, verify the admin and frontend, then take one page through the first workflow.

Install impact

A useful install proves more than Composer success. It should verify storage, theme assets, admin access, page URLs, a LayoutBuilder section, preview behaviour, public rendering, package discovery, and cache expectations.

Install

Extend Add focused packages. Choose packages by job and install impact instead of treating every CMS feature as core.

Install impact

Packages should make their effect inspectable before install: admin surface, frontend output, migrations, settings, commands, policies, render hooks, support route, compatibility, and rollback expectations.

View packages

Operate Keep the site healthy. Use operations pages for cache, URLs, package health, upgrades, Lockdown, and rollback context.

Operational detail

Operations are part of the product because they are part of the CMS job: redirects, broken links, cache refreshes, imports, package updates, missing translations, security controls, and the notes maintainers need under pressure.

Operate

Choose your path