Installer Module Laravel Package

Product Decisions This Supports

• Build vs. buy for the installation/onboarding step. This package is the reference implementation of a first-run wizard for a Laravel application: environment preflight checks, database credential capture, .env writing, migration/seeding execution, and admin-user bootstrap. If your roadmap includes a self-hosted distribution or an on-prem tier, this is a concrete spec for what that flow must do — regardless of whether you adopt the code.
• Self-hosted vs. SaaS go-to-market. The existence and shape of a web installer is a signal about the distribution model. A mature installer implies a downloadable, customer-operated deployment; if your product direction is SaaS-only, the installer surface is roadmap debt, not a feature. Use this as a benchmark when deciding which tier you actually ship.
• White-label and reseller readiness. Installers are where branding, license acceptance (EULA), telemetry opt-in, and sample-data choices live. If partner/reseller distribution is on the roadmap, this is a useful inventory of the knobs those deals will require.
• Platform ecosystem due diligence. If the team is evaluating the Streams Platform / PyroCMS lineage as a CMS foundation, the installer module is a low-cost probe of the platform's conventions — service providers, module structure, and how tightly add-ons couple to the core. That tells you more about exit cost than any marketing page.
• Onboarding funnel instrumentation. Any install wizard is the first funnel in a self-hosted product: preflight failures, DB errors, and abandoned setups are the earliest drop-off signal you will ever get. Worth owning that instrumentation whether you build or borrow.
• Not supported: general Laravel scaffolding (use Composer/laravel new), multi-tenant provisioning, or billing-driven signup flows. Those are different problems with different vendors.

When to Consider This Package

Adopt or evaluate only when these are true:

• You are already committed to the Streams Platform and need to restore or extend its installation flow. In that context it is a native component, not a dependency decision.
• You want a read-only reference architecture for a Laravel install wizard and are comfortable reading MIT-licensed code and re-implementing the parts you need inside your own app.
• You need to audit what a third-party CMS installer writes to a customer's .env, database, and filesystem before approving it for regulated or enterprise customers.

Look elsewhere — decisively — when any of the following apply:

• You are not on Streams. The module is bound to Streams abstractions (anomaly/* service providers, the Streams Platform bootstrapping model). Pulling it in standalone means pulling in the platform, which is a far larger commitment than the package's footprint suggests.
• You need maintained, general-purpose tooling. Three stars, zero dependents, and a single-vendor origin mean the bus factor is effectively one and the public support surface is nil. There is no community to absorb a breaking change.
• You need provisioning, not installation. For SaaS signup, tenant isolation, or per-customer environments, the correct category is tenancy/provisioning tooling (e.g. stancl/tenancy) or your own orchestration — not a CMS setup wizard.
• You require an SLA, security response commitments, or a support contract. Nothing here implies that, and the low opportunity signal reinforces it.
• You are optimizing for upgrade safety. Anything coupled to a niche CMS core inherits that core's release cadence and breaking-change risk. Budget for it explicitly or don't take it on.

How to Pitch It (Stakeholders)

To executives: This is not a strategic dependency and should not be presented as one — three GitHub stars, zero downstream dependents, and a single-vendor origin place it firmly in the "component of someone else's platform" category. The value is informational: it shows us exactly what a first-run installer for a self-hosted Laravel product has to handle, which is directly relevant if we ship an on-prem or downloadable tier. Recommendation: treat it as a design reference and a due-diligence artifact, not a line item in our dependency budget.

To engineering: Read it, don't vendor it. The useful takeaways are the preflight checklist, the .env write strategy, the migration/seed ordering, and the admin bootstrap sequence — all of which we would reimplement against our own conventions in a few days. Adopting it means adopting Streams Platform conventions and a maintainer with no public support surface, for a problem we can solve natively. If we do want it, scope the work as "extract the flow, rewrite the coupling" and estimate accordingly.

Risk framing in one line: low cost to learn from, high cost to depend on.