Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.capy.sc/llms.txt

Use this file to discover all available pages before exploring further.

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

capy checkout --protected -b production
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: 
> alice@acme.com                 admin          2025-01-15    2 projects
    api-backend          admin
      main               (org-wide)
      production         (granted)
    web-frontend         member
      main               (org-wide)
      production         (no access)
   ↑↓ navigate  Enter expand/collapse  r change role  g grant protected  q quit
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: 
capy grant-branch  alice@acme.com web-frontend production
capy revoke-branch alice@acme.com web-frontend production
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

development  — org-wide, everyone
staging      — org-wide, everyone
production   — protected, ops + on-call only

​
What’s next

Branches overview

How branches fit into the sync loop.