The Pro and Enterprise plans include a private instance of the Buf Schema Registry (BSR), SSO/SCIM for user provisioning, and several other features to address security, compliance, and automation requirements specific to larger organizations. The pages in this section describe the setup and usage of your private BSR instance and point to relevant sections of the general documentation where there are differences from the public BSR at https://buf.build.

• Setup instructions for Pro plan
• Setup instructions for Enterprise plan

Features

• Private BSR and SSO/SCIM: Setting up your private BSR instance is a shared process with Buf engineers. We currently support all OIDC or SAML providers for SSO/SCIM, and have specific setup guides for these:

  • SSO: Github/OAuth2, Google/SAML, Okta/OIDC, Okta/SAML
  • SCIM: Azure/SAML, Okta/SAML

• Breaking change policy enforcement: On your private BSR, you can enforce a set of breaking change rules across all repositories. Once enabled, the server rejects attempts to push non-compliant schemas and warns the developer of the potential breaking change. See the policy enforcement and breaking change documentation for more information.

• Custom plugins: Teams, Pro, and Enterprise plans include the ability to upload custom plugins for logic specific to your business needs. See the custom plugins documentation for policy and implementation information.

• CI/CD integration: In addition to the Github Actions integration for the public BSR, Pro and Enterprise plans offer access to Buf’s GitHub App. The app synchronizes your Protobuf source control with your private BSR instance, and automatically performs breaking change detection, linting, and formatting.

  • Server machine users: Pro and Enterprise plans allow you to create server machine users that can call the BSR from CI workflows without tying the actions to a specific person.

• Audit logging: BSR server administrators can query the private BSR instance about several types of events and actions on the server. See audit logs and the audit API documentation for more information.

• Webhooks: You can enable webhooks to trigger actions in other backend services, such as CI/CD or notification workflows. They are disabled by default.