Product Decisions This Supports
- Deployment ergonomics as a feature, not infrastructure. This package wraps Envoyer's deployment trigger in console commands, so a deployment can be kicked off from the app itself, a scheduler, or a CI job instead of a human opening the Envoyer dashboard. That directly supports roadmap items like "one-click/automated deploy," "post-deploy sync," or "deploy the downstream app when this content changes."
- Build vs. buy (small scale). The package is thin glue over an existing paid service. Adoption cost is one
composer require; removal cost is nearly zero. That makes it a tactical decision, not an architectural one — it should never be the reason you choose Envoyer, but it removes friction once Envoyer is chosen.
- Chained / multi-app deployments. The most defensible product use case: a Laravel app or WP install (Acorn/Sage stacks are this maintainer's home turf) triggering a deploy of an adjacent app, or a staging refresh triggered by an admin action. This is the kind of automation that's tedious to build and cheap to consume.
- CI gating. Lets a pipeline trigger a deployment as a discrete step with a real exit code, rather than a fire-and-forget
curl in a shell script — useful when you want deploy-on-green-main without granting the pipeline dashboard credentials.
- Non-decision. This release (v1.1.4) is a maintenance drop — a Laravel 12 dependency bump, no features, no breaking changes. It confirms the package stays installable on current Laravel and is still maintained; it does not justify new roadmap investment on its own. Treat it as a "keep the dependency current" item.
When to Consider This Package
Adopt when:
- Envoyer is already your deployment service, or is a finalist, and you want deployments triggered from code/CLI/scheduler rather than by hand.
- The need is narrow and scriptable: trigger a deploy, chain a deploy, deploy from CI — not orchestrate one.
- You're on Laravel 10, 11, or 12 (v1.1.4 explicitly bumps dependencies for Laravel 12), or on a WP-CLI/Acorn-style stack that benefits from a console-first interface.
- You value a small, readable dependency you could vendor or fork in an afternoon over a heavyweight deploy framework.
Look elsewhere when:
- You need actual deployment orchestration — build steps, release symmetry, rollbacks. That's Envoyer itself, or Envoy / Deployer / Ploi / Forge / GitHub Actions. This package only triggers; it does not deploy.
- You're not on Envoyer. Forge, Vapor, Ploi, and most PaaS providers ship their own CLIs/APIs; this package has no value there.
- A single authenticated webhook POST from your pipeline satisfies the requirement. The package is small enough that inlining the call is a legitimate alternative and removes a dependency.
- You need audit trails, RBAC, or approval gates on who triggered a production deploy. A CLI wrapper inherits whatever permissions the calling context has — deploying prod from application code is a security decision, not a convenience one.
- Single-maintainer risk is a blocker for you. Mitigation is trivial (fork/vendor), but it should be an explicit acknowledgment rather than a surprise.
Adoption hygiene (worth stating in the decision record): scope the deploy token to the specific Envoyer project, keep it in secrets rather than committed env, and never expose the command behind a public route or unauthenticated admin action.
How to Pitch It (Stakeholders)
For executives: This is a low-cost, low-risk automation enabler, not a new vendor or platform commitment. It lets us trigger Envoyer deployments from our own tooling — CI pipelines, scheduled jobs, admin workflows — removing manual dashboard steps and making releases repeatable. There is no lock-in: it's a small package on top of a service we already pay for, and it can be removed without touching deployment infrastructure. The v1.1.4 release is routine maintenance (Laravel 12 compatibility); it signals the package is still looked after and requires no action beyond a normal dependency bump.
For engineering: One composer require; the package exposes console commands that call Envoyer's deploy hook, so you can deploy from artisan, a scheduler, or a CI step and get a real exit code back. Supports Laravel 10–12 as of v1.1.4. The codebase is deliberately thin — review it before adopting, because it will take ten minutes and tells you everything. Two guardrails: treat the deploy token as a production secret scoped to a single Envoyer project, and don't wire the command to anything unauthenticated. If we'd rather not carry the dependency, the equivalent is a single signed HTTP call; we're buying convenience and a maintained interface, not capability.