---
site: protos.rip
page: blog/why-protorip
---
__ __ _
_ __/ /_ __ __ ____ _________ / /_____ _____(_)___
| | /| / / __ \/ / / / / __ \/ ___/ __ \/ __/ __ \/ ___/ / __ \
| |/ |/ / / / / /_/ / / /_/ / / / /_/ / /_/ /_/ / / / / /_/ /
|__/|__/_/ /_/\__, / / .___/_/ \____/\__/\____/_/ /_/ .___/
/____/ /_/ /_/ # Why we built Protorip
I first started using the
`buf` CLI when our team needed to manage RPC calls between our microservices.We had first tried to pilot cross-service calls with GraphQL since we already used that extensively for our frontend APIs. This came with obvious drawbacks: GraphQL’s design is squarely oriented at frontend or third-party API consumption (field selection, separate query/mutation model, single endpoint, and runtime query compilation).
What we really valued from GraphQL and needed was a tool that gave us a clear, readable, and hand-editable schema definition language without the heavy UI-based editing workflow of OpenAPI or the open-ended nature of REST design.
Protocol Buffers, as well as Connect RPC and the
`buf` CLI, gave us the schema-first definition language we needed to easily author our APIs as RPCs, with auto-generated typed clients and an ecosystem and community that prioritised tight, focused tooling that let you skip worrying about your API implementation and move on with validating your product.## Managing Protocol Buffers across repos
In our initial
`buf` workflows, our monorepo architecture made sharing proto definitions and generating server stubs and client code trivial. But moving towards separating out repos presented some challenges.To safely roll out API changes, you need to update your proto definitions, implement handlers in your server, and sync your changes to consuming clients.
To manage this without copying files around, we generated clients next to the server and proto definitions and distributed them through the standard npm package lifecycle. This introduced a surprising amount of ceremony: changesets, version bumps, waiting for CI to publish, private registry authentication, and bumping versions in consumers, all of that whether making a major change or just adding another endpoint or field.
## Buf modules and the Buf Schema Registry (BSR)
The
`buf` CLI comes with a solution to this problem built in: Buf modules. A module bundles up your proto files into a single package that can be published to a central registry: the Buf Schema Registry. That way you can easily have your CI publish new versions on commit or tag, and updating consumers becomes as simple as bumping a version and regenerating your client.Even better, BSR’s automatic SDK generation provides auto-generated client code as dependencies from a registry native to your language ecosystem (like npm, Cargo, or
`go mod`) without you having to configure any compilation, bundling, or package management process yourself.## The friction of per-type pricing
Unfortunately for most teams, Buf’s private module hosting has a fatal flaw: its pricing model. On Buf’s published pricing, its free tier can only be used to publish one private module with up to 100 types.
Buf uses an unconventional pricing model that they claim ties the value they provide to you to the charged bill: pay per type. Each type (a message, enum, or RPC method) costs $0.50 per month on Teams, or $5.00 on Pro with a $3,000 minimum. That means you commit to at least a $1.50/mo bill every time you add just one new method to your API (one RPC, Request message, and Response message).
In modern software development, code distribution and package hosting is basic infrastructure. Unlike database migrations, managed queues, or cloud functions, distributing Protobuf schemas incurs no operational overheads: BSR does not have to provision new runtime infrastructure for you when you add a new type, nor do they receive any traffic that scales with the production load of your app.
Per-type metering is a restrictive pricing model that interferes with a developer’s core work and is at odds with everyday software design. Organising and extending an API should not be a cost-management exercise. And pinning bills to an arbitrary measure of your product like API type count represents a fundamental disconnect between the value BSR offers you and the success of your own product. GitHub doesn’t charge per line of code, but Buf Schema Registry charges you per API type.
Whether you’re a scrappy startup trying to avoid unnecessary overheads, or a well-funded team willing to spend money to trade for developer velocity, per-type billing presents an unpredictable, ever-growing cost that makes no sense.
I have never used a paid BSR plan, and because of its broken pricing model I will never be able to justify it to myself or my teams. The Buf team brought a revolution in Protobuf developer workflows and popularised Protobuf as an efficient everyday API format through Connect, but they locked a key piece of the workflow behind a restrictive pricing model that punishes developers for success.
For teams like ours who just need simple, reliable module hosting and versioning, paying hundreds or thousands of dollars a month for developer convenience tooling just doesn’t add up.
## Enter Protorip: the drop-in replacement for BSR
The good news is that the
`buf` CLI, and the BSR protocol it uses to talk to the registry, are [open source](https://github.com/bufbuild/registry-proto).Buf published the protocol specification years ago, but until now there hasn’t been a popular second implementation.
We’re here to change that. We built the
`protos.rip` registry to be the drop-in BSR replacement that works seamlessly with your existing `buf` CLI workflows.By offering Protorip at predictable, low costs for private registry hosting ($9/mo Solo, $49/mo Team), we can unlock the core
`buf` workflow that was always intended, for teams of any scale.Because we implement the same open BSR protocol, you can swap just by directing your existing configs to the
`protos.rip` domain:```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```## Building on Cloudflare economics
How can Protorip offer flat, predictable pricing with unlimited types when Buf won’t?
At its core, the Buf Schema Registry is fundamentally a versioned file store with some metadata and a Connect API that the
`buf` CLI talks to.Over the last few years, Cloudflare has brought globally distributed edge storage and compute to developers at tiny marginal costs. By building Protorip natively on Cloudflare Workers, D1, and R2, we can store and serve your protos at scale sustainably with low overheads.
That lets us offer fair, flat-priced plans with zero metering for module hosting. Host as many modules with as many types as you want.
## The best of `buf` CLI for all
Today
`protos.rip` supports the core `buf` CLI workflows for managing modules and the registry. We provide the same core public modules (`googleapis`, `protovalidate`, `grpc-gateway`) under matching registry paths so you can migrate with minimal interruptions.And next on the horizon is support for remote code generation plugins via
`buf generate`, so you can generate clients, stubs, and documentation without needing to worry about setting up the `protoc` compiler or plugin dependencies in development or CI. As Protorip grows, we’re looking to provide more of the registry features developers love, such as generated SDK packages.Protorip unlocks the original vision for the
`buf` CLI by providing the missing piece: a dependable, flat-rate schema registry that lets you focus on designing your APIs, not managing your type count.