Protorip
sign in
dashboard
---
site: protos.rip
page: blog/why-protorip
---
           __         
 _      __/ /_  __  __
| | /| / / __ \/ / / /
| |/ |/ / / / / /_/ / 
|__/|__/_/ /_/\__, /  
             /____/

# Why we built Protorip: schema hosting without the per-type tax

I have used the `buf` CLI across multiple jobs for Connect, gRPC, and Twirp services. In almost every technical dimension, it is one of the best developer tools built in the past decade. It took Protocol Buffers out of the era of brittle `protoc` bash scripts, obscure `-I` include flags, and unversioned schemas, replacing them with clean `buf.yaml` configurations, fast linting, breaking-change detection, and reproducible dependency digests.
Yet across all those projects, I never once considered adopting the hosted Buf Schema Registry (BSR).
The moment you look at the pricing, you hit immediate sticker shock: $0.50 per private type per month on Teams, and $5.00 per type per month on Pro ($3,000 monthly minimum).

## GitHub does not charge per line of code

In modern software development, package and registry management is solved infrastructure:
  • >If you write JavaScript, npm gives you package hosting.
  • >If you write Rust, crates.io and Cargo registries handle dependencies.
  • >If you write Go, `proxy.golang.org` and private module proxies handle resolution.
  • >If you package containers, Docker registries charge for storage or bandwidth.
None of these services charge you for the size or structure of your code. GitHub does not bill per line of code. Docker Hub does not bill per container layer. An npm registry does not bill per exported JavaScript function.
Yet when you look at schema registries, `buf.build` asks you to pay for the size of your schema. Every `message`, `enum`, and `rpc` is a billable unit.
The moment a developer sees that, something fundamental breaks. When you are sitting down to design API contracts, your mind should be focused on domain modeling, ergonomics, and backwards compatibility. Instead, per-type pricing forces you to think about billing.
If you follow the official Protobuf style guide and Buf’s own `buf lint` rules, you define dedicated Request and Response messages for every single RPC. That is basic API hygiene—it ensures you can evolve endpoints later without breaking older clients. Under per-type billing, following that best practice literally doubles your type count. Adding an enum variant or breaking a messy message into two cleaner types shows up directly on your monthly invoice.
The bill does not grow because your company is growing or because your traffic increased. It grows simply because you wrote more code.

## The ad-hoc workaround: functional, but archaic

Faced with that pricing, I did what almost every other developer I know did: I walked away from the registry and cobbled together ad-hoc Git workflows.
We kept the excellent `buf` CLI for local linting, breaking change detection, and code generation, but shared `.proto` files between repositories using Git submodules, sparse checkouts, or custom CI sync scripts that opened automated pull requests across repositories.
At the scale of a few microservices, ad-hoc Git flows are not the end of the world. They work. But they feel deeply archaic.
Developers in every other ecosystem take central dependency resolution for granted. With Git submodules, you are back to fighting commit pointer drift, dealing with SSH deployment keys in CI containers, manually vendoring upstream files like `googleapis` or `protovalidate`, and resolving diamond dependencies by hand.
The `buf` CLI already solved all of this elegantly: `buf push`, `buf dep update`, `buf.lock` with content-addressed `b5` digests, and remote plugin generation. The only reason developers were not using those workflows was an artificial pricing wall on the hosted service.

## Why Cloudflare’s economics change the equation

I have been an avid follower of Cloudflare’s neo-cloud and developer platform innovations. Looking at what Cloudflare built with Workers, D1, and R2, an obvious realization hit:
The `buf` CLI is open source (Apache-2.0). The BSR protocol (`bufbuild/registry-proto`) is open source. And a schema registry, at its core, is a low-bandwidth metadata coordination service.
A large enterprise Protobuf repository is rarely more than a few megabytes. Storing `.proto` files in R2 costs fractions of a cent. Querying module graphs and verifying dependency digests in Cloudflare D1 and Workers takes milliseconds of lightweight compute.
Buf is a venture-backed company that raised over $90M. Their cost structure and valuation necessitated finding enterprise-scale Annual Contract Values (ACVs), which produced an escalating, punitive pricing model geared toward enterprise buyers (and led them to focus heavily on Bufstream and Kafka infrastructure).
Protorip does not have that venture overhang. By building natively on Cloudflare’s edge primitives, our marginal cost per customer is negligible. We can offer:
  • >Free ($0): Unlimited public modules and 1 private module for solo developers.
  • >Solo ($9/month): Unlimited private modules for individuals building real projects.
  • >Team ($49/month flat): Unlimited private modules, unlimited types, and unlimited members for entire engineering teams.
  • >Open Source ($0): Free team accounts for eligible public OSS projects.
We don’t need per-type meters or arbitrary usage gates to run a healthy, sustainable business at these prices. Cloudflare’s economics make flat pricing profitable from day one.

## The division of labor: what we build vs what we leave to Buf

We are not trying to be a 1:1 clone of `buf.build`’s enterprise platform.
Buf built a large enterprise suite that includes hosted package registries ([Generated SDKs](https://buf.build/docs/bsr/generated-sdks/) for npm, Go, Maven, PyPI, Cargo, and Swift), custom plugin hosting, server-side review gates, SAML SSO, and single-tenant instances. If you are a 500-person enterprise that needs pre-compiled npm packages and SAML integration, Buf built that platform for you, and you should use it.
Protorip focuses on the everyday developer loop:
  • >Full `buf` CLI compatibility: Push modules, lock dependency graphs, and resolve schemas using standard `buf.yaml` v2 configurations.
  • >Mirrored upstream modules: Standard dependencies like `googleapis`, `protovalidate`, and `grpc-gateway` are mirrored under identical paths on `protos.rip`.
  • >Mirrored community remote plugins: Run `buf generate` with standard community plugins (`protocolbuffers/go`, `connectrpc/es`, `grpc/go`, and more) without configuring local compilers.
  • >CI-first philosophy: You run `buf lint` and `buf breaking` in GitHub Actions or your existing CI pipeline where they belong, rather than paying an expensive registry to duplicate those checks on the server.
You shouldn’t have to choose between paying an enterprise tax or resorting to Git submodules. With Protorip, you get the first-class `buf` CLI workflow you already know, hosted on fair, transparent infrastructure that never asks you to count your lines of code.
Compare [Protorip vs buf.build](/compare/buf), evaluate [Protobuf schema workflows](/compare/workflows), review [pricing](/pricing), or [get started for free](/dashboard).