How quickS3 is built
The Cloudflare services behind quickS3, where each kind of data lives, how organisations are kept apart, and what that means for your files.
quickS3 runs on Cloudflare’s platform. This page is for people who want to know where things live before trusting it with their storage.
One store per organisation
Each organisation has its own Cloudflare Durable Object: a small, isolated database with a unique, unguessable ID. It holds everything about that organisation:
- members and their roles,
- custom roles and rules,
- connections and their encrypted storage keys,
- AI client access,
- the audit log.
Every request for an organisation goes to that one store, which checks membership and roles itself. Because there’s exactly one copy, changes are immediate: when you remove someone or change a role, their very next request sees it.
Around it
| Service | Holds |
|---|---|
| Cloudflare Workers | The web app, the API, and the MCP server. |
| Cloudflare D1 | The list of user accounts and sign-in details, and which organisations each person belongs to. Not permissions. |
| Cloudflare KV | Short-lived sign-in data for AI clients while they’re being approved. |
| Cloudflare Workflows | Multi-step jobs like sending invitations and removing members. |
The organisation switcher and a few lists read from D1, so right after a change they can take a moment to catch up. Access decisions never do.
Trust boundaries
- Storage keys are encrypted at rest and only decrypted on quickS3’s servers, to list files and sign links.
- File contents go directly between people and your storage provider, except when an Owner turns on the backend upload fallback. See where your files travel.
What this page doesn’t promise
It describes how quickS3 works today. It isn’t a guarantee of data location, backup, or recovery. quickS3 doesn’t back up your files, and the audit log is kept for 14 days. For what that means in practice, see security model and limitations.