Installer Laravel Package

Technical Evaluation

Architecture fit. orchestra/installer is not a library you integrate — it's a global Composer binary that scaffolds an Orchestra Platform application. Architecturally it sits outside our production topology entirely: it is a one-shot bootstrapper whose output (a Laravel app with admin UI, auth/ACL, schema, and extension registration already provisioned) is what actually enters our architecture. That distinction drives every downstream conclusion. Fit is therefore conditional on one thing: whether Orchestra Platform itself is a candidate for our admin/back-office layer. If the answer is no, this package has zero architectural relevance. If the answer is "we should evaluate it," the installer is the correct on-ramp, because the alternative is reproducing the AuthorizationCreated and SchemaCreated provisioning by hand — and those two v5.2.0 events prove the installer owns real setup logic, not just a composer create-project wrapper.

Integration feasibility. Straightforward mechanically and low-blast-radius if scoped as developer tooling. Requirements are PHP, Composer, a reachable database, and a PATH entry for the global bin directory. Everything after orchestra install is a normal Laravel app: Artisan, Composer, and the team's existing test tooling all work unchanged. The feasibility constraint is not technical difficulty but process discipline — keeping the binary out of composer.json, generating once, and committing the result.

Technical risk. Concentrated in four areas, in order of severity:

1. Bus factor / adoption risk. Zero stars, zero dependents, no community corpus. There is no Stack Overflow safety net for the v5.2.0 events and no third-party fixes. When it breaks, the options are reading src/Console/ and src/Installation/, or filing an issue and waiting.
2. Hidden coupling to setup logic. The provisioning steps are the package's value and its lock-in. Skipping the installer means reimplementing ACL/authorization and schema creation ourselves; the fallback path is more expensive than it appears from the README.
3. Silent version drift. The installer selects the skeleton version. A stale installer yields a stale skeleton, which surfaces as cryptic Composer resolution errors that look like installer bugs but are PHP/Laravel/Platform constraint failures. This is a four-way matrix (installer × PHP × Laravel × Orchestra Platform) that must be pinned and documented.
4. Supply-chain and privilege surface. It runs with the invoking user's privileges, hits the network, and writes to a database including ACL provisioning. Running it on a workstation holding production credentials is an avoidable exposure.

Key questions to resolve before committing engineering time:

• Are we evaluating Orchestra Platform at all, or is this a solution in search of a problem? No admin-surface need means no reason to proceed.
• What is the measured time-to-first-screen versus our current greenfield Laravel scaffold? That delta is the only defensible ROI number here.
• Does the generated app's composer.json stay clean of the installer, and what exactly does each provisioning step create (tables, roles, permissions) that we'd have to reproduce?
• Is orchestra install viable non-interactively? No --no-interaction mode is documented, which likely forecloses CI-native regeneration and forces the commit-the-scaffold pattern.
• Who owns the internal fallback runbook, and is that ownership funded? Without it, onboarding breaks when a zero-adoption tool rots.

Integration Approach

Stack fit. Native fit only if we are already a PHP/Laravel/Composer shop — which we are — and only for the admin/back-office use case. It introduces no new runtime paradigm, no new language, and no new CI toolchain. For an API-first or headless product this is a non-fit by construction; laravel/installer is the correct choice for a plain Laravel app.

Migration path. There is no migration — there is a decision gate followed by a scaffold. The sequence is: spike in a disposable environment, generate a reference app, evaluate the resulting admin UX/extension model against building our own or buying commercial, then either adopt a committed scaffold as an internal golden path or walk away with a documented runbook. Crucially, the artifact under evaluation is the generated application, not the installer.

Compatibility. Governed entirely by the four-way version matrix. Pin orchestra/installer:^5.2 explicitly — composer global require grabs latest by default, which is how teams get the silent skeleton drift described above. Record the exact installer, PHP, Laravel, and Orchestra Platform versions in the generated project's README at scaffold time, not retrospectively. The extension surface is exactly two events (AuthorizationCreated, SchemaCreated) with no config file, no plugin system, and no pluggable providers — plan customization around those two hooks or plan to post-process the app.

Sequencing.

1. Spike (timeboxed). Install in a dev container, not a workstation. Run orchestra install into a throwaway directory and read the console transcript step by step — that transcript is the best available documentation of what the tool does to a machine.
2. Pin and capture. Lock the version, scaffold, immediately git init + initial commit, and record the version matrix.
3. Evaluate the output. Benchmark time-to-first-screen; assess admin conventions and extension model against alternatives.
4. Customize via events if adopting. Register AuthorizationCreated / SchemaCreated listeners in an internal template or install-time service provider — scaffold customization, never runtime behavior.
5. Write the fallback runbook. Manual composer create-project steps plus a reproduction of the authorization and schema provisioning. This is the highest-value deliverable regardless of the adopt/reject outcome.
6. Standardize only if the demand is recurring. If internal dashboards and CRUD back-offices are a pattern, promote the committed scaffold to a golden-path template; otherwise leave scaffolding to individual teams.

Anti-pattern to forbid explicitly: regenerating the scaffold in CI. It couples the build to a low-adoption global binary and to upstream skeleton drift.

Operational Impact

Maintenance. Near-zero if used as intended (generate once, commit, never re-run) and near-total if used as a build step. The real maintenance burden is the fallback skeleton: once we depend on the generated app, we own a hand-maintained equivalent for the day the installer breaks. Budget that as an ongoing cost, not a spike artifact. The installer itself has no maintenance obligation we can influence — no release cadence is evidenced.

Support. Effectively none externally. Zero dependents means no community answers and no third-party patches; internal support means reading src/Console/ and the Orchestra Platform docs, because the installer has no standalone documentation — its behavior is documented as the platform's installation chapter. Escalation path is a GitHub issue with an unknown response time. Treat any commitment to this package as a commitment to self-support, and staff the spike accordingly. Commercial support, security review, and published cadence are all absent.

Scaling. Not a meaningful axis for the installer — it runs once per project, not per request. Scaling concerns belong to the generated Orchestra Platform app and should be evaluated there. The one scaling-adjacent property that matters: if we standardize a golden path, every new project inherits the pinned matrix, so a stale template propagates stale versions across the org at once. Central ownership of the template version is the mitigation.

Failure modes. Well understood and uniformly manual:

• Mid-install death (composer step, migration, admin user creation): no documented resume, no persisted inter-step state. Recovery is delete the partial directory, hunt stray .env files and orphaned databases, start over. Half-completed installs leave cleanup work by hand.
• --force overwrite: no dry-run; the installer wants an empty target. Never point it at anything we care about.
• Database unreachable at start: the installer prompts for credentials and immediately migrates and seeds. Have the DB up, schema clean, and migration permissions ready before invoking.
• Skeleton drift: manifests as Composer resolution errors misattributed to the installer.
• Leaked runtime dependency: if orchestra/installer appears in the generated composer.json, something went wrong — audit it post-scaffold every time.

Ramp-up. Low for anyone with Laravel habits, and the mental model to teach is narrow: orchestra install ≠ composer create-project, because it also runs provisioning. The genuinely hard part isn't the tool, it's the two traps — assuming vanilla Laravel scaffolding is equivalent, and assuming a headless path exists. Onboarding cost is one containerized spike plus reading the console transcript. The durable onboarding asset is the fallback runbook, which is what keeps new-project setup working after this tool goes stale.