Cloudflare OS makes it easy to share a Gadget the same way you’d share a document in an online office suite. There are two distinct sharing mechanisms: collaborators grant other users direct, ongoing access to your Gadget so you can work on it together, and blueprints share a snapshot of the Gadget’s source code so others can spin up their own independent copy. This guide covers the collaborator system — real-time, permission-tracked, live access.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/cloudflare/cloudflare-os/llms.txt
Use this file to discover all available pages before exploring further.
Collaborator roles
Every collaborator is assigned a role that determines exactly what they can do inside your Gadget.build
Full access: edit code, use the AI chat, manage bindings, and interact with the deployed UI — the same as the owner, with a few exceptions noted below.
use
UI-only access: render and interact with the Gadget’s deployed interface. No code editor, no AI chat, no binding management.
build > use. A caller can never grant a role higher than their own, so a build collaborator can grant both build and use access, but a use collaborator cannot reshare at all today (though the permission graph already supports this for a future release).
How build collaborators differ from the owner
build collaborators have nearly the same access as the owner, but with four important differences:
- Cannot delete the Gadget. Only the owner can permanently delete a Gadget.
- Use their own AI models. BYOK billing for AI chat goes to the person who prompted — not the Gadget owner.
- Use their own connected accounts. When a
buildcollaborator adds or uses a Gatekeeper binding, it connects through their third-party accounts, not the owner’s. This prevents collaborators from gaining access to the owner’s external services beyond what the Gadget’s existing bindings already expose. - Limited revocation authority. A collaborator can only remove users that they themselves added. They cannot sever edges they didn’t create.
Adding collaborators
- Direct add
The owner or any
build collaborator can enter a username or email address in the Share modal. If the account exists, a collaborator record is created immediately.Enter the collaborator's email
Type the email address of the person you want to add, select their role (
build or use), and click Add.Permission graph and lazy revocation
Cloudflare OS tracks how every collaborator gained access, forming a directed permission graph rooted at the owner.Edges
Each collaborator has one or more permission edges explaining how they gained access:- User edge — a specific sharer directly added this person (carries timestamp, role, and optional note).
- Share-link edge — this person redeemed a key for a specific share link (carries timestamp; role comes from the link).
Effective role
A collaborator’s effective role is the maximum role reachable from the owner through their valid edges. Each edge grantsmin(edge role, sharer's effective role). The owner is the implicit build root. Effective role is computed live on every open() — never denormalized — so it is always consistent with the current graph.
Lazy revocation
Rather than cascading-deletes, Cloudflare OS uses lazy revocation: only the removed party’s incoming edges are severed. Their outgoing grants (edges they created to other users) remain intact. A downstream collaborator who loses their only path to the owner simply becomes unreachable and is denied atopen() time — no proactive cleanup required.
Example: Bob was added by Alice. Carol was added by Bob. Removing Alice severs Alice’s edge; Bob has no path to the owner; Carol loses her only path through Bob. All three are denied without any additional steps.
Revocation is reversible. Because the graph is never destructively pruned, re-adding Bob restores him and transitively restores Carol and all other users Bob had added — their records and outgoing edges were never deleted.
Revoking a share link
Revoking a share link sets arevoked flag on the link record. A revoked link contributes nothing to the permission graph; none of its keys can be redeemed; all users who gained access solely through it become unreachable. Records and edges are kept (no dangling references), so the graph stays consistent.
Preview before revoking
Before actually revoking, the UI callspreviewRemoveCollaborator() or previewRevokeShareLink(). This runs the effective-role computation with a hypothetical removal applied and returns the set of AffectedCollaborator records whose access would change — including downstream users who would be cut off.
If the preview reveals that removing someone would also cut off others, the UI warns you: “Removing Bob will also cut off Carol.” You can then choose to proceed, cancel, or use keepUsers to automatically re-root specific dependents so they retain access under a fresh direct edge.
Live session termination
Authorization is only checked atopen(), not per-message. To close the window where a just-removed collaborator could continue using an already-open session, Cloudflare OS proactively aborts the Gadget’s Overseer Durable Object whenever a removal or revocation actually changes access.
Edge is severed and flushed
The changed edge is written with
ctx.storage.sync() before anything else, ensuring the restart sees the updated graph.Overseer aborts after ~100 ms
A short delay lets the triggering RPC response reach the caller (typically the owner, who is also connected) before their own connection drops.
Home page behavior
Shared Gadgets do not appear on a collaborator’s home page until they first open one. On first open, a record is created in their account storing a cached title and the owner’s profile. ThelastActive timestamp updates each time they open the Gadget.
Shared Gadgets appear in the same home-page list as owned ones, with the owner’s name shown in the Owner column. Collaborators can dismiss a shared Gadget from their home page, but this does not revoke access — visiting the URL again will re-add it to the list.
When access is revoked, the stale entry lingers on the collaborator’s home page (Cloudflare OS does not proactively clean it up). The next time they try to open it, they see an access-denied message and can dismiss the dead entry.