# Protobuf schema workflows: Protorip vs buf.build vs Git submodules & OSS tools

## 1. The default workaround: `buf` CLI + ad-hoc Git wiring

• >Git submodules or `git subtree`: Each service repository mounts a shared `protos/` repository at a pinned commit.
• >CI sync bots: Pushing to a central schema repo triggers a GitHub Action that opens pull requests copying `.proto` files or generated code into downstream repos.
• >Pre-built images in object storage: CI runs `buf build -o image.binpb`, uploads the artifact to S3 or GitHub Releases, and consumer repos run a custom wrapper script to fetch it before building.

### Where ad-hoc wiring breaks down

• >Submodule drift and broken onboarding: Developers forget `git submodule update --init --recursive`, accidentally commit rolled-back submodule pointers in unrelated PRs, or fight SSH/PAT token permissions inside Docker builds and CI runners.
• >Vendoring public upstream schemas: Without a registry, importing `google/api/annotations.proto` or `buf/validate/validate.proto` means copying third-party `.proto` trees directly into your repository and keeping them updated by hand.
• >Diamond dependency conflicts: When Service A depends on Common Protos and Event Protos, and Event Protos also depends on Common Protos, raw Git checkouts have no module graph or content-addressed lockfile (`buf.lock`) to resolve them cleanly.

## 2. Alternative open-source Protobuf package managers (`buffrs`, `protodep`)

### The hidden cost: leaving the `buf` CLI ecosystem

• >Custom manifests and CLIs: Instead of standard `buf.yaml` and `buf.lock` files, every consumer must install a separate CLI binary and maintain a tool-specific manifest (`Proto.toml` or `protodep.toml`).
• >Different resolution semantics: Tools like `buffrs` enforce their own packaging constraints and unpack files into local vendor directories, requiring extra wiring so `buf lint` or `protoc` can discover them.
• >Loss of remote plugins and upstream mirrors: You lose access to `buf generate` remote plugins (`protocolbuffers/go`, `connectrpc/es`, etc.) and curated upstream modules (`googleapis`, `protovalidate`).
• >You still have to run a backend: `buffrs` is not a standalone server; it relies on a JFog Artifactory instance to host packages.

## 3. Why not self-host an open-source BSR?

• >No open-source BSR server exists: While the [BSR protocol definitions](https://github.com/bufbuild/registry-proto) and the `buf` CLI are open source (Apache-2.0), the server implementation (including dependency graph resolution, legacy `v1alpha1` CLI endpoints, upstream module syncing, and containerised remote plugin execution) has no open-source equivalent.
• >Self-hosting defeats the point of a central schema registry: A schema registry exists to eliminate infrastructure plumbing between repositories. Provisioning and maintaining your own database, blob storage, authentication, upstream mirror syncs, and sandboxed codegen containers creates more operational burden than the schema-sharing problem it solves.

## 4. Managed BSR compatibility: Protorip vs `buf.build`

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

• >Protorip (`protos.rip`) gives you the core registry and codegen workflow at a flat utility price ($9/month Solo, $49/month Team, $0 for Free and [open source](/oss)). It supports `buf push`, `buf dep update`, `buf build`, and `buf generate` with the same mirrored community remote plugins and upstream public modules maintained on `buf.build`, while leaving linting and breaking-change enforcement in your CI pipeline where they already run.
• >`buf.build` adds an enterprise control plane on top of the registry: hosted language package registries ([Generated SDKs](https://buf.build/docs/bsr/generated-sdks/) for npm, Go, Maven, PyPI, Cargo, and Swift), custom plugin hosting, [server-enforced schema checks](https://buf.build/docs/bsr/checks/), per-repository RBAC, SAML SSO, and dedicated private instances, priced at $0.50 per private type per month on Teams or from $3,000/month on Pro.

## Which workflow should you choose?

• >Use `buf` CLI + Git submodules only if you have a single consumer repository, zero budget, and rarely touch your `.proto` definitions.
• >Use Protorip (`protos.rip`) if you want the standard `buf` CLI workflow, private modules, upstream dependencies, and remote code generation plugins without maintaining Git glue scripts or paying per Protobuf type.
• >Use `buf.build` if your organisation needs hosted npm/Go/Maven package registries (Generated SDKs), server-enforced review gates, SAML SSO, or per-repository RBAC.