Skippr Docs

Appearance

What a Good First SFTP Integration Looks Like ​

July 2026

The smallest production SFTP setup is one reachable host and one file path with a dedicated automation identity, preferably key-based.

Short Answer ​

A good first SFTP integration is one host, one SSH user, one remote_path, and a deliberate auth choice. The connector docs support password auth and private_key_path, but for a long-lived production integration the better boundary is usually one dedicated automation user with one private key and one remote directory or glob such as /data/*.json.

That setup is small enough to operate well. You know which server matters, which account owns the pipeline, and which files Skippr should pick up. If the server only supports password auth, keep that password outside the file and treat it as a transitional production setup rather than as the ideal shape.

Why Teams Struggle with This ​

Teams often treat SFTP as just file pickup, then reuse a personal account or a shared password. The first production boundary should be more deliberate than that because ownership and rotation become painful very quickly.

  • The runner must reach the SFTP host on the configured SSH port before any path debugging helps.
  • A user that can log in still needs read access to the specific remote_path the integration expects.
  • A broad home-directory account makes the pipeline harder to audit and rotate.
  • Password auth works, but it is usually a weaker long-term operating model than a dedicated key pair.

How Skippr Handles It ​

Skippr keeps SFTP readable because the contract is mostly operational: host, port, username, auth method, and remote_path. That is enough to define a production file pickup without inventing more ceremony.

It also supports the cleanest migration path. You can begin with a password-backed setup if the server requires it, then move to private_key_path later without changing the basic source boundary.

  • Supports SSH key auth with private_key_path, which is preferable for long-lived jobs.
  • Also supports env-backed password auth when the server requires it.
  • Keeps remote_path explicit so the file contract is reviewable.
  • Works well with a dedicated automation account that can only read the export path.

What the First Useful Version Looks Like ​

The first useful version is one SFTP host, one automation user, and one remote path or glob that returns the files you actually want. That is enough to validate network reachability, auth, and the file boundary together.

If the server team can support key auth, start there. If not, keep the password behind SFTP_PASSWORD and make the rotation plan part of the production setup instead of an afterthought.