Filament Modular Luncher Laravel Package

Technical Evaluation

Architecture fit Filament Modular Luncher is not a library you embed in application code — it is an admin-panel control plane that sits on top of Laravel Modular 1.2 and Filament. Architecturally it assumes:

• A Laravel 12 (and prospectively 13) application with Filament already installed and configured with an authenticated admin panel.
• Laravel Modular ^1.2 as the module manifest/runtime layer — this package is a presentation + operations layer, not a module system itself.
• A filesystem-writable modules directory plus outbound network access (Composer, Git, HTTP) from the web tier if you enable remote installs.

That is a meaningful architectural commitment: the package turns a read-mostly admin surface into a code-mutating surface. For teams already standardizing on Filament + Laravel Modular, the fit is strong and the UI-level features (health badges, ecosystem metadata for requires/conflicts/provides/middleware/policies/events) directly reduce the need for bespoke module-inventory screens. For teams not on Filament, this is a non-starter — adopting it means adopting Filament too.

Integration feasibility Feasible for a mid-sized Laravel team in a single sprint for the read/diagnostic half, with the install path treated as a separate, higher-scrutiny workstream.

• Low-risk, high-value subset: health badges, Module Doctor, Status Report, Debug JSON, Explain Module. These are read-only and immediately useful for triage and onboarding.
• Higher-risk subset: Git/ZIP/URL/Composer installs. These require the app process to hold write access to module directories and outbound network egress. In many managed environments (containers with read-only FS, no egress, immutable images) these actions simply cannot run — which is fine, but should be decided up front rather than discovered at rollout.
• Composer package validation, vendor allowlists, and host allowlists are the right primitives, but the notes describe them as optional — default-off allowlists materially change the risk posture and must be verified in code, not assumed from the changelog.

Technical risk

• Supply chain / RCE-adjacent exposure (highest). An authenticated admin user can cause arbitrary package installation and Git clone. The v1.1.0 hardening (safe process arguments replacing shell interpolation, ZIP traversal and absolute-path rejection, HTTP timeouts and response validation, secret-bearing URL redaction) is exactly the right list and suggests prior versions had genuine injection surface. Any team that shipped ≤1.0.x into a shared environment should treat this as a security-relevant upgrade, not a feature upgrade.
• Ecosystem coupling. Hard dependency on Laravel Modular ^1.2 means your upgrade cadence is bound to another single-maintainer package's release cadence. A breaking 1.3 in Laravel Modular stalls this package.
• Forward-looking CI claims. Laravel 13 and PHP 8.5 coverage in CI implies pre-release targets; passing a matrix against unreleased runtimes is a good signal of intent but is not equivalent to production validation.
• Unquantified quality signals. PHPStan "passed" and Pint "passed" are reported without level or scope; note that Pint was scoped to package-owned paths, so downstream formatting drift is possible.
• Blast radius of a bug. A defect in the install pipeline corrupts composer.json/lock or module manifests on a live app. There is no mention of transactional install, dry-run, or rollback.

Key questions

1. Are Composer vendor allowlists and remote host allowlists enforced by default or strictly opt-in? What happens with an empty allowlist — deny or permit?
2. How are Filament actions authorized? Is there a gate/policy restricting Module Doctor and install actions to a super-admin role, and is it on by default?
3. Is there an audit trail (who installed what, from where, when) and is it immutable?
4. What is the PHPStan level, and what is the actual line/branch coverage of the Pest suite?
5. Are installs atomic? Is there a dry-run, a lockfile diff preview, or a rollback path on partial failure?
6. What Filament major version(s) are supported, and what is the minimum Laravel 12 minor?
7. Who maintains the package, what is the license, and what is the release cadence / security disclosure process?
8. Does it support multi-tenant or multi-panel Filament setups, and can install actions be disabled per-environment?
9. Can the package operate fully read-only (diagnostics only) with install features compiled out or config-disabled?

Integration Approach

Stack fit Good fit only if the target application is: Laravel 12+, PHP 8.3+, Filament-based admin panel, and already (or willing to become) a Laravel Modular ^1.2 shop. Otherwise the dependency chain is too deep for the value returned. Confirm Filament version compatibility before committing — it is not stated in the release notes.

Migration path

