Last updated October 19, 2026

Security

A studio trusts us with work that belongs to its clients. This page says how that work is stored, who can open it, how it is deleted, and which companies help us run the service. If your team has a security review to fill in, this is the place to start, and we will answer what it does not.

How files are stored

Every file a studio uploads goes straight from the studio’s browser to Cloudflare R2 object storage. Our servers never hold the file itself. The storage is never publicly listable, and no file has a permanent public address.

To show or download a file, our server checks the link first and then signs a short-lived address for that one file. A picture or a film shown on the page is signed for a limited time. A download is signed when someone presses Download and stops working after twelve hours, so a large master can finish on a slow connection.

Video is encoded on our own encoder, which runs on Cloudflare, into streaming files stored in the same R2 storage. Films uploaded before that encoder existed still play from Cloudflare Stream.

Encryption

• In transit. The site is served only over HTTPS, and we send a Strict-Transport-Security header so browsers refuse a plain HTTP connection. Files move between the browser and R2 over TLS. Supabase’s APIs accept only TLS 1.2 or 1.3 (Supabase platform security).
• Files at rest. Cloudflare encrypts every object stored in R2, including its metadata, with AES-256 (Cloudflare R2 data security).
• The database at rest. Supabase encrypts customer data at rest with AES-256 (Supabase security).
• Passwords. A password a studio puts on a gallery link is stored only as a bcrypt hash. Studio sign-in is handled by Supabase Auth.
• Cards. Payment details are entered on Stripe’s own pages and never reach our servers.

Who can open what

Clients

• A client never makes an account. They open the gallery through a link the studio sends, made of 24 random bytes (192 bits), which is not guessable. Every request the page makes is checked against that link on our server.
• A studio can give a link a password. Wrong guesses are limited per address and per link, and a wrong password shows nothing of the gallery. Once the right password is entered, the browser keeps a signed cookie that scripts on the page cannot read, and changing the password ends every earlier unlock at once.
• A studio can give a link an expiry date, and can switch a link off at any time. A switched-off or expired link stops opening immediately, including the preview card a messaging app draws.
• A link can be limited to one folder of a project or to one file, and the studio decides whether it allows notes, favorites, approval and downloads.

Studios and their teams

• A studio signs in with an email address and password, or with Google, through Supabase Auth. Row-level security in the database means a studio’s session can only read that studio’s own records.
• Two-step sign-in with an authenticator app is available to every studio login, in Account. Once it is on, every sign-in asks for the code. An owner can also require it for the whole team, in Account, and a teammate without it is asked to set it up before getting in.
• A studio owner decides who on their team can see what: the whole studio, one client, one project, or one folder.

Us

Administrative access to the database and to file storage is limited to the people who run DropYourFiles, and is used to operate the service and to answer a studio’s own support requests.

Deleting data

Nothing is deleted for being old. When a studio deletes a file, a project or a client, it is permanently deleted: the original, the video renditions and the preview images are removed from storage, and the records about them are removed from the database.

One thing is kept on purpose. Permanently deleting a project leaves a short deletion record: which studio, which client, how many files and how much space was freed. It holds none of the files or their contents. It exists so that we can confirm a deletion in writing when a studio or its client asks, after the thing it describes is gone.

Supabase keeps database backups on its own schedule, so a deleted record can remain in a backup for a limited time before it ages out. Ask us for the current window.

What we collect and how long we keep it is set out in full in our privacy policy.

The companies that process data, and where

• Vercel: hosts the website. Our server functions run in Portland, Oregon, USA, and pages are delivered through Vercel’s global network.
• Supabase: the database, accounts and sign-in. Hosted in the United States, in AWS’s US West (Northern California) region.
• Cloudflare: file storage (R2, in Western North America), video encoding and the older films on Cloudflare Stream, on Cloudflare’s global network. Delivering a file to a client abroad may pass through Cloudflare outside the United States.
• Resend: sends the service’s emails. Ask us for its region.
• Stripe: payments, through Stripe Checkout and Stripe’s customer portal.
• Google and Dropbox: only if a studio chooses to sign in with Google or to bring files in from Google Drive or Dropbox.

Certifications and agreements

We do not hold a SOC 2 report or an ISO 27001 certification. If your organization needs a data processing agreement, ask us at support@dropyourfiles.com.

If something goes wrong

If we discover a breach affecting your data, we will tell you.

Report a security issue

Write to support@dropyourfiles.com with what you found and how to see it. A person will answer. Please give us a fair chance to fix it before you tell anyone else, and do not open, change or delete anyone else’s files while you look. Our contact details for researchers are also at /.well-known/security.txt.

Questions about this page? Write to support@dropyourfiles.com and a person will answer.