Installer Laravel Package

Product Decisions This Supports

Build vs. buy on the admin/back-office layer. The installer is the cheapest possible on-ramp to Orchestra Platform, a Laravel-based admin and extension framework. Running orchestra install my-app produces a working reference product in hours — a real admin UI with authentication, authorization, schema, and an extension model — that can be compared side by side against (a) assembling an admin layer from Laravel plus our own packages, and (b) a commercial admin-panel vendor. The installer is not the decision; it is the fastest way to manufacture the artifact the decision requires.

Time-to-first-screen as a comparable metric. A single command bootstraps a complete Orchestra application, which yields a hard number: how long until a developer has a running admin UI with auth, ACL, and schema in place? That number is directly comparable against our current greenfield Laravel scaffold and against vendor demos, and it is a legitimate input to roadmap conversations about developer onboarding cost and DX investment.

Whether to standardize an internal "golden path." If internal dashboards, CRUD back-offices, and content-managed apps are recurring demand, this package is a candidate template for a standard scaffold. It informs the choice between adopting an off-the-shelf scaffold, maintaining an internal starter kit, or leaving scaffolding to individual teams.

Sizing the maintenance burden we would inherit. Installer friction — PHP/Laravel version constraints, the absence of standalone documentation, the interactive-only prompt flow, no resumable failure recovery — is a proxy for the operational cost of adopting the platform. Poor ergonomics is a signal to budget internal DX work or to reject the platform outright, and it belongs in the adoption estimate rather than being discovered during delivery.

Risk register and dependency posture. Effectively zero stars and zero dependents place this squarely in the unproven/at-risk tier. That is a concrete input to a bus-factor note and to a standing rule: developer tooling only, never a production runtime dependency. If it appears in a generated composer.json, something went wrong.

Prototyping, discovery workshops, and stakeholder demos. Rapid spin-up of an admin surface for POCs where the goal is to demonstrate CRUD flows and permissions quickly — not to ship production code. Scriptable end to end, so any laptop produces the same demo.

One caveat that changes the math. v5.2.0 added AuthorizationCreated and SchemaCreated events, which tells us the installer performs real provisioning — ACL/authorization setup and schema creation — not merely a composer create-project wrapper. That moves it from "disposable convenience" to "the owner of setup logic we would otherwise have to reproduce by hand," and the cost of that reproduction belongs in the build-vs-buy calculation from day one.

When to Consider This Package

Consider it when:

• The team has already chosen, or is seriously evaluating, Orchestra Platform on top of Laravel. The installer is the intended on-ramp; hand-rolling the bootstrap buys nothing.
• You need a throwaway or timeboxed evaluation environment — a spike to judge the platform's admin conventions, extension model, and UX before committing engineering time.
• You want repeatable scaffolding for demos and POCs where consistency across machines matters more than long-term maintenance.
• You are already standardized on PHP/Laravel and Composer, so the installer introduces no new runtime paradigm or toolchain for the team to learn.
• The product genuinely needs an admin UI surface — that is where Orchestra's value is concentrated.

Look elsewhere when:

• You are starting a plain Laravel application — use laravel/installer; there is no reason to route through an Orchestra-specific bootstrap.
• You need actively maintained, widely adopted scaffolding. Zero dependents is not proof of poor quality, but it is proof of no community safety net — no Stack Overflow corpus, no third-party fixes, no posts on the v5.2.0 events. Do not put it on a critical path.
• The product is API-first or headless. If we do not need the admin surface, the installer buys us nothing.
• You require commercial support, a security review, or a published release cadence — none of which this package evidences.
• You need non-PHP or multi-stack bootstrapping; this is Laravel-only by construction.
• You need CI-native, non-interactive provisioning. It prompts for DB credentials and admin user details with no documented --no-interaction mode. Commit the scaffold instead of regenerating it in the pipeline.

Guardrails if adopted: pin the version (orchestra/installer:^5.2) and record the exact installer, PHP, Laravel, and Orchestra Platform versions in the project README — that four-way matrix will bite you otherwise; install strictly as global developer tooling, never as a production dependency, and audit the generated composer.json to confirm it did not leak in; generate the scaffold once, git init, commit, and never let the installer touch the repo again; run --force only against an empty, disposable target directory since there is no dry-run and overwrite is unforgiving; run it in a dev container or dedicated VM rather than a machine holding production credentials; and document a fallback path to a hand-maintained skeleton that reproduces the AuthorizationCreated and SchemaCreated provisioning steps. That runbook is the single most valuable artifact from any installer spike.

How to Pitch It (Stakeholders)

For executives: This is a free, open-source command-line installer for a Laravel-based administration platform. It costs nothing to try and carries no license obligation. Its value to us is as a low-cost evaluation accelerator: it stands up a realistic admin/back-office prototype in hours instead of weeks, which is the fastest way to get a defensible answer on whether to build our admin layer, buy a commercial product, or adopt this framework. The deliverable of the pilot is not code — it is a decision-grade comparison plus a documented fallback runbook. The risk is contained by design: it is a developer tool, never shipped to customers, and we commit the generated scaffold rather than depending on the binary.

For engineering: Treat orchestra install as a bootstrapper, not a build step. It is a global Composer binary — nothing in composer.json — that wraps skeleton fetch and provisioning: migrations, admin user creation, core extension registration, and, as of v5.2.0, authorization/ACL and schema creation. That provisioning is the actual value and the part we would otherwise reimplement. Because of that, composer create-project orchestra/platform is not an equivalent substitute — the ACL and schema steps simply do not happen.

Practically: install into a dev container, run it once into a throwaway directory, and read the console transcript — it is the best available documentation. Pin the installer alongside PHP, Laravel, and the platform, and record the matrix in the README. The extension surface is exactly two events (AuthorizationCreated, SchemaCreated); there is no plugin system, no config file, and no other hooks, so don't go hunting. Failures are not resumable — delete the partial directory, check for stray .env files and orphaned databases, and start over. Headless and CI usage is constrained by interactive prompts; the correct pattern is to scaffold locally and commit.

Finally, budget debugging time honestly. With zero dependents there is no community safety net; when it breaks, the fix usually lives in the platform source rather than the installer's, because the installer is orchestration and the interesting logic is downstream. Write down the manual fallback — composer create-project plus a reproduction of the authorization and schema provisioning — before the spike ends, not after the tool goes stale.