Sftp Bundle Laravel Package

Product Decisions This Supports

• Partner / B2B file-exchange features. Any roadmap item that involves moving files to or from a third party's SFTP endpoint — nightly CSV drops, EDI payloads, bank statement or payroll file pickups, customer-managed report delivery, inbound catalog feeds. This is the archetypal use case the package targets: connect, list, get, put, delete.
• Build vs. buy on file transfer. The package is a thin, MIT-licensed wrapper over PHP's ssh2/phpseclib-style primitives. The real build-vs-buy decision is not "this package vs. nothing" — it is in-process SFTP client vs. a managed transfer service (AWS Transfer Family, SFTP Gateway, MFT vendors). Choose in-process only when volumes are modest, endpoints are few, and the file flow is synchronous with a job/batch.
• Framework direction, not just a library pick. The package is a Symfony bundle (sf2h/sftp-bundle, SFTPBundle), not a Laravel package, despite being evaluated in a Laravel/PHP context. If the product is Laravel, this signals an adapter gap: adopting it means either running it outside its intended container or hand-rolling the wiring. That is a product-level integration tax, not a technical footnote.
• Use-case triage. Good fit for "scheduled job pushes a file, logs the result, alerts on failure." Poor fit for interactive user-triggered transfers, very large files (streaming/chunking), resumable transfers, or multi-tenant credential management. Those map to roadmap items that need a different foundation.
• Deprecation / risk budgeting. 3 stars, 0 dependents, last release 2020-12-22. This is a signal to plan for fork-and-own from day one rather than treat it as a maintained dependency. Budget a small internal ownership line item, not a support contract.

When to Consider This Package

Consider it when all of the following hold:

• You are on a Symfony application (or explicitly willing to vendor the class into a Laravel service layer) and need only a handful of primitive operations: connect, list directory, upload, download, delete.
• You need something small and readable — the value here is a few hundred lines you can audit in an afternoon, under a permissive MIT license, with no transitive dependency tree to inherit.
• Your PHP/runtime is pinned to an era compatible with a 2020 release, or you have the appetite to patch forward yourself.
• The transfer is batch/scheduled, low volume, single-tenant, and failure is recoverable by re-running the job.
• You are comfortable owning the code — forking it into your repo, adding tests, and pinning it internally.

Look elsewhere — decisively — when any of these are true:

• You are building on Laravel. Laravel's filesystem layer already ships an sftp disk driver via Flysystem. Reaching for a Symfony bundle to do what Storage::disk('sftp')->put(...) already does is a net-negative trade: extra surface, zero coverage, unfamiliar abstractions. Use the native disk.
• You need a maintained dependency. No release since 2020, 3 stars, no visible dependents means no upstream security response, no PHP 8.x compatibility guarantee, no issue triage. Anything customer-facing or regulated (SOC 2, PCI, HIPAA) should not rest on this.
• You need anything beyond the happy path: host-key verification policy, key rotation, connection pooling, retries/backoff, partial-transfer resumption, large-file streaming, SFTP-over-proxy, structured logging, or async transfers. You will write all of it yourself; at that point start from phpseclib or league/flysystem-sftp directly and skip the middle layer.
• Your team has no one who wants to own an SSH-credential-handling code path. That is a security-sensitive surface and an on-call burden.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed helper for moving files to and from partner SFTP servers — a common requirement in B2B and finance-adjacent workflows. It is not a vendor relationship; it is closer to a code sample. With three stars, no downstream users, and no release since December 2020, we should treat it as unmaintained. The right framing is not "adopt this package" but "we need SFTP capability; here are three ways to get it, and this is the cheapest-looking but least-supported one." The cost of adopting it is not the license — it's the internal ownership we take on the day we ship it.

To engineering: Two things to say plainly. First, this is a Symfony bundle, not a Laravel package — if we're on Laravel, our own sftp filesystem disk (Flysystem-backed) already covers the common cases and is maintained; that should be the default answer, and this package needs a specific justification to beat it. Second, it's thin and stale: primitives only, last touched in 2020, no test or CI signal we can rely on. If we do use it, we fork it into our repo, pin it, add tests around credential handling and error paths, and set expectations that we own it forever. If the requirement is anything more than list/get/put/delete on a schedule, we should start from phpseclib or league/flysystem-sftp instead and save ourselves the rewrite.

Recommendation: Do not adopt as a dependency. Use it as a reference implementation for scoping effort (it demonstrates the problem is small), and make the real decision between Laravel's native SFTP disk and a direct phpseclib/Flysystem integration. Reserve managed transfer services for when volume, compliance, or multi-tenant credential handling shows up on the roadmap.