How Capell fits into Laravel
When content rules are spread across models, resources, templates and add-ons, a change becomes a search for the real owner. Capell assigns each concern to Core, Admin, Frontend or a package.
Use the four boundaries below to see what Capell maintains, what stays in your application, and how one Page moves from definition and editing to public response and recovery.
Trace the Core, Admin, Frontend, and Packages boundaries through one maintainable Laravel CMS.
Watch on YouTubeA website that is easier to maintain
Connect editing, design, publishing and packages around the pages your team actually needs.
The platform makes most sense as one page journey: an editor changes clear content, a shared layout presents it, the application delivers it and the team can inspect or recover the change. The four platform areas explain those responsibilities without requiring you to adopt every optional feature.
For an agency or product team, that means the next campaign can reuse a maintained page pattern and editors can work inside a familiar publishing environment. Start with the part of the journey that currently costs your team time: repeated content, inconsistent presentation, a difficult release process or an application integration. The examples below show where each responsibility belongs and what to inspect before choosing an optional package.
On this page
-
Follow one useful page
See how the pieces support a real editorial and visitor task.
-
Start small, grow deliberately
Choose capabilities because they remove a demonstrated problem.
-
The four parts of a Capell application
Each part owns a different part of the publishing path, with explicit crossings between content, editing, delivery, and optional capability.
-
One page, from draft to live
Five existing product captures follow one page from its reusable definition to the public response and the package capability around it.
-
Explore Capell
Read about page editing, public rendering, packages and publishing.
-
What is included, optional, or planned
Availability is resolved from Capell's shared capability catalogue rather than inferred from a broad platform claim.
Capell has four parts: Core stores content, Admin gives editors a Filament interface, Frontend connects content to the public site, and optional packages add features.
Follow one useful page
See how the pieces support a real editorial and visitor task.
Choose a campaign and identify what changes from one campaign to the next. Its page type defines the editable information, its layout supplies the presentation and its public route leads the visitor to the offer. A form or application action belongs where the visitor is ready to respond.
Then follow an update through preview, publication and Page history. That makes the boundaries visible: content changes are not automatically code deployments, and optional review or layout packages should be selected for the requirement they meet.
Start small, grow deliberately
Choose capabilities because they remove a demonstrated problem.
Foundation provides the publishing base. Layout Builder, Publishing Studio and other packages add deeper workflows as needed. Check the current scope and licence of each package rather than inferring availability from a screenshot of a fully configured site.
Keep a clear owner for configuration, upgrades and the public experience. A small set of well-understood capabilities is easier to hand over than a large installation with no explanation of why each part exists.
The four parts of a Capell application
Core
Pages, URLs, revisions, translations, media, layouts, and extension points form the durable content model.
Filament Admin
Approved fields, media, composition, preview, and Page History give editors a focused publishing workspace.
Your frontend
Blade, Livewire, Inertia, Vue.js, or a custom Laravel stack turns hydrated content into clean anonymous HTML.
Packages
Composer-installed packages add manifest-declared capability without moving project rules into Core.
One page, from draft to live
Define the page and its type
Core connects the page to a reusable type, URL, translation, and layout before composition begins.
See page-building pathsEdit and preview in Filament Admin
Editors change approved fields and composition, then preview the real page shape before the public version changes.
Follow the publishing workflowPublish with recovery visible
Page History records the change and supports validated rollback or roll-forward; Publishing Studio adds coordinated review when installed.
Watch draft to rollbackServe the public response
The Laravel application returns clean visitor HTML through its own frontend, cache policy, URLs, metadata, and navigation.
See public deliverySee what a package adds
A package can add a bounded feature such as scheduled access while its manifest, install impact, public surface, and removal path stay inspectable.
Trace the package lifecycleExplore Capell
Start with the change that has to remain maintainable: a repeatable page family, a higher-risk publish, a public response, a discovery requirement, a growing set of sites, or a new package. The right detail page gives the team a smaller evaluation surface and a direct route back to the platform map.
What is included, optional, or planned
Foundation capability ships with the standard stack. Optional capability is named only when its approved Marketplace record is publicly available. Roadmap work links to its current public item.
Reusable page structure
- Outcome
- Own structured pages, layouts, and public rendering inside the Laravel application.
- Source
- Foundation
- Maturity
- Released
Page history and recovery
- Outcome
- Compare, restore, and roll forward page changes without erasing history.
- Source
- Foundation
- Maturity
- Released
Team publishing workflow
- Outcome
- Add isolated workspaces, review, approvals, scheduling, and atomic releases.
- Source
- Optional package
- Maturity
- Released
Referral reporting
- Outcome
- See which external sources bring visits to your Capell site using aggregate referral counts.
- Source
- Optional package
- Maturity
- Beta
AI and agent delivery
- Outcome
- Track safe discovery, validation, preview, and controlled agent-assisted delivery.
- Source
- Roadmap
- Maturity
- Labs
Automation and integrations
- Outcome
- Track auditable automation that connects content operations to the wider application.
- Source
- Roadmap
- Maturity
- Labs
Experimentation and growth
- Outcome
- Track structured experimentation and measurement without presenting Labs work as shipped.
- Source
- Roadmap
- Maturity
- Labs
Trust, compliance, and operations
- Outcome
- Track operational trust and governance capability for long-lived applications.
- Source
- Roadmap
- Maturity
- Labs
Customer self-service
- Outcome
- Track customer-facing account capability integrated with the application the customer owns.
- Source
- Roadmap
- Maturity
- Labs
Next step
Try the live demo before installing
Use the read-only demo to follow content from the admin to the published page, then decide whether the split suits your team.
In the demo, find a page structure, inspect Page History, open the public result, and identify which capability comes from a package. Use the route map above for the deeper evaluation before installation.