---
site: protos.rip
page: blog/why-protorip
---
__ __
/ /_ / /___ ____ _
/ __ \/ / __ \/ __ `/
/ /_/ / / /_/ / /_/ /
/_.___/_/\____/\__, /
/____/ # Why I built a flat-rate Buf Schema Registry
Marc Porciuncula, Founder of Strange Computer
I first started using the
`buf` CLI when our team needed to manage RPC calls between microservices.We had piloted cross-service calls with GraphQL because we already used it heavily for frontend APIs. That ran into obvious friction: GraphQL is built around client field selection, separate query and mutation roots, a single endpoint, and runtime query compilation.
What we actually wanted was a clear, hand-editable schema language without OpenAPI’s UI-heavy editing cycle or the ambiguity of ad-hoc REST conventions. Protocol Buffers, Connect RPC, and the
`buf` CLI gave us that schema-first workflow: typed RPC contracts, generated clients, and focused tooling that stayed out of the way.## Managing Protocol Buffers across repos
In a monorepo, sharing
`.proto` files and generating server stubs and client code was trivial. Splitting services into separate repositories changed that.To roll out an API change safely across repos, you have to update your proto definitions, implement the server handlers, and sync updated types to consuming clients. Without copying files around, we generated clients alongside the server and published them as private npm packages. That brought a surprising amount of ceremony: changesets, version bumps, CI publish waits, private registry tokens, and consumer version bumps, whether shipping a breaking change or adding one field.
## Buf modules and the Buf Schema Registry (BSR)
The
`buf` CLI has a built-in answer to this: Buf modules. A module bundles your proto files into a versioned package hosted on a central registry, the Buf Schema Registry (BSR). CI can push new commits on merge or tag, and updating a consumer becomes a `buf dep update` and a client regeneration.## The friction of per-type pricing
For most teams, Buf’s private hosting has one dealbreaker: its pricing model. On Buf’s published pricing, the free tier covers one private module with up to 100 types.
Every additional type (a message, enum, or RPC method) costs $0.50 per month on Teams, or $5.00 on Pro with a $3,000 monthly minimum. Adding a single RPC endpoint (one method, a Request message, and a Response message) adds at least $1.50/month to your recurring bill!
Schema hosting is basic package infrastructure. Unlike managed databases, queues, or compute, storing and serving Protobuf definitions carries no per-type operational overhead: BSR doesn’t provision extra runtime infrastructure when you add a message, and it receives zero production traffic from your app.
Organising and extending an API shouldn’t turn into a cost-management exercise. GitHub doesn’t charge per line of code, yet the Buf Schema Registry charges per API type.
I’ve never used a paid BSR plan, and with per-type billing I could never justify it to myself or my teams. Buf moved Protobuf workflows forward with
`buf` and Connect, then gated private module hosting behind a meter that penalises teams for growing their APIs.## Building a drop-in BSR alternative
The good news is that the
`buf` CLI and the BSR protocol it speaks are [open source](https://github.com/bufbuild/registry-proto). Buf published the protocol specification years ago, yet there still wasn’t a widely adopted second implementation.So I built
`protos.rip` as a drop-in BSR replacement for core `buf` CLI workflows: publishing modules, resolving dependencies, and locking versions.With flat monthly pricing instead of per-type metering (see [pricing](/pricing)), teams of any size can keep the
`buf` workflow without counting messages or enums. Because Protorip implements the same open BSR protocol, migrating your config is a hostname swap:```diff version: v2 modules: - path: proto- name: buf.build/acme/orderapis+ name: protos.rip/acme/orderapis deps:- - buf.build/googleapis/googleapis- - buf.build/bufbuild/protovalidate+ - protos.rip/googleapis/googleapis+ - protos.rip/bufbuild/protovalidate```## Running on Cloudflare economics
How can Protorip offer flat, predictable pricing with unlimited types when Buf won’t?
At its core, a Protobuf schema registry is a versioned file store with metadata and a Connect API that the
`buf` CLI talks to.By building Protorip natively on Cloudflare Workers, D1, and R2, I can store and serve schemas globally with low marginal costs. That keeps unit economics simple enough to offer flat plans with zero type metering: host as many modules and types as you want.
## Where Protorip starts
Today
`protos.rip` supports the core `buf` CLI workflows: `buf registry login`, `buf push`, `buf dep update`, `buf build`, and module, label, and commit management. It also hosts the core public modules (`googleapis`, `protovalidate`, `grpc-gateway`, `wellknowntypes`) under matching paths so existing dependency graphs resolve without rewrites, alongside browsable docs and `.proto` file trees on the web.Next up is expanding CLI coverage further and adding hosted remote code generation plugins so teams can run
`buf generate` without installing `protoc` locally.