A sign-in in front of a bucket you already own

How it works

1. Connect the bucket

   Give objectgate a read-only access key, or on AWS a cross-account role it assumes with an external id. Either way the grant is scoped to one bucket and one prefix, and you can revoke it in your own console.

   The connect check runs while you watch: it lists the prefix and reads one object. When that fails you get the S3 answer translated into the thing to change, whether it is a missing permission, the wrong region, or a KMS key policy that does not mention the role yet.

2. Choose who may open it

   An address list, an email domain, a link that is itself the credential, or your own identity provider over OIDC. Sign-in happens before a request reaches the share, so a viewer needs no account with objectgate and no identity in your cloud.

3. Send the address

   A share is a host: rushes.acme.objectgate.dev, or a domain of yours pointed at it. Signed-in viewers see the objects under the prefix you picked. A key that resolves outside that prefix answers 404, which tells a prober nothing about what exists.

What a download does

Five hops, and only the last one moves bytes.

1. GET /f/2026-08/master.mov arrives at the share carrying the viewer's session.
2. resolve against the prefix the key is normalised and re-checked; a .. segment or a different prefix ends here.
3. sign a GET for that one object, valid for the share's window, five minutes unless you set another.
4. 302, Cache-Control: no-store with a content-disposition taken from the key, so the file keeps its name on the way into the downloads folder.
5. browser → your bucket S3 answers the object. Range and If-None-Match work because the storage is answering them, not a proxy of ours.

Proxy delivery is the other setting: the share streams the object through itself and no presigned URL ever reaches the browser. Either way the grant lands in the event log with the viewer, the key and the time.

What stays as it is

Block Public Access

On, all four switches. objectgate reads with credentials; no object becomes public.

The bucket policy

Unedited. The permission lives in a role or a key that you create and can delete.

CloudFront

Not involved. No distribution, no origin access control, no signed cookies.

CORS

Untouched for downloads. Following a redirect to an object is a navigation, not a cross-origin fetch.

The objects

Not copied, not moved, not re-encrypted. The policy objectgate asks for grants no write anywhere.

Who it is for

• A studio delivering rushes to a client who is never going to be given an AWS login.
• A lab handing a dataset to four named collaborators for the length of a review.
• A vendor shipping firmware images, one prefix per customer, from the bucket the build already writes to.
• An agency whose client owns the bucket: the role is created in the client's account, and revoked there when the engagement ends.

Storage it reads

Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, DigitalOcean Spaces, Scaleway Object Storage, and MinIO on a public hostname. Anything else that speaks S3 with signature version 4 connects as other, path-style. The connect guide lists the endpoint, region and addressing each one wants.

What it will not do