Sftp Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (buy → borrow): This is a ~micro-package that wraps PHP's native SFTP functions behind a Symfony service. The realistic decision is not "buy vs. build a product" but "adopt, vendor, or reimplement in a day." Treat it as a reference implementation, not a strategic dependency.
• Feature scoping for partner/B2B file exchange: Supports roadmap items involving scheduled file drops and pickups — payroll files, EDI/clearing-house exchanges, bank statement retrieval, invoice/remittance delivery, vendor batch imports. If the roadmap has "connect to partner X's SFTP," this package covers the thin transport layer only; the valuable work (retry logic, reconciliation, audit trail, PGP encryption, file naming contracts) is still ours to build.
• Integration architecture decision: Because it is config-driven and framework-native (Symfony bundle), it is a cheap way to prove out an integration pattern — one service per endpoint, credentials in config/secrets — before standardizing on a filesystem abstraction.
• Prioritization signal (negative): 3 stars, 0 dependents, no release since 2020, and a low opportunity score all say "no ecosystem, no community maintenance." That argues against putting this in a critical path or building a product surface on top of it. It is a commodity, not a differentiator.
• Buy-vs-fork economics: MIT license means we can fork and own it. If we use it at all, budget for forking and internal ownership from day one rather than assuming upstream will respond to issues or PHP/Symfony upgrades.

When to Consider This Package

Consider it when:

• You are on Symfony and need one or a few simple, well-defined SFTP transfers (upload/download/list) with connection settings managed in configuration.
• You want the smallest possible surface: no new abstraction layer, no cloud SDK, no queue infrastructure — just "move this file to that host."
• The transfer is non-critical-path, low volume, and failures can be handled by a scheduled retry with alerting.
• You are prototyping an integration and want the fastest path to a working proof of concept, accepting that you may replace it later.
• Your infrastructure already has (or will accept) the required PHP SSH extension installed and pinned in the runtime image.

Look elsewhere when:

• You need active maintenance, security patching, or vendor support. Last release was December 2020, so assume no fixes for modern PHP/Symfony versions — verify compatibility against your PHP and Symfony versions before committing, and assume you own the fork.
• The work is high-stakes or regulated (payments, PII, healthcare): you need key management, host-key verification, audit logging, PGP/GPG encryption, and tested retry/idempotency semantics. That belongs in our code, not in a thin wrapper.
• You need a filesystem abstraction used across local, S3, and SFTP. Use a maintained Flysystem SFTP adapter instead so all storage shares one interface.
• You cannot install a PECL/SSH extension in your runtime (locked-down containers, shared hosting, some serverless), or you want pure-PHP transport — a phpseclib-based client avoids the extension entirely.
• You need connection pooling, parallel transfers, resumable/large-file streaming, or SFTP events/webhooks. None of that is in scope here.
• One person's evaluation cost exceeds the code's value — in that case, write a 50-line service around the native functions and skip the dependency.

How to Pitch It (Stakeholders)

To executives: This is a tiny, MIT-licensed glue library for moving files to and from partner SFTP servers. The strategic read is simple: it is undifferentiated plumbing, not a moat. Adopting it can save us a few days on a single integration, but it has essentially no community — three stars, zero dependent projects, and no release since late 2020. So the recommendation is not "adopt a dependency," it is "treat it as a reference and own the code." Either we fork it behind our own internal interface, or we use a maintained alternative if the integration is customer-facing or regulated. Cost is near zero; the actual risk is not the license or the price, it is unmaintained code sitting in a security-sensitive path.

To engineering: Small wrapper over PHP's native SFTP calls, packaged as a Symfony bundle with configuration for connection profiles. Pros: minimal surface, permissive license, framework-native, easy to read and reason about. Cons: stale since 2020, unverified against current PHP/Symfony, requires the SSH extension in the runtime, no apparent ecosystem or test/CI signals we can rely on. Proposed handling: wrap it (or a fork) behind our own FileTransfer interface so the transport is swappable; enforce host-key verification and secrets from our secret manager, not YAML; add idempotent retries, checksums, and structured audit logs in our layer; and add a compatibility spike as the first ticket. If that spike fails, fall back to a maintained Flysystem SFTP adapter or a phpseclib client, both of which keep the same internal interface.

Decision requested: Approve a timeboxed compatibility spike plus an internal abstraction, rather than a direct dependency in the critical path. Success criteria: transfer succeeds against a real partner endpoint, credentials come from the secret store, host keys are pinned, and failures are observable. If those criteria are not met within the timebox, we do not adopt.