Skippr Docs

Appearance

When to Use SFTP as a Source Connector ​

June 2026

The SFTP source connector is the right answer when the data handoff is already an SFTP folder and you want to operationalize that existing delivery pattern without rewriting it.

Short Answer ​

Use the SFTP source connector when a vendor, partner, or legacy internal system already delivers files over SFTP and the easiest reliable integration is to read that remote path directly. It is a strong fit when the remote directory structure is stable, the file cadence is good enough for the business need, and no one wants to rebuild the handoff around object storage or an API first.

A common example is a partner dropping daily exports under /data/exports/ or /data/*.json. Skippr can authenticate with a username plus password or private key, read that remote path or glob, and move those files into the warehouse or destination the team actually uses.

Why Teams Struggle with This ​

SFTP is usually chosen because it already exists, not because it is elegant. That makes it useful, but teams should still ask whether the remote path is stable enough to be treated as a lasting integration boundary.

  • The SSH user needs read access to the remote path, not just the ability to log in.
  • Private-key authentication is usually the better long-lived choice, even though password auth is available.
  • The machine running Skippr must be able to reach the SFTP host on the configured port, which can be a real blocker in private network environments.
  • SFTP is a poor fit for near-real-time workloads that would be better served by streams, APIs, or direct database extraction.

How Skippr Handles It ​

Skippr keeps the connector aligned with how SFTP integrations are actually managed: host, port, username, password or private key, and remote path. That is enough to operationalize an existing file drop without building an extra synchronization layer.

The connector is especially useful when the business reality is that a partner will keep sending files over SSH for the foreseeable future. In that case, meeting the handoff where it already exists is often the best technical choice.

  • Reads files from a remote SFTP host and path or glob.
  • Supports password or SSH private-key authentication.
  • Keeps config narrow and environment-variable-friendly.
  • Fits partner and legacy-system delivery patterns that already rely on SFTP.

What the First Useful Version Looks Like ​

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

SFTP is a bad fit when the path naming is chaotic, the server access rules are brittle, or the real need is continuous low-latency ingestion instead of file-based exchange.