[Go to site: main page, start]
Skip to content

Buf Schema Registry#

The Buf Schema Registry (BSR) is a Protobuf-aware registry for Buf modules (versioned bundles of .proto files plus their dependencies). The BSR runs as a public service at buf.build (so a public module like connectrpc/eliza is addressable as buf.build/connectrpc/eliza) and as a private instance for organizations that need their own host on Pro, Enterprise, or on-prem.

Each module has two sets of users: producers, who develop its Protobuf files, and consumers, who install generated SDKs, browse documentation, test RPCs in Studio, or develop other BSR modules depending on this one. Both users can rely on registry-side checks to reject broken commits at push time.

If you want to start hands-on rather than read about the BSR, head to the BSR quickstart; it walks through pushing and consuming a module end-to-end in around ten minutes.

What you can do with the BSR#

  • Publish Protobuf files as versioned modules. buf push sends a module to the BSR; every push is a commit, and labels mark commits for downstream consumers (the default label tracks released versions).
  • Resolve module dependencies. Declare deps: in buf.yaml against module names; buf dep update resolves them into buf.lock. See dependency management.
  • Browse and link documentation. Every commit has a generated, syntax-highlighted API documentation page with cross-references between types.
  • Generate code remotely. Hosted plugins run on the BSR; reference them in buf.gen.yaml and buf generate writes the output locally without a local toolchain.
  • Install SDKs generated for modules. Each supported language has a native registry on the BSR, so consumers run go get, npm install, cargo add, mvn, pip install, and friends against native registries at buf.build/... without producing stubs locally. See Generated SDKs.
  • Enforce Protobuf standards on every push. BSR checks run lint, breaking-change, and review-commit policies on the registry side; broken pushes are rejected before they reach consumers.

Why a Protobuf-aware registry#

Plain Git repositories of .proto files don’t enforce compilation, don’t model dependencies, and don’t help downstream language workflows. The BSR addresses each of those gaps directly:

  • Build guarantees. The BSR rejects pushes that don’t compile or that break the configured policies, so consumers fetching by module name aren’t surprised by broken or incompatible .proto files.
  • One source of truth. Modules are addressable by name (buf.build/owner/name), with explicit version history. Forked or out-of-date copies of the same .proto files don’t drift through the ecosystem the way they do in a checked-in-anywhere model.
  • Native package-manager install. Clients install language packages by name from their existing package manager, instead of running protoc against a vendored snapshot.

For teams using the Buf CLI today, publishing to the BSR is the step that makes the local workflow scale: the same schema that passes buf lint, buf breaking, and buf generate locally becomes a governed dependency with generated SDKs, docs, Studio access, and CI/CD automation.

Next steps#