Remote Laravel Package

Product Decisions This Supports

• Build vs. buy vs. inherit for remote operations. This component gives you first-party primitives for executing commands/processes against remote hosts from within a Laravel app. If your roadmap includes deployment triggers, multi-server artisan/shell execution, or ops dashboards, this is the "inherit" option — you avoid building SSH orchestration and avoid buying a separate vendor tool.
• Feature scoping for internal tooling. Useful when deciding whether an admin/ops surface (run migration on staging, restart queue workers across hosts, tail logs) is a two-week feature or a platform investment. This package collapses a meaningful chunk of that work into plumbing you already ship.
• Dependency and upgrade planning. Because it is a read-only subtree split of laravel/framework, the real decision is a framework-version decision, not a package-adoption decision. It informs how tightly your ops features should couple to Laravel internals versus a stable abstraction you own.
• Platform bets. If you are standardizing on Laravel Cloud/Forge-style workflows, this is aligned with the direction of first-party tooling. If you are multiplatform or polyglot, it is not a differentiator.
• Risk register input. An 18-star, read-only split is a signal: no independent community, no separate release cadence, no vendor SLA beyond the framework. That belongs in your dependency risk assessment, not your feature backlog.

When to Consider This Package

Adopt (i.e., rely on it) when:

• You are already on a supported Laravel version and your remote-execution needs are inside the framework's scope — running commands on hosts you control, as part of app-level automation.
• You want the smallest possible dependency surface: no extra vendor, no new auth model, consistent with the rest of your Laravel stack.
• Your team owns the target hosts and the operational blast radius is acceptable for app-initiated commands.

Look elsewhere when:

• You need infrastructure provisioning, configuration management, or idempotent state — that is Terraform/Ansible/Pulumi territory, not this.
• You need a standalone, versioned SSH client decoupled from Laravel (polyglot services, non-Laravel workers) — evaluate phpseclib or a language-native SSH library.
• You need task-runner ergonomics independent of the app runtime — Laravel Envoy is the more appropriate first-party choice.
• You need contractual support, SLAs, or a vendor to escalate to. A read-only subtree split provides none of that.
• You are pinning an old framework version and would have to backport — the cost of forking outweighs the benefit.

How to Pitch It (Stakeholders)

To executives: This is not a product we buy or a project we fund — it is a capability we already have by virtue of being on Laravel. It lets our application trigger and manage commands on our own servers without adding a vendor, a contract, or a new security surface. The decision it unlocks is whether certain ops features are cheap internal wins or expensive platform builds. The trade-off is dependency risk: it has no independent community, so we treat it as part of the framework, keep our framework version current, and avoid building anything mission-critical directly on its internals without an abstraction we control.

To engineering: Treat illuminate/remote as framework plumbing, not a library. Pin it via laravel/framework, not as a standalone constraint, and do not build product logic against its internals — wrap it behind our own service so a framework upgrade or a swap to Envoy/phpseclib is a contained change. It is fit for app-initiated command execution on hosts we own; it is explicitly not a replacement for our provisioning and configuration tooling. Before we commit, someone needs to own the answer to: what runs remotely, from where, with what credentials, and what happens when it fails mid-run. If we cannot answer that crisply, we are not ready to use it — and we should not be shipping it into a customer-facing path regardless.