Site Process Laravel Package

Product Decisions This Supports

• Build vs. buy for remote execution plumbing. This package is a thin adapter between Symfony Process and the Site Alias abstraction (@site.env handles). It answers the question "do we hand-roll SSH/local command dispatch, or adopt a small, composable library that already speaks the Drush/Robo alias convention?" For most teams the answer is adopt — the surface area is small, but re-implementing local-vs-remote transport selection, alias resolution, and option translation is a classic schedule sink for CLI features.
• Multi-environment CLI roadmap. If the roadmap includes any "run this against staging/prod," "deploy to a site," or "sync between environments" capability, this package is the substrate that makes those verbs one-liners rather than per-environment special cases. It determines whether environment targets are a product feature (first-class @alias targets) or a hardcoded config chore.
• Ecosystem alignment / tooling platform bets. This is a Consolidation-ecosystem component — the same family as Drush, Robo, and Terminus. Adopting it is a bet on that convention (aliases, task runners, agency workflows) rather than on a bespoke CLI UX. That's a real product decision about who your CLI is for: Drupal/WordPress agency operators and DevOps-adjacent users, or general-purpose developers.
• Feature scoping for automation surfaces. Because remote calls are expressed as aliases rather than raw connection strings, it enables features like saved targets, per-environment credentials, and "run on all sites" fan-out that would otherwise require a config subsystem.
• Dependency and maintenance risk budgeting. Low stars (52) and a last release in May 2020 understate its role: it's infrastructure pulled in transitively, not a product people star. The decision it informs is less "should we market this" and more "where does this sit in our supply-chain review and upgrade cadence."

When to Consider This Package

Consider it when:

• You are building PHP CLI tooling and need commands to run either locally or on a remote host, selected by a human-friendly target rather than a connection string.
• You are already in the Consolidation orbit (Drush, Robo, Terminus) or building custom commands for Drupal/WordPress agency workflows — the alias convention is already your users' mental model.
• You want Symfony Process semantics (exit codes, timeouts, stdout/stderr capture) without writing transport selection logic on top.
• Your remote transport requirement is essentially SSH plus local — that is the scope here, and it is honestly scoped.
• You value a small, stable, low-churn dependency more than an actively developed one.

Look elsewhere when:

• You need transports beyond local/SSH — container exec, Kubernetes, cloud APIs, WinRM — or structured stream multiplexing; Symfony Process directly is a cleaner base.
• You need a maintained security posture with a regular patch cadence. The 2020 last release and NOASSERTION license metadata (legal will need to confirm; it is generally understood to be MIT) mean procurement and AppSec will ask questions you must answer before shipping.
• Cross-platform Windows parity is a hard requirement for your CLI; validate carefully rather than assuming.
• You are not a PHP shop, or your CLI is a thin front end over an existing orchestration layer (Ansible, Terraform, CI runners) that already owns target selection.
• You only ever execute locally — then this is an unnecessary indirection over Symfony Process.

How to Pitch It (Stakeholders)

For executives: this is not a product; it is a small, well-scoped piece of plumbing that lets our command-line tooling target "staging" or "production" by name instead of by hand-written server details. Adopting it converts a multi-week build into a dependency, and aligns us with the conventions used by Drush, Robo, and Terminus — the tools our agency and DevOps-facing users already know. Cost is near zero; the main caveat is that it is a mature, quiet library with no recent releases, so we should pin the version, confirm the license with legal, and treat it as stable infrastructure rather than something we expect upstream features from.

For engineering: it is a thin wrapper over Symfony Process that resolves Consolidation Site Alias handles and dispatches the command either locally or over SSH. Keep it behind a narrow internal interface so we can swap in Symfony Process directly, or a richer transport layer, if our needs move past SSH/local. Pin to a known version, add it to the dependency review list, and do not expect upstream churn — which is fine for glue code, as long as we own the tests around target resolution and failure handling.