Skip to main content
Kadoa uploads your workflow results to an SFTP (SSH File Transfer Protocol) server that you host, after every completed run. Use it when your systems read files from a directory rather than from an object store or a warehouse. Kadoa’s support team sets up SFTP delivery for you. There is no self-service connector screen for SFTP yet.

​
Before you begin

Your server must meet all of these requirements. If your server needs an allowlist, use Cloud Storage instead. Ask your Kadoa contact if you are unsure whether your server qualifies.

​
Prepare the server

  1. Create a dedicated account for Kadoa. Do not reuse a person’s login.
  2. Create the base directory that Kadoa writes into, for example /incoming/kadoa.
  3. Give the account write, create, and delete permission on that directory and everything below it. Kadoa needs delete permission to clear its own temporary files.
  4. Confirm that the account can create subdirectories. Kadoa creates one directory per workflow run below the base directory.
  5. Record the server’s host-key algorithm and SHA-256 fingerprint. Run this on the server itself, not from a client that has never connected:
    The command prints the key size, then the fingerprint in the form SHA256:<43 characters>, then a comment. Send Kadoa the fingerprint exactly as printed, including the SHA256: prefix.
Send the fingerprint through a channel that is separate from the server address, and confirm it with someone who has access to the server. The fingerprint is what proves Kadoa is talking to your server and not to an impostor. Kadoa refuses the connection when the presented key does not match, before it sends any credential.

​
Add your credentials

Store the login credential as a secret variable first. Kadoa never accepts a password or private key through email, chat, or a ticket.
  1. Open Team settings and select Variables.
  2. For a password, select Create variable, enter a key such as SFTP_PASSWORD, choose Secret, and enter the value.
  3. For an SSH private key, store the key in your Google Secret Manager project. Then create a customer-managed Secret Variable that references that secret.
  4. Select Save.
Repeat for the passphrase if your private key is encrypted. That passphrase needs its own secret variable. Secret values are write-only. Nobody, including Kadoa staff, can read a stored value back. Do not paste a private key into the Kadoa-managed value field because it does not preserve multiline PEM content. See Secret Variables for provider choices and rotation.

​
Give Kadoa the connection details

Send these non-secret details to your Kadoa contact: Also send your expected file sizes, your server’s idle timeout, and any limit on concurrent sessions. Kadoa sets its connection timeouts from those numbers. Kadoa creates the connector disabled, tests it, and enables delivery only after a verified first run.

​
Formats and file layout

Choose any combination of these formats. Kadoa writes one file per format per run. If you do not choose formats, Kadoa delivers Parquet and JSONL. Files land below your base directory in a directory per run:
Ask Kadoa for a different layout if you need one. The path can use {teamId}, {workflowId}, {runId}, {runDatetimeSafe}, {runDatetime}, and {runDate}.

​
How delivery works

Kadoa uploads each file to a temporary name that ends in .part, waits for the server to confirm the write, then renames it to the final name with posix-rename@openssh.com. The rename is atomic, so a reader never sees a partial file, and a repeated run replaces the previous file in one step. Only read files that do not end in .part. A file with that suffix is still being written or was left by an interrupted run. Kadoa makes at most five connection attempts for one run, waiting 2, 5, 10, and 20 seconds between them. A run that already delivered some formats resumes with only the missing ones. Errors that cannot improve by retrying, such as a wrong fingerprint, a rejected login, or a missing base directory, stop after the first attempt. A failed SFTP delivery never fails the workflow itself. The run still completes and its data stays available through every other integration. Preview runs and quality-assurance runs are not delivered.

​
Verify the first delivery

  1. Ask Kadoa to run the workflow once with the connector enabled.
  2. List the run directory on your server and confirm one file per chosen format.
  3. Confirm that no file ends in .part.
  4. Compare the record count in the delivered file against the run’s record count in the Kadoa dashboard.
  5. Run the workflow a second time and confirm that the new run writes a new directory.
Tell your Kadoa contact if any step does not match. Kadoa keeps a per-run delivery history, including the attempted formats, the number of attempts, and a failure category.

​
Rotate or replace credentials

  1. Update the value in Team settings → Variables. Rotate the existing variable rather than creating a new one, so the connector keeps working.
  2. Ask Kadoa to run the connection test.
  3. Retire the old credential on your server only after the test passes.
Kadoa blocks deletion of a variable while a connector still uses it. The request fails with a conflict, and the connector keeps running.

​
Troubleshoot

​
Limits

  • No source-IP allowlisting. Kadoa cannot give you a fixed egress address for SFTP.
  • Your server must be reachable from the public internet. Kadoa cannot reach a private network, a VPN-only host, or a private IP address.
  • Password and SSH private-key login only.
  • The connection test is advisory. It proves a login and a file round trip at that moment. It does not guarantee the next delivery.
  • A connection lost at the end of an upload can leave one .part file behind. Paths are unique per run, so no later run reuses or cleans that file.

​
Get help

Submit a request through the Support Center. Include the workflow, the run time, and what you saw on the server. Never include a password, a private key, or a passphrase in a support request.