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.
FTP, delivered.
SFTP is the recommended flavour — it runs over SSH, supports key-auth as well as passwords, and encrypts everything on the wire. FTPS (FTP-over-TLS) covers the older TLS deployments; plain unencrypted FTP still works where a legacy pipeline demands it. Key-auth is the important distinction: SyncShot supports it, not just password login; credentials live in Keychain and never travel unencrypted. Host, port, key path, done — the server lists as a destination from then on, indistinguishable from a local drive in the workflow picker.
The quirk worth knowing: passive-mode FTP through NAT frequently reports port ranges the router's forward doesn't match, and the connection stalls with no useful error. SFTP sidesteps the whole passive/active dance by multiplexing over SSH. For large FTP offloads, use SFTP with a public key and set the destination path with a date token — /YYYY/MM/DD/shoot-name/ writes into a predictable spot every time, and you never have to guess which folder last night's shoot ended up in.
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
Should I bother with plain FTP or just use SFTP?
SFTP for everything you can control. It runs over SSH, supports key-auth, encrypts the whole session, and multiplexes cleanly through NAT — where passive-mode FTP frequently reports port ranges the router's forward doesn't match and stalls with no useful error. Plain FTP and FTPS still work in SyncShot for legacy pipelines that require them, but for a new destination from scratch, SFTP with a public key and a date-token path template is the setup that stays out of your way.
Also writing to S3, Google Drive, or NAS? Browse everything SyncShot loves.