Build your public site in Laravel

Review ownership decisions Compare WordPress

Choose Blade, Livewire, Inertia, or Vue for the public presentation. Capell resolves approved content and page context; the project's components turn that data into the finished visitor response.

That boundary keeps a future redesign in the application codebase. If several independent channels need one hosted content API, a headless CMS may fit better than this coupled Laravel delivery model.

Own templates Guard editor changes Redesign in code

Actual Capell CMS page types screen showing registered content structures and their available editor actions. — CMS capture: page structure **Page families are defined once.** A real Filament screen showing the registered page structures editors use instead of rebuilding content rules inside each page.

Actual anonymous Capell delivery guide showing the published overview and linked contents in its Laravel-rendered page. — Public page capture **Published content becomes the visitor-facing page.** The published delivery guide brings its overview, explained contents and linked sections into one Laravel-rendered visitor experience.

Build the experience you need

Connect editable pages to the design and application behaviour your visitors expect.

A CMS should make content easier to maintain without deciding every part of the public experience for you. Capell works within a Laravel application, so your team can build the website using the stack that fits the project. The important boundary is between editable content and the code responsible for presentation and behaviour.

Choose this path when the team already builds Laravel pages and wants editors to maintain their content. It replaces hard-coded copy and repeated page forms while keeping design work in the application. It requires a developer to connect the page definition to a template and implement any visitor interaction. An existing enquiry form can remain application code; adding editable content does not require buying a form package or moving the whole site to another framework.

On this page

Keep design changes manageable
Separate the page content from the presentation you will improve later.
Verify what reaches visitors
Review the public result independently of the editing screen.
Use your existing frontend tools
Use one release path for the public experience. Presentation libraries and build tools remain project decisions instead of CMS runtime requirements.
What Capell supplies and what your team builds
See what Capell supplies and what the team still owns. The boundary is concrete enough to test during a redesign, upgrade, or exit assessment.
Changing the design or replacing the CMS
Test the boundary against redesign and exit work. Ownership matters when components change, a channel is added, or the team decides to replace the CMS.

Containers organise the page; widgets and assigned assets supply its content and interactions.

The boundary can be inspected on one page. Capell prepares published content, links, media, and approved package contributions. The application component produces the HTML, applies the design system, chooses asset and cache behaviour, and ships through the normal release path.

A redesign changes project components and shared renderers while the content model remains available. An exit still requires migration engineering, but the public presentation and deployment path do not belong to a hosted builder.

Choose headless instead when multiple independent consumers genuinely need one content API and the extra network, permission, and operational boundary justifies its cost.

Keep design changes manageable

Separate the page content from the presentation you will improve later.

Start with the visitor task and define the information the template requires. Resolve published content, media and page context before rendering. A public view should receive prepared data rather than looking up models or deciding editor permissions while drawing the page.

Share templates for repeated page families and keep unusual application behaviour in the application. Blade is a natural starting point; Livewire, Inertia or a separate frontend can be appropriate when the interaction warrants it. The CMS choice does not make those architectural decisions disappear.

Verify what reaches visitors

Review the public result independently of the editing screen.

A convincing preview does not establish what an anonymous visitor receives. Check the public URL, heading hierarchy, media loading, links and validation. Authoring controls, draft state and internal identifiers should stay outside public output.

Inspect the first viewport and smaller screens, then follow the whole journey through its final action. Where fragments or caches are installed, verify those responses too. Choose performance work based on the real page rather than assuming that changing frontend frameworks will solve every delay.

Frontend toolchain

Use your existing frontend tools

The CMS prepares content and page context. The team keeps its components, asset build, quality checks, deployment, and replacement path.

The stack stays recognisable because Capell is installed into the application, not bolted on as a separate platform.

What Capell supplies and what your team builds

Use this ownership table to name the maintainer for the content schema, editor choices, templates, build, cache, and deploy path.

Scroll horizontally to view the full table.

