We broker credentials. We never see your files.
BlobShip was designed around one decision: your data should go straight to your own storage, and our servers should only ever handle tiny control messages. Here's exactly what that means.
The path your file takes
The control message (the API key check) hits us. The file bytes do not — they follow the redirect straight to your bucket.
Broker, not relay
Our servers only mint a short-lived, tightly-scoped credential and then issue a 307 redirect. The file bytes travel directly from the box to your storage — one network hop, not two. They never transit our infrastructure, so we can't read, store, or leak them.
We don't store your cloud keys
You never hand us a long-lived access key. AWS access is granted via an IAM role you control (AssumeRole + a unique external ID); Azure via User Delegation. We hold a grant you can revoke, not a secret we have to guard.
Least privilege by design
Each connector is scoped to exactly the bucket or container it needs, with write-only intent. Credentials minted per upload are short-lived and can't be replayed elsewhere.
Revocable in one click
Pull the grant from your cloud console or the BlobShip dashboard and access stops immediately. No keys to rotate, no secrets stranded on old boxes.
Every authorization logged
We keep an audit trail of who issued what, when, and to which connector — the control-plane record you need for compliance. What we deliberately don't log is anything about file contents, because we never see them.
Nothing left on the box
There's no agent and no daemon. The command is plain curl; it runs once and leaves nothing installed, scheduled, or persisted. Perfect for a customer's server you don't own.
Want the full architecture?
See exactly how connecting a cloud works — AWS Launch Stack and Azure deploy, in a few clicks, in your own tenant.
See how it works