# protobuf schema workflows: ad-hoc, bsr, and open source

## 1. the starting point: buf cli + ad-hoc file management

• >environment and onboarding friction: distributing raw files across repositories requires strict synchronization hygiene. whether relying on copy scripts, vendored folders, or shared repository mounts, developers frequently commit stale definitions, break fresh checkouts, and spend hours debugging path mismatches, access permissions, or custom sync scripts in Docker builds and CI runners.
• >unversioned upstream dependencies: without a registry, importing third-party standards (`google/api/annotations.proto`, `buf/validate/validate.proto`) means manually copying foreign `.proto` trees into your repository, losing cryptographic checksums and automated update paths.
• >diamond dependencies without a resolver: when multiple services depend on different versions of a shared common schema, raw file copies provide no module graph or lockfile (`buf.lock`) to resolve transitive collisions.
• >asynchronous codegen drift: copying schemas out-of-band means client code generation happens asynchronously, opening windows where downstream services run against stale or incompatible definitions.

## 2. the official upgrade: buf schema registry (buf.build)

• >central private module publishing: running `buf push` publishes versioned schemas to a managed registry, letting downstream services depend on schemas by module name instead of manually tracking raw files.
• >remote code generation: `buf generate` executes plugins remotely in the cloud, removing the need for developers or CI containers to install local `protoc` compiler toolchains.
• >enterprise governance: for organizations with complex compliance needs, `buf.build` adds hosted language package registries ([Generated SDKs](https://buf.build/docs/bsr/generated-sdks/)), custom plugin container hosting, [server-enforced review gates](https://buf.build/docs/bsr/checks/), per-repository RBAC, and SAML SSO.

## 3. the cost-avoidance detour: self-hosted protobuf registry alternatives (buffrs, pbuf.io)

### buffrs

• >bespoke toolchain and manifests: instead of standard `buf.yaml` and `buf.lock` files, every developer and CI runner must install a separate CLI binary and maintain custom manifests (`Proto.toml`).
• >
  loss of remote plugins and public modules:
  you forfeit access to remote plugins (`protocolbuffers/go`, `connectrpc/es`) and upstream dependencies (`googleapis`, `protovalidate`).
• >backend infrastructure requirements: buffrs is not a standalone registry server. hosting private packages requires your team to provision, configure, and license an enterprise JFrog Artifactory instance.

### pbuf.io

• >incompatible wire protocol: pbuf.io does not implement the BSR wire protocol. it requires teams to abandon standard `buf` CLI commands in favour of custom CLI binaries, manifests, and deployment patterns.
• >heavyweight infrastructure: the recommended deployment for pbuf.io requires provisioning and operating a Kubernetes cluster, a substantial operational burden for developer plumbing that sits entirely off the production request path.

## 4. the middle ground: protorip (protos.rip)

```yaml
version: v2
modules:
  - path: proto
    name: protos.rip/acme/platform
deps:
  - protos.rip/googleapis/googleapis
  - protos.rip/bufbuild/protovalidate
```

```bash
buf dep update
buf lint
buf breaking --against .git#branch=main
buf generate
buf push
```

• >drop-in buf CLI compatibility: no new CLIs, manifests, or plugins to learn. your `buf.yaml` files, `buf.lock` dependency graphs, and CI actions (`buf-setup`) work unchanged.
• >
  hosted community plugins & standard public modules:
  run `buf generate` remotely against standard plugins (`protocolbuffers/go`, `connectrpc/es`, `protocolbuffers/python`) and resolve upstream dependencies (`googleapis`, `protovalidate`) using the same module names and plugin identifiers you already use on buf.build.
• >predictable flat pricing: $9/month Solo, $49/month Team, and $0 for Free and [open source](/oss), with unlimited private modules, unlimited types, and unlimited team members, enabled by serverless edge economics rather than per-type metering.
• >zero infrastructure to manage: fully hosted and backed by Cloudflare edge primitives, providing high durability and low latency without requiring you to operate databases or maintain Kubernetes clusters.

## which workflow should you choose?

• >use `buf` CLI + ad-hoc file management if you have two or three consumer repositories, zero budget, and rarely change your `.proto` definitions.
• >use `buf.build` if your organisation needs hosted language package registries (Generated SDKs), server-enforced review gates, SAML SSO, or per-repository RBAC.
• >use self-hosted open source if strict air-gapped or regulatory mandates legally prohibit using a managed SaaS registry, and you have dedicated platform engineering bandwidth to maintain custom infrastructure and bespoke CLIs.
• >use protorip (`protos.rip`) if you want the standard `buf` CLI workflow, private modules, upstream dependencies, and remote code generation at a predictable flat price without maintaining ad-hoc sync scripts or operating servers.