Find the package for the work
A useful extension removes work the team already understands. Open its listing for maturity, supported versions, data and migration impact, visible surfaces, access terms, support, and removal guidance.
Stable listings are current adoption options; a listed Beta requires an explicit decision. Packages still in preview are product direction, not an install option.
Stable or Beta status
Visible production impact
Public or paid access
Use the marketplace when a repeatable package can remove a named piece of CMS work. The live listing is the adoption contract: current maturity, compatibility, surfaces, data access, migrations, jobs, support, licence, access, and removal guidance.
Capell Foundation is distributed through public MIT-licensed packages. Paid catalogue packages remain proprietary commercial software and use entitlement-scoped Composer access. Stable and explicitly accepted Beta listings are current options; preview-only packages are not.
Every first-party extension is reviewed against one published review standard, and each listing states its migrations, routes, jobs, permissions and removal impact before you install it.
Before installation
- Confirm the package solves a requirement the team already understands.
- Inspect what changes for editors, visitors, data, deployment, and operations.
- Check compatibility, support, advisories, access, and retained data.
- Test the representative workflow and removal path away from production.
Choose a short starting set
Featured placement is a discovery aid, not a recommendation for every project.
One reviewed Laravel package catalogue
Use a smaller catalogue, reviewed as one Laravel system. First-party, publisher verified, Stable, Beta and Capell reviewed remain separate signals.
Capell reviewed applies only to the exact package release that passed automated checks, AI-assisted analysis and authorised human sign-off. Changed code must pass again, and review reduces risk rather than guaranteeing permanent security.
-
No database queries in public views
Public Blade receives complete hydrated render data without Eloquent, DB access or lazy-loading fallbacks.
Automated AI-assisted -
Declared package boundaries
Dependencies, contributions, migrations, permissions and removal behaviour must match reachable package code.
Automated AI-assisted -
Exact-release accountability
Artifact and manifest hashes bind the evidence to one version before a human reviewer owns the release decision.
Automated AI-assisted Human sign-off
Loading section
Compose capability through Composer, not by patching Core
A package publishes its own routes, jobs, settings, and Filament resources through Capell's manifest-declared extension points. Composer resolves the dependency; the manifest declares what the package touches, what it caches, and what it costs to render.
Nothing here bypasses Core. A package that outgrows its boundary is a signal to review it, not a reason to fork Core to make room for it.
Extension workflow
See package-led capability in practice
Follow package selection, review signals, an Admin workflow, and the explicit extension boundary that keeps project code maintainable.
A narrated walkthrough of Capell's package-led extension model.
Package adoption signals
Stable and Beta listings are current install candidates when the project's access allows them. Incomplete work stays preview-only or withheld until its marketplace readiness has been assessed.
capell.json # capell-app/access-gate, manifest-version 3
version "1.0.0"
product { group, tier, bundle } # where it sits commercially
surfaces ["admin", …] # where it is allowed to appear
dependencies { requires, supports, conflicts }
contributes [ 14 entries ] # every resource, page and widget it adds
database { migrations, settings, requiredTables }
permissions [ 13 entries ] # e.g. "View:Area"
security { riskTier, publicSurface, sensitiveData,
publicOutput, externalHttpClients, adminSurface }
performance { frontendRenderBudgetMs, adminQueryBudget,
cacheTags, cacheSafety }
healthChecks [ 1 entry ]
commercial { proposedLicense, supportPolicy, … }Real fields from a released package's capell.json, shortened for reading. Because the listing renders this record, install impact, public surfaces, permissions and removal effect can be read before installation instead of discovered after it.
Browse by job
Use a group to narrow the search to the area of work you need.
Preview packages not yet listed on the marketplace
Use these entries to understand possible future capability and to give roadmap feedback. They are not available marketplace installs. Depend only on packages with an approved visible listing and an explicit Stable or Beta maturity label.
Next step
One package for a real requirement
Adopt one package from a real requirement. Carry a short list into the live catalogue.
If no listed package solves the job cleanly, keep the work in project code or wait. A larger catalogue is not a reason to install more dependencies.
Extension planner
A job-based package shortlist
The planner connects publishing, discovery, forms, migration, operations, theme, and growth requirements to likely packages. It explains the match; it does not replace maturity, compatibility, access, or impact review.
Planner
01 / 03
capell extension install planner
The required editorial workflow
The main post-launch risk
Start with these extensions
Recommendations will appear after the last answer.
Also recommended
The required editorial workflow
The main post-launch risk
“Role-based checks drawn from product capabilities and fit boundaries.”
What to inspect before adding packages