How to Review SFTP Config Before Production

July 2026

An SFTP review should prove the SSH path and the file pattern together, because a correct login is not enough if the connector is pointed at the wrong remote path.

Short Answer

Review an SFTP source config by checking host, port, username, the chosen authentication method, and the exact remote_path. The docs support either password authentication or private_key_path, so the production review should confirm which one is intentional and whether the SSH user can list and read the matching files.

A concrete review might say: connect to sftp.vendor.example on port 22 as skippr_ingest, authenticate with a private key, and read /exports/orders/*.json. That is specific enough to test. If the connector instead uses a loose directory path with no one sure which filenames matter, the production boundary is still vague even if SSH login succeeds.

Why Teams Struggle with This

SFTP pipelines often fail after promotion because teams only test authentication. Production support depends just as much on the remote path contract, especially when vendors rotate filenames or publish many unrelated files in the same directory.

• The SSH user needs read access to the selected remote path, not merely the ability to authenticate to the host.
• Choosing password versus private_key_path is an operational decision, and long-lived production setups usually benefit from key-based auth.
• A remote glob such as /data/*.json should be reviewed like a dataset selector because it determines which files enter the pipeline.
• Network checks have to confirm that the production runner can reach the SFTP host and port, not only that a desktop client can.

How Skippr Handles It

Skippr keeps the SFTP connector clear by exposing exactly the inputs reviewers care about: host, port, user, auth method, and remote path. That makes it easier to discuss the real boundary of the feed instead of treating SFTP as a generic black box.

The best first release is narrow. One known folder or glob with one authentication method gives the team a stable file contract and a smaller support surface when the upstream sender changes behavior.

• Connects to an SFTP server with password or SSH private-key authentication.
• Uses an explicit remote_path or glob as the file-selection contract.
• Defaults to SSH port 22 but allows an alternate port when needed.
• Works well when a vendor or internal team already publishes files as the source boundary.

What the First Useful Version Looks Like

The first useful version is one host, one SSH identity, and one remote path pattern that the team has validated against real production files.

If the review cannot say exactly which files the connector should pick up tomorrow morning, the remote path is still too loose for production.