1. Pin to ^1.1 explicitly. Do not float on *. The security hardening in 1.1.0 should be treated as a floor, not a ceiling.
2. Phase 1 — diagnostics only. Install, register the Filament plugin, and enable only the read-only surfaces: health badges, Module Doctor, Status Report, Debug JSON, Explain Module. Ship this behind an existing admin role. No filesystem writes, no egress.
3. Phase 2 — observe. Run Phase 1 for two to four weeks across staging and one production app. Validate that module health badges and ecosystem metadata (requires, conflicts, provides, middleware, policies, events) match reality — in particular that conflict detection does not produce false positives on optional/soft dependencies.
4. Phase 3 — gated installs (optional). Only if there is a concrete need. Enable Composer installs first with a strict vendor allowlist; add Git/URL/ZIP only after confirming allowlist enforcement and network egress policy. Keep installs disabled in production if your deployment model is immutable-image.
5. Phase 4 — adopt Laravel Boost guidance (resources/boost/guidelines/core.blade.php) if the team uses Boost; otherwise skip, it is additive.

Compatibility

• Verify Laravel Modular ^1.2 is actually installed and its manifests contain the fields the UI reads. The removeable/removable flag fix is a reminder that manifest schema drift is real — pin Laravel Modular to a minor and re-test on each bump.
• Confirm PHP 8.3/8.4 are the deployment reality; 8.5 support is a forward-looking signal, not a reason to upgrade PHP.
• Check Git/Composer binaries and credentials are available to the web user (not just the deploy user) if installs are enabled. This is frequently the actual blocker.

Sequencing Sequence the security review before the feature evaluation. Concretely: read the install pipeline code for allowlist defaults and authorization gates, then decide scope. Doing this in the reverse order is how teams end up with a control plane in production that any admin can use to pull arbitrary code.

Operational Impact

Maintenance

• Two packages now move together (Luncher + Laravel Modular) plus Filament. Budget for a compatibility check on every minor bump of either. The 1.1.0 notes already show active churn in manifest-field handling — expect continued schema work.
• Optional allowlists are configuration, and configuration rots. Assign an owner for the vendor and host allowlists with a quarterly review; an unreviewed allowlist is worse than none because it implies control that isn't there.
• The resources/boost/guidelines/core.blade.php file is a maintenance surface if you use Boost; treat it as code, review it on upgrade.

Support

• Primary support burden is "install failed" tickets, not "the panel is broken." These are the hardest class of ticket: they involve network policy, credentials, Composer resolution, and disk state simultaneously.
• Secret redaction in failure messages is a genuine support ergonomic win (no more pasted tokens in tickets), but it also means less debuggable output — expect to need server-side logs alongside the UI.
• Ramp-up material exists (upgrades, diagnostics, security docs); assign one engineer to read all three before rollout so the team has an internal escalation point.

Scaling

• Diagnostics surfaces scale trivially; health badges and metadata views are cheap reads.
• The install path does not scale horizontally. On multi-instance deployments, an install triggered on one node leaves sibling nodes with divergent module state until redeploy. Treat installs as a single-node, single-operator operation or move them out of the web tier entirely.
• Disk growth from Git clones and ZIP extractions is unbounded unless you add cleanup. Add a retention policy for install artifacts before enabling remote installs.

Failure modes

• Partial install: Composer or Git fails midway, leaving a half-registered module. Without atomic install/rollback this is a manual repair. Highest-probability operational incident.
• Lockfile drift: an install performed via the UI mutates composer.json/lock outside CI, producing a state no one reviewed and no one can reproduce.
• Network/egress failure: HTTP timeouts now exist (good), but a blocked host produces a failure indistinguishable from a bad URL unless logs are inspected.
• Node divergence: as above, on any multi-instance topology.
• Privilege creep: if action authorization is coarse, any Filament admin becomes a code-deployment operator. This is the failure mode that matters most and the one to independently verify.
• Manifest schema drift: an upstream Laravel Modular change silently breaks conflict/dependency detection, producing confidently wrong health badges — worse than no badges, because operators trust them.

Ramp-up

• Diagnostics-only adoption: roughly half a day for a Laravel-fluent engineer to install, register the plugin, and validate the panel; another day for the team to learn what each action answers.
• Install-path adoption: add one to two weeks, covering authorization review, allowlist configuration, egress/credential setup, and a documented manual repair runbook for partial installs.
• Pre-rollout checklist: confirm allowlist defaults, confirm action authorization gate, confirm single-node or immutable-image topology, write the failure-recovery runbook, and record the pinned versions of Luncher, Laravel Modular, Filament, Laravel, and PHP.

Overall recommendation: Adopt the diagnostics layer; treat the install layer as a separate, security-reviewed decision. v1.1.0 is a clear net improvement — the hardening list is substantive and the diagnostic feature set is well matched to the pain of managing a modular Laravel app — but it should be adopted pinned, gated, and validated for authorization and allowlist defaults before any environment with real credentials sees it.