Skip to main content
Protected branches restrict who in your org can read or write a specific branch. Use them for production, customer data, or anything where org-wide access is too broad.

​
Creating a protected branch

The --protected flag marks the branch as invite-only at creation. By default only the branch creator has access; every other member must be explicitly granted.

​
Access model

  • Org-wide branches (the default, e.g., development) - every active member of the org can read and write.
  • Protected branches - the branch has its own membership list, stored on the service alongside the branch. Only users on the list can co-decrypt the branch blob.
Protected branches use the same cryptographic enforcement as org-level membership: the service gates co-decrypt requests against the branch access list before returning the service’s half of the key. A user without access gets a 403 - there’s nothing to attack.

​
Granting access

Two ways to grant a member access to a protected branch. capy users opens the interactive members list. Expand a member with Enter, expand the project they should have branch access on, and the protected branches in that project appear with their grant status:
Move the cursor onto a (no access) branch row and press g to grant. The status flips to (granted) immediately. Press g again on a (granted) row to revoke.

​
From scripts and CI

Two non-interactive subcommands wrap the same calls - useful in automation:
Both take <email> <project> <branch> and exit non-zero on failure. The interactive TUI dispatches to the same service endpoints, so behavior is identical.

​
Typical split

​
What’s next

Branches overview

How branches fit into the sync loop.
Last modified on May 20, 2026