Types are any of the following:

• Messages
• Enums
• RPCs

For example, the following code has 6 types:

// 1
message Vehicle {
    string id = 1;
    Make make = 2;
}

// 2
enum Make {
    MAKE_UNSPECIFIED = 0;
    MAKE_ACME = 1;
}

// 3
message GetVehicleRequest {
    string id = 1;
}

// 4
message CreateVehicleRequest {
    Vehicle vehicle = 1;
}

service VehicleService {
    // 5
    rpc GetVehicle(GetVehicleRequest) returns (Vehicle);
    // 6
    rpc CreateVehicle(CreateVehicleRequest) returns (Vehicle);
}

• For Teams, any types within your organization that are in private repositories are billed.
• For Pro, all types within your instance in public and private repositories are billed, as public repositories are still private to your instance. As an exception, all types within managed modules (such as googleapis) that Buf pushes to your instance on your behalf are not billed.

We considered this carefully: types may not be the first thing that comes to mind in terms of how to charge. In the end, we chose types for one simple reason: we want to bill in the fairest manner possible. The value you get out of the BSR should be correlated to what you pay us, without worrying about how to structure your APIs for optimal billing. The volume of API definitions you have stored on the BSR correlates with your usage of the BSR, and messages, enums, and RPCs make up the core of a Protobuf API definition. While types are a bit more complicated to reason about, charging based on your actual usage of the BSR results in a fairer experience for everyone - no matter how many repositories or users you have, your billing remains correlated to how much you actually use the BSR.

Our CLI provides a tool to calculate this:

$ buf beta price

If your code works with buf lint, buf breaking, or buf generate, it will work with buf beta price. Run this command to estimate the cost of your APIs on the BSR, it's that simple. See the  installation instructions to get started with the Buf CLI. Note that the command is in beta, and may change - make sure you are using the latest version of the CLI for the most up-to-date pricing estimations!

We calculate the average number of types over your billing cycle.

For example, on Teams:

• If you have 100 types in private repositories during your billing cycle, you'll be billed $50 for the month.
• If you have 100 types in private repositories for the first half of your billing cycle, and 200 types for the second half, you averaged 150 types over your billing cycle, and you'll be billed $75 for the month.

We want to ensure you're made aware when the number of types within your organization is higher than you expect. We know that mistakes happen, and we want you to be able to take corrective action as soon as possible. In order to receive notifications, you will need to configure usage alerts. Configure alerts on your organization settings page. Alerts will notify all organization admins via email when the configured threshold is exceeded.

Yes - in the Vehicle example below, your billing would be the same whether or not Make was nested within Vehicle:

// 1
message Vehicle {
    // 2
    enum Make {
        MAKE_UNSPECIFIED = 0;
        MAKE_ACME = 1;
    }
    string id = 1;
    Make make = 2;
}

Community plan users and organizations may have 1 private repo with up to 100 types. Teams and Pro organizations are entitled to unlimited private repositories with no limit on the number of types.

Not yet— it's something we'd like to add in the future. For now, if you want to utilize the features of our paid plans, create an organization and use Teams or Pro.

No, types in branches or tags are not currently counted toward your total types. If we count them in the future, we will ensure that types within branches or tags are not double-billed.

At this time we only offer annual billing on the Enterprise plan, but let us know if you'd like an annual option for Teams or Pro - we appreciate the feedback.