Documentation

PrivateCrates implements Cargo’s sparse registry protocol in front of your GitHub organisation. GitHub stays the store, the identity provider and the source of truth for permissions.

The model in one paragraph

Crate files are stored as GitHub release assets in a private repository your organisation owns, and the registry index lives in the same repository. Each crate has an owning repository, usually the one its code is in. Anyone who can read that repository on GitHub can use the crate; anyone who can push to it can publish it, from CI. There are no separate accounts, keys or access lists.

Guides

  • Set up a registry: install the Apps, create the storage repository, choose a name, and configure Cargo on developers’ machines.
  • Set up with an AI agent: let Claude Code or another coding agent set up the registry and configure your crates, with the cargo privatecrates CLI and your own gh login.
  • CI without secrets: read crates from GitHub Actions with OIDC, and build Docker images or use other CI safely.
  • Publishing: trusted publishing from Actions, the owners file, first publishes, yanking and publishing from a laptop.
  • Verify the registry: run privatecrates-verify on a schedule to check everything PrivateCrates writes.
  • Security model: what we see, what we store, and what happens if a token, a key or the service itself is compromised.
  • Error reference: every error code the registry returns, and what to do about it.

Names used in examples

The examples use an organisation called acme, whose registry is also named acme and served at https://acme.privatecrates.dev, and a crate called story_engine owned by the repository acme/story-engine. Replace them with your own; the account page shows your registry’s exact configuration once it is live.