Federation#
Deprecated feature#
We recommend using the default managed modules feature, which synchronizes the community modules hosted in the public BSR to your private BSR instance.
Introduction#
Federation allows Buf modules to depend on modules hosted on different BSR instances.
For example, a module on buf.example.com may depend on a public BSR module like buf.build/googleapis/googleapis.
Although hosted on a different remote, federated dependencies work the same as regular dependencies.
Use of Federation creates a dependency between your single-tenant instance and buf.build.
For this reason, federation is turned off by default for new customers.
If you wish to use this feature, please reach out to a Buf representative.
Limitations#
Depending on a module from buf.build doesn't automatically mirror this module into your BSR.
Federation is currently only supported between enterprise instances (for instance buf.example.com) and public buf.build modules.
See the table below for an overview:
| Module | Dependency | Supported | 
|---|---|---|
| buf.example.com/foo/bar | buf.build/user/public-repository | Yes | 
| buf.example.com/foo/bar | buf.build/user/private-repository | No (dependencies on private modules not supported) | 
| buf.example.com/foo/bar | different-buf.example.org/user/repository | No (dependencies between enterprise BSRs not supported) | 
| buf.build/foo/bar | buf.example.com/user/public-repository | No (federation is a enterprise-only feature) | 
Migration#
The easiest way to move away from federated modules is to depend on a local copy. The BSR automatically synchronizes a list of well-known community modules using the managed modules feature.
Manual upload#
If the module that you want to sync can't be added to the managed modules repository, then you can manually upload a copy to your instance:
- Export the module from buf.build to a local directory.
- Initialize a new local module under the buf.example.comprivate instance.
- Create the organization and repository.
- Push the module.