See a package's production footprint before installing it
Take Publishing Studio as the representative package. When Publishing Studio is installed and licensed, it adds coordinated team workflow around the standard page-history foundation. Before adoption, inspect its marketplace maturity, Composer constraint, provider, migrations, configuration, admin surfaces, jobs, public effects, diagnostics, and support path.
Install it on a representative page, test the editor workflow and anonymous response, plan the release checks, then document upgrade and removal. Removing a Composer dependency does not decide what happens to retained data; the package guidance and application team must make that choice deliberately.
Only approved, visible marketplace listings are current install options.
Choose packages by job, but judge each one by its production lifecycle. Check the current marketplace listing, maturity, compatibility, install footprint, public surface, support, and operational signals before Composer changes the application.
Install on a representative content flow, run migrations and setup deliberately, verify the editor and public result, and add the package to deployment, health, upgrade, and recovery checks. Removal needs a plan for routes, jobs, configuration, package-owned content, and retained data.
These are capability categories, not a promise that every named package is released. Marketplace visibility and the displayed Stable, Beta, or Labs label are the adoption boundary.
Follow the package lifecycle, not the catalogue
Choose packages by job, then run the same lifecycle regardless of whether the capability is workflow, search, a theme, diagnostics, or another bounded extension.
Run one package through the whole lifecycle
Review a package lifecycle against a current marketplace listing, then use the developer route to inspect the extension boundary behind it.
Package boundary Capability arrives through Composer packages, manifests, setup commands, migrations, hooks, and tests.
Make adoption depend on visible evidence
Capell packages should behave like serious Laravel dependencies. Before a package changes a live CMS, the team should understand what it registers, what it stores, what it renders, and how it affects cache, search, workflow, and operations.
Scroll horizontally to view the full table.
| Area | Capell shape | Developer check | Team outcome |
|---|---|---|---|
| Install impact | Packages can add migrations, config, routes, commands, resources, views, and render hooks. | Read the manifest and review setup steps before installing. | Teams know whether a package is lightweight or operationally significant. |
| Public surface | Packages may contribute frontend blocks, forms, search, SEO, or gated experiences. | Verify what can render publicly and whether the output is cacheable. | Visitors get useful features without accidental exposure. |
| Maintenance | Capability stays versioned through Composer instead of patching core. | Track updates, compatibility notes, and rollback requirements like any dependency. | The CMS can grow without becoming un-upgradeable. |
| Marketplace trust | Listings should show capability, support, compatibility, screenshots, and safety signals. | Prefer packages with clear evidence over vague feature claims. | Buyers and developers can evaluate risk before install. |
Review the footprint before and after installation
Install footprint
A package should say what setup work it needs, what capability it adds, and whether the team must plan data, queue, search, or cache changes before deploying.
Browse extensionsPublic surface
If a package contributes forms, search, SEO, themes, gated experiences, or rendered blocks, confirm the visitor output remains clean, cache-aware, and owned by the application.
Render rulesOperational cost
Look for clear expectations around compatibility, rollout, rollback, diagnostics, and long-term support. Optional CMS capability still becomes production software once installed.
Site operationsExtension boundary
Shared CMS behaviour belongs in package extension points; project-specific business rules still belong in the Laravel app. That split keeps packages reusable without swallowing the product.
Browse released extensionsBuild to the standard the catalogue reviews
Package architecture, lifecycle behaviour and interoperability need evidence before marketplace claims do.
Keep UI layers thin, move domain work into Actions, cross boundaries with typed data, and make installation, migrations, permissions, public output, operations and removal testable.
22 of 46 eligible first-party releases currently carry exact-release review evidence.
-
Actions and typed boundaries
Domain work belongs in Actions or services, with structured input and output crossing layers through Data objects.
Automated AI-assisted -
Manifest and migration integrity
Commands, settings, contributions, migrations, permissions and retained data must match reachable lifecycle code.
Automated AI-assisted -
Interoperability over isolation
Declared dependencies and optional companions are exercised with the catalogue and supported Capell release family.
Automated AI-assisted Human sign-off