Skippr Docs

Appearance

When SFTP Is the Right System Boundary ​

July 2026

SFTP is the right system boundary when the handoff is already a remote folder or file glob and rewriting that delivery pattern would add more churn than value.

Short Answer ​

SFTP is the right system boundary when a partner or legacy internal system already delivers files over SSH and that remote location is the contract the business actually uses. The source docs reflect that reality: Skippr needs host, optional port, username, either password or private_key_path, and a remote_path that can be a concrete location or a glob.

That is a good fit when the cadence is file-based and good enough for the business. A vendor dropping daily settlement files under /data/exports/*.csv, or a legacy system publishing nightly JSON extracts over SSH, is often best integrated as an SFTP boundary rather than by forcing the upstream team to build an API they do not own today.

Why Teams Struggle with This ​

SFTP is usually chosen because it already exists, not because it is elegant. That is fine, but only if the remote path, authentication method, and file naming rules are stable enough to treat as a contract instead of a fragile convention.

  • The SSH user needs read access to the remote path, not just permission to log in.
  • Private-key authentication is usually the better long-lived choice even though password auth is supported.
  • The runner must reach the SFTP host on the configured port, which can be the real blocker in locked-down networks.
  • If the workload needs low-latency updates rather than periodic files, SFTP is usually the wrong shape.

How Skippr Handles It ​

Skippr handles SFTP well because the connector matches the handoff exactly as operators see it: one host, one account, one credential method, and one remote path. That keeps the integration grounded in the existing exchange pattern instead of forcing a new abstraction over it.

It also makes review easier. Teams can document the exact remote location and authentication choice that define the feed without pretending the source is anything other than an SSH file drop.

  • Reads files from a remote SFTP host and path or glob.
  • Supports password or SSH private-key authentication.
  • Keeps connector config narrow and environment-variable-friendly.
  • Fits partner and legacy delivery patterns that are already organized around file exchange.

What the First Useful Version Looks Like ​

The first useful version is one host, one account, one remote path or glob, and one destination table that proves the files are readable and structurally consistent.

If filenames, directories, or delivery timing change without warning, fix that operational discipline before you rely on SFTP as the long-term boundary.