Cli Laravel Package

Product Decisions This Supports

• Build vs. buy for deployment automation. Shipper CLI is a candidate for standardizing how Laravel/PHP services get shipped (build → release → activate) instead of maintaining bespoke shell scripts or per-team deploy jobs. v1.0.3 does not change the feature surface; it changes how the tool reaches your pipeline, which is the decision-relevant part.
• Single-binary distribution for CI runners. The standalone shipper binary means deployment steps no longer require a PHP runtime or composer install on the runner. This unlocks use on slim container images, locked-down build agents, and self-hosted runners where installing a PHP toolchain is a security-review or image-size cost.
• Supply-chain assurance as an adoption gate. SHA-256 checksums plus GitHub build provenance let you verify the artifact you execute back to a specific workflow and commit. This supports a "verified artifact" policy in CI and gives you something concrete to put in front of a security reviewer rather than "it's a popular repo."
• Dual-channel install path. Exposing the Composer CLI binary (bin entry) alongside the standalone download means one tool covers two adoption paths: Composer-native teams (local + CI) and binary-only environments. That reduces the "which install method do we standardize on" debate to a per-environment answer.
• Roadmap input on deployment ownership. Whether this sits in your platform team's paved road or stays an opt-in team-level tool. A tool with verified artifacts and no runtime dependency is cheap to make the default; a young 1.x project with a small contributor base is not something to mandate across every service yet.
• Use cases it plausibly serves: scripted deploys from GitHub Actions/GitLab CI, release artifact promotion between environments, and repeatable deploys for small Laravel fleets that don't justify a managed deployment product.

When to Consider This Package

Consider it when:

• You run Laravel/PHP services and deploy from CI today via hand-rolled scripts that only one or two people understand.
• You want deployment invoked as a portable binary — constrained runners, minimal base images, no PHP in the deploy job.
• Your organization has (or is heading toward) artifact verification requirements: checksums and provenance are non-negotiable in your release process.
• You already have Composer-based tooling and want the same tool available locally and in CI without two install stories.
• You are willing to pilot on one or two non-critical services and own the rollback story yourself.

Look elsewhere when:

• You need managed zero-downtime deploys with a UI, one-click rollback, and an audit trail — that is a platform purchase (Laravel Cloud, Envoyer-class tooling), not a CLI.
• You need multi-language or general orchestration beyond PHP app releases.
• You require a long support window, LTS commitments, or a vendor SLA — a v1.x project with a small maintainer group does not provide that; you are accepting maintenance risk.
• You need guaranteed API/CLI flag stability across versions. Nothing in this release speaks to a compatibility policy, and pre-2.0 CLIs commonly change flags.
• Your deployment model needs infrastructure provisioning, not just release activation.

One scoping caveat: the release notes describe packaging, not capabilities. The CLI's actual command set, configuration format, and rollback behavior aren't evidenced here — validate those in a spike before committing to a recommendation.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost lever on deployment reliability. The tool is now distributed as a single verified binary — we can check its SHA-256 and its build provenance before it ever runs in our pipeline, which is exactly the kind of evidence our security review asks for. It removes a PHP toolchain dependency from our deploy jobs, so deploys get simpler and faster to set up. Cost is near zero; the risk is maturity, so we propose a time-boxed pilot on one or two services with a documented fallback to the current process. Success criteria: deploys are reproducible by someone other than the author, and setup time per service drops.

To engineering: v1.0.3 ships the standalone shipper CLI with a checksum and build provenance, and exposes the binary through Composer as well. Practically: chmod +x shipper && ./shipper --version on any runner, no PHP required — or composer if you prefer the familiar path. Verify the checksum/provenance in the pipeline before execution. We treat this as a pilot, not a mandate: pin the version, verify the artifact, and keep the existing deploy path until we've validated the command set and rollback behavior on a non-critical service.