Decision	Capell	Hosted builder	Headless CMS
Templates	Laravel project owns the public templates	Builder or hosted platform often owns page composition	Separate frontend app owns templates
Content schema	Defined for the Laravel CMS boundary	Often shaped inside the editing tool	Defined in a separate content service
Editor changes	Registered LayoutBuilder widgets and page types protect the public design	Editors may shape layout directly in the visual tool	Editors depend on preview and frontend wiring
Deploys	Normal Laravel release path	Platform release behaviour	CMS deploy plus frontend deploy
Best fit	Laravel sites that need editable structured pages	Small sites where visual control matters most	Many channels consuming one content API

Ownership checks

Changing the design or replacing the CMS

How are editor controls kept out of public pages?

Public templates receive prepared content without editor controls, field paths or private preview state. Core does not depend on Admin. Changes to content, rendering or packages still need review and testing before publication.

Can editors publish without touching templates?

Yes. Editors work with approved page types, widgets, media, previews, URLs, and publishing flow while templates remain in the Laravel project.

Can we query our own content database?

Yes. Capell stores CMS records in the Laravel application's database, so application code can work with the content model directly where that is the right boundary.

Can we leave later?

Capell is not a hosted SaaS CMS. Leaving still takes engineering work, but the content, code, database, and deployment path remain in your Laravel estate.

Do we have to use one frontend stack?

No. Capell can prepare structured render data for Blade, Livewire, Inertia, Vue.js, cached HTML, or custom Laravel views. If the application needs its own endpoint, the application team designs, secures, and operates it.

Is this anti-headless?

No. Headless wins when many channels need one content API. Capell fits when the Laravel app owns the website and needs a real CMS inside that boundary.

Next step

Try the rendering path on one page

Follow the quickstart to trace one editable page into project-owned HTML. Use the headless comparison when multi-channel delivery may change the fit decision.

Ownership matrix The CMS should support the frontend boundary, not replace it.

Build the first public page Price a Laravel-owned build

Role scenarios

What to inspect in frontend delivery

Checks for public delivery, cache behaviour, frontend control, and output safety.

Role-based checks drawn from product capabilities and fit boundaries.

Actual Capell Layout Builder for the agency workflow described.

Check for database queries during cached rendering

Render a cacheable public page that performs a database query. The render should fail visibly in development so a slow query cannot become part of the handed-over build.

The renderer treats a stray query on a cached page as a fault, so delivered performance does not quietly erode after handover. Public presentation stays the Blade and Tailwind the agency owns, not rented from a renderer agency teams cannot touch.

Trade-off to assess: It will not hand a client who wants to design every page a no-code canvas. A hosted builder fits better when the app does not need to own delivery or defend its own speed.

Run this yourself in the demo

Laravel developer representing this editorial scenario.

The renderer polices its own SQL in public — what to verify

Add a database query to a page marked for static caching and render it publicly. Development should hard-fail at the render boundary rather than allow a hidden query or N+1 into production.

A credible evaluation should confirm: The query guard and render contract reject database access, signed admin URLs and Livewire authoring state on cacheable public pages. Trigger each violation and verify that it becomes a diagnosable event instead of entering shared output.

When to look elsewhere: This does not review the application code teams write on top. It guards the render boundary hard, but their own controllers and queries are still theirs to test properly.

Run this yourself in the demo

Site owner representing this editorial scenario.

A dynamic CMS that serves like static files — what to verify

Request a busy cached page repeatedly and compare it with gated content. Public traffic should resolve from a flat-file origin path while personalized access is never frozen into the shared response.

Operational evidence to check: The cache inspects its own output and vetoes itself rather than trusting the app to have stripped editor chrome, so a signed admin URL can never get baked into a shareable page. Site owners get static-file speed without paying for it in leaked private content.

Decision note: This protects the render boundary, not everything. Whatever custom code the site’s developer adds still needs its own care, so site owners do not treat it as a blanket security guarantee.

Run this yourself in the demo

Build your public site in Laravel

Build the experience you need

Keep design changes manageable

Verify what reaches visitors

Use your existing frontend tools

What Capell supplies and what your team builds

Changing the design or replacing the CMS

Try the rendering path on one page

What to inspect in frontend delivery

Capell

How it works

Why Capell

Extensions

View all 82 extensions

Our 6 most popular extensions

Extension suites

Capell

Manage cookie preferences

Build your public site in Laravel

Changing the design or replacing the CMS

Try the rendering path on one page