> ## Documentation Index
> Fetch the complete documentation index at: https://capy.sc/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Protected Branches: Lock Down Production Secrets

> Restrict production secrets to a vetted subset of your team. Capy protected branches are invite-only at the cryptographic layer — only members can decrypt.

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

```bash theme={null}
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.

### From the TUI (recommended)

`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:

```text theme={null}
> 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:

```bash theme={null}
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

<Card title="Branches overview" icon="code-branch" href="/using/branches/overview" horizontal>
  How branches fit into the sync loop.
</Card>
