A publishing CMS inside your Laravel app

Choose a separate content platform when several unrelated applications must consume the same content through an API. Capell is coupled on purpose: it belongs inside the Laravel application.

Capell Foundation has no public content-delivery API, and the optional API package (beta, free) only returns read-only JSON for published pages. That is a decision, not a gap. The application resolves a page, hydrates its content and renders it with its own stack, which is exactly wrong for a mobile app, a second website and a kiosk all reading one shared content store.

If your architecture is headless, a headless platform will serve you better, and this question should save you the pilot.

Yes. Public checkout is open for paid Marketplace products. Foundation remains available under the MIT licence without a purchase.

Install Foundation from public Packagist releases, or review a paid package's published terms and pricing before buying it through the Marketplace.

If your plan needs a paid package in production this quarter, review its release status, compatibility and licence terms before adopting it.

It can be when the sites share a delivery method and your team values repeatable upgrades, Page recovery and reviewed packages. Confirm the licence and package fit before standardising.

The agency case is where the shared model pays twice: page structures, workflows and packages proven on one client site carry to the next, and upgrades run as the same commands on every project without five bespoke procedures.

Standardising is also where a wrong fit multiplies by five, so run the disqualifying questions on this page against your actual client mix first, not against the site you happen to be building this month.

Capell is founder-maintained, and its paid commercial programme is early. The Foundation source is MIT licensed, paid-package continuity terms are published, and the current operating limits are stated plainly.

Weigh what the licences actually guarantee, not what a roadmap promises. Foundation being MIT means the code your sites run cannot be taken away or re-licensed out from under you; the continuity terms state what happens to paid packages you have already installed if entitlement lapses.

Then weigh the honest residual: a small maintainer surface is a real concentration of knowledge, and no licence fixes that. If your organisation requires a vendor with a support bench today, that is a legitimate reason to choose differently.

Build directly with Filament when a few resources and custom pages are enough. Choose Capell when Pages, URLs, Page history, layouts, themes, publishing and package lifecycle should share one maintained contract.

The test worth applying is who maintains the contract. A hand-built Page resource is yours to evolve: every URL rule, revision behaviour and layout convention added later is code your team designs, tests and upgrades. With Capell those contracts arrive maintained, and your additions plug into them through packages.

The comparison page walks a concrete requirement list through both routes; take the list, not the conclusion.

Staying put is a valid outcome. Keep the current CMS when it already fits the team, the migration cost exceeds the maintenance cost, or the paid commercial programme's early stage adds risk you do not need.

Migration cost is mostly not the content transfer; it is retraining editors, rebuilding integrations and rebuilding the operational confidence your team has in the current system's failure modes. Price those honestly before comparing feature lists.

The migration guides here start from the same premise: name every consumer of the old system before removing anything. If working through that exercise shows the current CMS still fits, you have lost an afternoon, not a quarter.