Setup Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy on installation/setup tooling. This package addresses a real, recurring cost: the "fresh install" path (config publishing, asset publishing, migrations, seeding, environment preflight checks) is where new developers lose hours and where onboarding docs rot. The decision it informs is whether to invest in a first-party, scripted bootstrap (make install, a Docker entrypoint, an Artisan/Console command wrapper) rather than a third-party installer.
• Deployment standardization across environments. The stated value is consistency between local and production. That maps directly to a roadmap item most teams eventually need: a single, idempotent "provision a working instance" step that CI can also run. If you have no such step today, this package is a signal that you need one — but see the caveats below before adopting this one.
• Onboarding time as a tracked metric. "Time from clone to running app" is a legitimate product metric for internal platforms. A setup bundle is a concrete lever on it; the same lever can be built in-house in a few days.
• Scope boundary for your platform team. It helps frame a buy/borrow/build call: does setup orchestration belong in your app repo, your container image, or a vendor package you inherit the upgrade risk from?
• Not a feature decision. This is infrastructure plumbing. It should not influence customer-facing roadmap items, pricing, or positioning. Treat it as an internal engineering-enablement decision with a maintenance-cost line item, not a product bet.

Material caveat the assessment must lead with: the repository metadata and the supplied documentation contradict each other. orkestra-cms/setup-bundle is described as a Symfony bundle, last released 2017-11-13, with 0 stars and 0 dependents; the provided docs describe a Laravel package publishing config/assets and Artisan commands. These cannot both be true. A PM should treat the metadata as authoritative until an engineer confirms otherwise, and should not let a Laravel-flavored write-up create false confidence in a nine-year-old Symfony artifact. Regardless of which reading is correct, the package is unmaintained, unadopted, and predates the current Laravel and Symfony major versions by many releases.

When to Consider This Package

Consider it only as a reference design, not a dependency, when:

• You are building a greenfield CMS or admin platform on top of an Orkestra-style stack and want a checklist of what "setup" actually entails (config publish → asset publish → migrate → seed → environment preflight).
• You need a fast spike to demonstrate a one-command bootstrap and want to see how someone else structured it before writing your own.
• You are auditing an existing legacy project that already depends on it, and need to understand what the installer does so you can replace it safely.

Look elsewhere — in practice, always — when any of the following is true:

• You need a maintained dependency. Last release 2017 with no dependents means no security patching, no compatibility with current framework versions, and no community to answer questions. Supply-chain and audit tooling will flag it; some organizations will block it outright.
• You are on a current Laravel or Symfony version. A 2017-era package will almost certainly declare framework constraints that no longer resolve, or will resolve against abandoned transitive dependencies.
• The framework question is unresolved. Do not adopt until an engineer confirms whether this is a Symfony bundle or a Laravel package; the discrepancy alone is a blocker for any procurement or architecture-review conversation.
• You need determinism in deploys. Setup steps that mutate a live environment should live in your deployment pipeline (Dockerfile, entrypoint, CI job), not in a vendor command you don't control.
• Your platform is already containerized. If docker compose up or a Helm chart already provisions a working instance, a PHP setup bundle adds a second, competing source of truth for initialization.

The reasonable path in nearly every case: spend one to three engineering days writing a thin first-party bootstrap command that does exactly the five steps above, keep it in your repo, and own it.

How to Pitch It (Stakeholders)

To executives (30 seconds): We evaluated a small open-source installer that automates first-time setup of an Orkestra-based CMS. It targets a real problem — new environments take too long to bring online and the steps live in tribal knowledge — but the specific package is a poor acquisition: last released in 2017, zero downstream users, and its own documentation contradicts its repository about which framework it even targets. Recommendation: do not adopt. Instead, fund a small internal task to build the same capability in-house as a single documented setup command. Expected cost is a few developer-days; the benefit is faster onboarding, reproducible deploys, and no dependency on abandoned code.

To engineering leads: The package's scope is right and worth copying — publish config and assets, run migrations and seeders, run environment preflight checks, all behind one entry point. Its implementation is not adoptable: nine years without a release, no dependents, and an unresolved Laravel-vs-Symfony ambiguity in the docs. Propose we build a first-party equivalent: one idempotent command, config-driven, safe to re-run, wired into the container entrypoint and CI so local and production share the same path. Keep the third-party integration behind a thin adapter and a feature flag if anyone still wants to trial it in a sandbox.

To security/procurement: Flag as unmaintained and unadopted. No CVE process, no upgrade path, no community review. If a team insists on trialing it, scope the trial to a throwaway branch with pinned versions, and record the exit criteria (does it resolve on our framework versions? does it run cleanly against a scratch database?) before any production consideration.

Bottom line for the roadmap: Capture "one-command environment bootstrap" as an internal platform deliverable with a clear success metric (time from clone to running app, and setup failure rate in CI). Do not list this package as a solution to it.