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

How Capell works inside Laravel

Capell separates CMS responsibilities without separating the CMS from Laravel. Core owns the content model, Admin gives editors a Filament workspace, Frontend prepares public delivery, and packages add optional capability.

Start here when you need the whole shape before choosing a page type, writing a widget, installing a package, or planning a migration.

Core Admin Frontend Packages

The platform map is the architectural walkthrough for Capell. It follows a page from CMS records to Filament editing to public rendering, then shows how packages, cache, search, SEO, deployment, and operations sit around that path.

Read it before choosing a page type, writing a widget, installing a package, or planning a migration. It is more technical than a marketing overview because the point is to see the shape the team will maintain.

What it helps you connect

  • How page records, URLs, translations, layouts, and media become public routes.
  • Where editor workflow stops and frontend rendering begins.
  • How LayoutBuilder widgets give editors composition without handing over markup.
  • Where packages add capability without taking over the application.

For a serious evaluation, the boundaries matter more than the feature list. If the map feels heavier than your site needs, that is useful information. If it matches the work you expect to own for years, it is the right next read.

Where Capell fits

Capell is not trying to be every CMS. It fits when owners want lower rebuild risk, editors need guarded publishing, agencies need repeatable delivery, and developers want content, frontend rendering, extensions, and operations to stay inside the Laravel project.

Capell

Content in app
Native
Frontend control
Native
Package trust
Native
Operational health
Native

Strong fit for CMS inside Laravel work.

Custom Filament admin

Content in app
Native
Frontend control
Native
Package trust
Custom work
Operational health
Custom work

Good start, but repeated CMS concerns become custom platform work.

WordPress

Content in app
Separate app
Frontend control
Depends
Package trust
Depends
Operational health
Possible

Mature CMS, weaker fit when Laravel is the product boundary.

Headless CMS

Content in app
Separate service
Frontend control
Native
Package trust
Depends
Operational health
Custom work

Strong API model, but the Laravel team rebuilds much of the site layer.

Hyperreal editorial illustration: A team reading a wall.

How Capell Works

Follow the Capell CMS flow from Core records to Filament Admin, Frontend rendering, package extension points, cache, search, SEO, and public output safety.

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.

Keep your CMS inside Laravel

Capell is not a detached content service. It gives Laravel teams a CMS layer that uses the same codebase, deployment habits, queues, policies, Blade views, tests, and operational checks as the rest of the product.

Your app owns

Routes, Blade, policy, queues

The project keeps deployment, tests, public views, permissions, cache policy, and operational checks in Laravel.

Capell provides

Pages, URLs, languages, layout

Core CMS records, Filament screens, Layout Builder, frontend resolution, and package extension points have a reusable shape.

Editors control

Approved content composition

Editors compose pages from structured records and approved sections without owning the frontend contract.

Avoid scattered CMS glue across plugins, detached APIs, and custom admin hacks.

Keep product code, publishing code, and operational checks close enough to test together.

Core stays lean; capability arrives through packages

The important boundary is deliberate: Core, Admin, Frontend, and Layout Builder provide the stable CMS path. Growth, publishing, search, commerce, operations, and AI capability arrive through focused packages when a site needs them.

Base

Laravel and Filament

The trusted Laravel and Filament ecosystem remains the bedrock.

Host packages

Core, Admin, Frontend, Layout Builder

The required CMS path from modelled content to editor screens and public delivery.

Optional packages

Publishing, SEO, forms, access

Specialist packages plug in when a project needs deeper workflow, discovery, access, analytics, or theme capability.

Public output stays public

Capell can support previews and in-page authoring, but public visitors and crawlers should receive ordinary public HTML. Editor controls are an authenticated post-load concern, not something baked into cached markup.

Admin editor

Editor state stays private

Permissions, locks, revision controls, and editor-only tools stay behind authentication.

Boundary

Public output checklist

No editor controls, model IDs, admin URLs, field paths, internal selectors, signed editor URLs, or package markers.

Frontend

Cached public HTML

The same clean markup works for CDNs, crawlers, anonymous visitors, and authenticated admins.

Trace the public rendering flow

Use this visual when you want to see where content records, layout data, render preparation, cache, and public HTML meet. It belongs in the platform map because the rendering boundary is an engineering decision, not a homepage slogan.

