phanan/remote
Run Artisan commands on remote servers over SSH directly from your local Laravel app. Configure connections, then execute and inspect them as if they were local—handy for deployment, maintenance, and managing multiple environments. No extra tooling required.
Architecture fit. phanan/remote is a Laravel 5-era service provider plus facade that wraps SSH/SFTP primitives, most likely phpseclib or the ssh2 extension. That shape fits a legacy Laravel 5 IoC container but sits beside, not inside, Laravel's Storage/Flysystem abstraction. For any modern codebase this is an architectural mismatch: file movement would bypass disk configuration, visibility rules, fake/mock testing hooks, and the unified retry/error semantics teams expect from Storage::disk(). The first thing to confirm is whether it registers a Flysystem driver or only exposes a convenience facade — the latter makes it a side channel rather than an integration.
Integration feasibility. Low for a current stack. The package is archived, carries Laravel 5 illuminate/* constraints, and predates PHP 8 and Laravel 6+. Composer will almost certainly refuse resolution on Laravel 9–12 / PHP 8.1+, so adoption implies a fork or a replace shim. Even where it installs, it is a thin wrapper: the real dependency risk lives in its transitive SSH library, which is also pinned to an old major.
Technical risk. High and mostly unowned:
Key questions. Does it implement a Flysystem adapter or a standalone facade? Which transport (phpseclib v1/v2 or ext-ssh2) and what are the exact version constraints? Is host-key verification enforced or opt-in? Are uploads atomic (temp file + rename) and are partial transfers detectable? What is the license and can we legally fork and vendor it? Who inside the team would own that fork? Is there an existing SFTP server contract (ciphers, key types, IP allowlisting) that constrains the client?
Stack fit. Acceptable only for a Laravel 5.x application already in maintenance mode, where the cost of touching working code exceeds the cost of carrying a stale dependency. For anything greenfield or on Laravel 8+, it does not fit. The opportunity score (0.54) reflects a real need for simple SSH/SFTP in Laravel, not a endorsement of this implementation — that need is now met by first-party options.
Migration path. Treat this as a replace, not an adopt:
Storage::disk('sftp') backed by league/flysystem-sftp-v3 (phpseclib 3) or direct phpseclib 3 for non-file SSH commands.internal/remote VCS repository, pin the transport, add host-key verification and PHP 8 patches, and document it as a liability.Compatibility. Expect PHP ≤7.4 and Laravel ≤5.x in practice. Before committing to a fork, run a Composer dry-run against the target stack and a small connectivity spike against the real SFTP endpoint — cipher and key-exchange negotiation with modern OpenSSH servers is a common failure point for old phpseclib majors. Confirm the ssh2 extension is installed and pinned in the base image if that is the transport.
Sequencing. Discovery and call-site inventory → compatibility spike against the actual server → decision gate (fork/vendor vs. replace) → build the adapter behind the existing interface → shadow-run transfers and diff results → cut over per job/queue → remove the package and its config. Keep the legacy path available behind a feature flag until at least one full transfer cycle has passed.
Maintenance. Archived means zero upstream maintenance. Every future PHP upgrade, OpenSSH hardening change, or CVE becomes an internal ticket. Budget explicit ownership — a named maintainer and a quarterly review — or do not ship it. This is the single largest operational cost and it does not appear in the initial estimate.
Support. No vendor, no SLA, negligible community (28 stars). Incident response is entirely internal. For a business-critical transfer path (payroll files, partner drops, backups), that is usually disqualifying on its own; for an internal convenience script, it may be tolerable.
Scaling. Each call opens a connection synchronously, so throughput is bounded by handshake latency and SFTP server connection limits, not application concurrency. Under load this manifests as thread/worker starvation in PHP-FPM rather than clean backpressure. Move bulk or scheduled transfers to queued jobs with dedicated workers, cap concurrency per remote host, and set explicit connect and read timeouts. Persistent connections are unlikely to be supported; assume one connection per operation.
Failure modes. Watch for: silent authentication failures surfacing as generic exceptions; hangs with no timeout on unreachable hosts; partial uploads that leave truncated files at the destination with no atomic rename; host-key verification absent, enabling MITM; stale facade singletons holding a dead connection across a long-running worker; credentials leaking into exception traces or logs; and no idempotency, so retries duplicate files. Add a checksum-and-rename wrapper and a dead-letter queue for failed transfers regardless of which library you land on.
Ramp-up. The API surface is small, so developer ramp-up is hours, not days. The real cost is archaeological: reconstructing why a legacy path exists, what the remote counterpart expects, and which transfers are safe to replay. Document the endpoint contracts and file-naming conventions before touching code — that documentation, not the library, is the durable artifact from this work.
How can I help you explore Laravel packages today?