Forge Cli Laravel Package

Product Decisions This Supports

• Infrastructure/deployment strategy. This package is the command-line surface of Laravel Forge, a paid server-provisioning and deployment SaaS. Adopting it is really a decision to standardize on Forge as the deployment substrate for Laravel/PHP apps, with the CLI as the automation layer on top. Treat the CLI decision as downstream of the platform decision, not a separate one.
• Build vs. buy for deploy tooling. The alternative to forge-cli + Forge is hand-rolled deploy scripts, Deployer, GitHub Actions pipelines, or a container platform. The CLI's value is that it removes bespoke scripting for routine operations: deploy, tail deployment and daemon logs, pull/push environment files, open a database shell, configure SSH, and script deploys from CI using FORGE_API_TOKEN (non-interactive use has explicit support).
• Developer onboarding and runbook standardization. Commands like ssh:configure, server:list, site:list with tags, and open shorten time-to-first-deploy for new engineers and give the team one documented interface instead of per-engineer SSH habits.
• CI/CD and environment parity. env:pull / env:push and scriptable deploys make it practical to keep local, staging, and production configuration aligned, and to trigger deploys from a pipeline rather than a dashboard click — an auditable, repeatable change to the release process.
• Roadmap input on operational tooling. Recent releases are almost entirely operational polish: configurable deploy poll interval and timeout, fixes to deploy:logs showing stale logs, custom SSH port handling. That tells you where teams actually feel friction (deploy observability, long-running deploys, non-standard networking) — useful when prioritizing internal platform work.
• Vendor-risk review. v2.0.0 migrated the CLI to the Forge v2 API — a major-version break driven by a vendor-side API change. That is a concrete data point for the decision log on how much release automation to concentrate in a single vendor's tooling.

When to Consider This Package

Consider it when:

• Your applications already run on (or are about to move to) Laravel Forge, and you want deploys, logs, and environment management driven from a terminal or CI rather than the dashboard.
• You want deploy automation quickly without owning deploy scripts — especially small platform teams where a full internal deployment platform is not justified.
• You need scripted, non-interactive deploys in CI, with a scoped FORGE_API_TOKEN and no interactive prompts.
• You want a low-ceremony operational interface for engineers who are not infrastructure specialists.

Look elsewhere when:

• You are not on Forge and do not intend to be. The CLI is a thin client over Forge's API; without a Forge account it delivers nothing.
• You need a programmatic integration — a PHP SDK, event hooks, or an embedded library. This is an executable tool (Laravel Zero based), not a dependency to import; the zero dependents figure reflects that, not a lack of adoption.
• You require fine-grained deploy orchestration, multi-cloud portability, or infrastructure-as-code guarantees. Forge + CLI is opinionated and vendor-coupled; Terraform/Pulumi or a container platform is a better fit.
• You cannot accept vendor API coupling in your release path. The v1→v2 migration shows major releases can be forced by Forge API changes; if release tooling must be vendor-independent, pin versions deliberately and plan for that churn.
• Secrets governance is strict and .env movement through a third-party API is not acceptable without an approved handling policy.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed command-line tool from the Laravel team that automates deploys and server operations for apps we already host on Laravel Forge. It costs nothing to adopt beyond the Forge subscription we already pay for, and it reduces manual dashboard work and deploy mistakes. The trade-off is vendor concentration: our release automation would depend on Forge's API, which has already forced one major upgrade. Recommendation: adopt within the Forge footprint, keep the scope to deploys, logs, and environment sync, and avoid making it a hard dependency in anything we could not migrate within a sprint.

To engineering: Install the CLI, authenticate with a scoped Forge API token (or FORGE_API_TOKEN in CI), and use it for deploys, log tailing, env:pull/env:push, ssh:configure, and database shell access. It is a CLI wrapper, not a library — script it, don't import it. Practical cautions: treat env:push as a production write, pin the CLI version in CI, and set explicit deploy poll interval/timeout values rather than relying on defaults. It is actively maintained (Dependabot, hardened GitHub Actions, regular patches), but adoption breadth is modest (~246 stars), so expect to validate edge cases like custom SSH ports and non-interactive environments yourself rather than relying on community answers.

Ask: approve a time-boxed pilot on one non-critical service, with a documented fallback to existing deploy scripts, before standardizing across the Forge estate.