Capell public rendering flow showing structured content moving into clean Laravel public output.
Structured content, prepared render data, cache behaviour, and visitor-safe public output remain part of the Laravel application boundary.

Daily work has a route through the system

Capell is content-first. Editors compose pages from approved records, sections, widgets, and layouts while developers keep public rendering predictable, testable, and fast.

Structure

Page tree and redirects

Content hierarchy, canonical URLs, aliases, and redirect history stay visible.

Composition

Layout Builder

Approved containers and widget assets create responsive pages without copied markup.

Performance

Cache and chrome-lite navigation

Static HTML, render-data caching, chrome-lite Livewire navigation, URL caches, and lazy client behaviour are part of the rendering contract.

Target a sub-2.0s LCP budget for public pages before adding heavier interactive packages.

The ecosystem grows around clear jobs

Capell packages should be grouped by the problem they solve, not by vague plugin categories. That keeps install decisions legible as the marketplace grows.

Authoring

Publishing Studio, Translation Manager

Editor packages add approvals, previews, scheduling, translations, and rollback without changing public delivery rules.

Discovery

SEO Suite, Site Discovery, Search

Discovery packages keep metadata, sitemaps, robots, search, and cache health near content records.

Interaction

Form Builder, Access Gate, Newsletter

Interaction packages add controlled visitor workflows and account-aware paths.

Operations

HTML Cache, Diagnostics, Deployments

Operations packages make cache, health, deployment, redirects, and upgrade work visible.

Roadmap promises stay labelled

Roadmap governance is part of the product story. Public pages should not blur shipped CMS capability, active package work, research, and future ideas.

Now

The core CMS path is the active evaluation surface.

Core, Admin, Frontend, Layout Builder

Shipped

CMS page routing and public rendering

Shipped

Package manifests and install impact

Active

Marketplace browsing and access

Active
Next

Publishing depth and package trust are the next product validation points.

Publishing workflow examples

Testing

Package review signals

Design

Install and upgrade diagnostics

Testing
Later

Research stays labelled until product behaviour and docs prove it.

AI authoring

Research

Translation API

Planning

SEO migration toolkit

Planning
Shipped

Delivered platform surfaces remain visible as shipped evidence, not future promise.

Structured pages, URLs, translations

Shipped

Filament admin editing surface

Shipped

Layout Builder composition

Shipped

Frontend page resolution

Shipped
Public roadmap labels distinguish shipped capability, active work, planned work, and research.

Choose the next step

If Capell looks like the right shape, start with the install path. If you are still comparing options, use the feature and extension pages to test fit before adopting packages.

Fit

Compare the options

Use the fit matrix and feature catalogue to decide whether Capell belongs in this project.

Install

Prove the base path

Install Core, Admin, Frontend, Layout Builder, and a theme before adding specialist packages.

Packages

Add capability deliberately

Choose packages by install impact, support path, and the job they own.

Operate

Keep public output safe

Check cache, redirects, package health, and roadmap state as part of the same CMS workflow.

Questions

New to Capell?

What is Capell?
Capell is a Laravel CMS built on Filament for websites with serious content needs: structured pages, reusable layouts, widgets you approve, publishing flow editors can use safely, public delivery, and features added one Composer package at a time.
Is Capell meant for designers?
Designers can work with Capell through themes, approved layouts, visual direction, and frontend systems while the CMS keeps content structure stable.
Is Capell made for developers only?
No. Developers get the Laravel architecture, but site owners and editors get the practical value: manageable pages, safer publishing, and visible site operations.
How can Capell help me out?
Capell gives repeated CMS work a proper home so teams are not rebuilding pages, URLs, layouts, publishing, redirects, cache, SEO, and package logic from scratch.
Can I use Capell with my existing website?
Yes, when the project is a Laravel app or can move into one. Start with a verified install path, then migrate content and packages deliberately.
What happens when I install Capell?
You install Core, Admin, and Frontend first, verify the Filament workspace and public output path, then add LayoutBuilder, themes, and other extensions only when the site needs them.
How can we reach you?
Use the contact path when you need help deciding fit, discussing a project, reporting a concern, or talking through package and marketplace work.
How can I work with Capell?
You can install Capell, build a site on it, author packages, create themes, or use it as the CMS foundation for long-running Laravel projects.
How can I help Capell?
Use Core, share feedback, donate, buy first-party packages, purchase marketplace extensions, or author trusted packages for other Capell teams.
Loading footer