What gets written.
Whatever the source handed over — uploaded onto the server exactly as it arrived. SyncShot treats FTP like any other destination: files are originals, the path is yours to define, the verification is non-negotiable.
- Originals
- Files arrive byte-for-byte intact — no recompression, no name mangling, no surprise rewrites on the wire. What came in is what lives on the server.
- Folder structure
- Source structure preserved as the directory layout by default — or apply a workflow path template (something like /YYYY/MM-shoot-name/) so the server organises itself the way the recipient expects.
- Metadata
- EXIF and file times preserved on the upload where the destination supports it. The provenance survives the protocol hop.
- Job report
- Alongside the upload (or in a side log, your choice) SyncShot writes a job report — what landed on the server, when, and which verification check it passed.
What it pairs with.
FTP is rarely the only destination — but it's the non-negotiable one. Your FTP server is one of many destinations, and SyncShot writes to it in parallel with the local drive, the archive, and the cloud — the delivery copy goes up while the rest of the job is still running.
- Legacy delivery workflows
- The wire service, the newsroom, the broadcaster who's been on the same SFTP server for fifteen years. SyncShot meets them where they are — no extra app, no third-party client.
- Third-party services
- Stock agencies, syndication platforms, post-production houses that still spec SFTP as the only accepted ingest. The server URL is theirs; the files are yours; SyncShot is the bridge.
- Self-hosted servers
- Your own VPS, a colo box, a Raspberry Pi running SFTP at home — anywhere you can paste host + credentials, SyncShot will write to it.
- Hand-off to vendors
- Print shop, lab, retoucher with their own server. The directory structure they expect, the files they need, dropped in as the shoot runs.
How it works.
- 01
Add the FTP server
Host, port, username, password (or SSH key for SFTP) — pasted once, stored in the macOS Keychain. SyncShot tests the connection and lists the server as a destination from then on.
- 02
Choose destinations
Pick this server — and every other place this shoot belongs. Save the set as a workflow if you'll use it again; next time it's one click.
- 03
Hit start
SyncShot reads the source once and writes to every destination in parallel. The local drive finishes first; the FTP upload keeps going in the background.
- 04
Trust the report
Every byte is hash-checked end to end. When the job finishes you get a report — what landed on the server, every verification mark. The byte that left the source is the byte the recipient downloads.
Common questions.
- 01
Which FTP flavours work?
Plain FTP, SFTP (over SSH), and FTPS (FTP-over-TLS). Host, port, credentials in — the server lists as a destination from then on, regardless of which dialect it speaks.
- 02
Can I write to multiple FTP servers at once?
Yes. Each server is a separate destination — list as many as you want and SyncShot writes to all of them in parallel, alongside any other destinations in the same workflow.
- 03
What if the connection drops mid-upload?
SyncShot pauses that destination and retries with backoff. The local copy and the other destinations keep going — a flaky FTP server never takes down the rest of the job.
- 04
Will it verify the upload?
Yes — hash-verified end to end like every SyncShot copy. The byte that left the source is the byte that landed on the server, and the job report tells you exactly which files passed.
- 05
Where do credentials live?
Locally, in the macOS Keychain — host, port, username, password (or SSH key for SFTP). SyncShot uses them to connect to the server; nothing else sees the credentials.
Also writing to S3, Google Drive, or NAS? Browse everything SyncShot loves.