What gets written.
Whatever the source handed over — uploaded into the bucket exactly as it arrived. SyncShot treats S3 like any other destination: the objects are originals, the keys are yours to define, the verification is non-negotiable.
- Originals
- Objects arrive byte-for-byte intact — no recompression, no name mangling. What came in is what lives in the bucket, available for download a decade from now unchanged.
- Folder structure
- Source structure preserved as the key prefix by default — or apply a workflow path template (something like /YYYY/MM-shoot-name/) so the bucket organises itself the way your archive thinks.
- Metadata
- EXIF and file times preserved on the object where the destination supports it — as object metadata, sidecar, or both. The provenance survives the upload.
- Job report
- Alongside the upload (or in a side log, your choice) SyncShot writes a job report — what landed in the bucket, when, and which verification check it passed.
What it pairs with.
S3 is the destination for everything that needs to leave the building. Your bucket is one of many destinations, and SyncShot writes to it in parallel with the local drive and the NAS — the cloud copy starts uploading the moment the first byte lands locally.
- Off-site archive
- The copy that lives somewhere your studio doesn't. Every job written locally is also uploaded — the bucket grows alongside the NAS, on the same workflow.
- Client deliverables
- Finished work, ready to share — landing in a delivery bucket with a clean path structure, ready for a signed URL or a CDN to take over from there.
- Automation pipelines
- The bucket is the handoff point. SyncShot puts the files there; a queue, a Lambda, a render farm picks them up. Object lands, pipeline fires.
- Cold storage
- Glacier, deep archive, infrequent-access tiers — the bucket SyncShot writes to is the bucket the lifecycle policy reads from. Nothing about the offload changes.
How it works.
- 01
Add the bucket
Endpoint, region, access key, secret — pasted once, stored in the macOS Keychain. SyncShot validates the credentials against the bucket and lists it as a destination from then on.
- 02
Choose destinations
Pick this bucket — 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 bucket uploads keep 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 in the bucket, every verification mark. The byte that left the source is the byte in S3.
Common questions.
- 01
Which S3-compatible providers work?
Anything that speaks the S3 API — AWS S3 itself, Cloudflare R2, Wasabi, Backblaze B2, MinIO, plus the half-dozen others built on the same protocol. Endpoint and credentials in, bucket as a destination out.
- 02
Can I write to multiple buckets at once?
Yes. List as many buckets as you want — across providers if you mix them — and SyncShot uploads to each in parallel. Your S3 bucket is one of many destinations, fed from a single read of the source.
- 03
What if the upload drops mid-job?
SyncShot pauses that destination and retries with backoff. The local copy and the other destinations keep going — a wobbly connection never takes down the whole job.
- 04
Will it verify the cloud upload?
Yes — hash-verified end to end like every SyncShot copy. The byte that left the source is the byte sitting in the bucket, and the job report tells you exactly which objects passed.
- 05
Where do credentials live?
Locally, in the macOS Keychain. SyncShot uses the credentials to write to the bucket; nothing about your S3 setup is ever sent anywhere except to the endpoint you configured.
Also writing to Google Drive, NAS, or external drives? Browse everything SyncShot loves.