The registry provides a central place to store and manage your protobuf files.
The protobuf files are usually stored in the same repository as the code that uses them. This approach works well for small projects, but it becomes a problem when you have multiple repositories that use the same protobuf files. In this case, you have to copy manually the files to each repository, which is not only tedious but also error-prone.
The registry solves this problem by providing a central place to store and manage your protobuf files and sync the files with your repositories.
- Clone the repository
- Generate certificates with
make certs-gencommand (they will appear ingen/certsfolder) or put your own certificates in the folder - Export
SERVER_STATIC_TOKENwith static authorization token - Run
make run-prodto start the registry - Run
make stop-prodto stop the running registry
The registry can be configured with environment variables that overrides values in the config/config.yaml file. For instance, to change the database DSN you can set DATA_DATABASE_DSN environment variable that is reflect to data.database.dsn yaml property.
- Helm
- Postgres database should be provisioned separately
Add repository to Helm:
helm repo add pbuf https://pbufio.github.io/helm-chartsTo install the chart with the release name my-pbuf-registry:
helm install my-pbuf-registry pbuf/pbuf-registry --set secrets.databaseDSN=<databaseDSN>More information about the chart can be found in the chart repository
Once the registry is running, try these commands to see it in action:
Prerequisites: Install pbuf
# 1. Configure pbuf to point to your registry
export PBUF_REGISTRY_URL=https://localhost:6777
export PBUF_REGISTRY_TOKEN=${SERVER_STATIC_TOKEN}
# 2. Register a new module (module name comes from pbuf.yaml)
pbuf modules register
# 3. Push your first tag (from a directory with .proto files and pbuf.yaml)
pbuf modules push v1.0.0
# 4. Pull dependencies (add module to pbuf.yaml's modules section, then run)
pbuf vendorNew to pbuf? Check out the examples/ directory for a complete walkthrough with sample protobuf files.
The registry supports role-based access control with fine-grained permissions per module.
The registry supports two types of authentication:
- Admin Token - The
SERVER_STATIC_TOKENenvironment variable serves as the admin token with full access to all operations - User/Bot Tokens - Generated tokens for users and bots with configurable permissions
- Read - Pull modules, list modules, view metadata
- Write - Read + Push modules, register new modules
- Admin - Write + Delete modules and tags
Permissions can be granted per module or globally using * as the module name.
Only admins can manage users, bots, and permissions.
# Using grpcurl (requires generated proto files)
grpcurl -H "Authorization: Bearer ${ADMIN_TOKEN}" \
-d '{"name": "ci-bot", "type": "USER_TYPE_BOT"}' \
localhost:6777 pbufregistry.v1.UserService/CreateUserReturns a response with the user details and a generated token (only shown once):
{
"user": {"id": "...", "name": "ci-bot", "type": "USER_TYPE_BOT", ...},
"token": "pbuf_bot_<random>"
}# Grant read permission on a specific module
grpcurl -H "Authorization: Bearer ${ADMIN_TOKEN}" \
-d '{"user_id": "<user-id>", "module_name": "my-module", "permission": "PERMISSION_READ"}' \
localhost:6777 pbufregistry.v1.UserService/GrantPermission
# Grant write permission on all modules
grpcurl -H "Authorization: Bearer ${ADMIN_TOKEN}" \
-d '{"user_id": "<user-id>", "module_name": "*", "permission": "PERMISSION_WRITE"}' \
localhost:6777 pbufregistry.v1.UserService/GrantPermissiongrpcurl -H "Authorization: Bearer ${ADMIN_TOKEN}" \
localhost:6777 pbufregistry.v1.UserService/ListUsersgrpcurl -H "Authorization: Bearer ${ADMIN_TOKEN}" \
-d '{"user_id": "<user-id>", "module_name": "my-module"}' \
localhost:6777 pbufregistry.v1.UserService/RevokePermissiongrpcurl -H "Authorization: Bearer ${ADMIN_TOKEN}" \
-d '{"id": "<user-id>"}' \
localhost:6777 pbufregistry.v1.UserService/RegenerateTokenOnce a user or bot has been created and granted permissions, they can authenticate using their token:
# Configure pbuf CLI with user/bot token
export PBUF_REGISTRY_TOKEN="pbuf_bot_<random>"
# Now the bot can perform operations based on its permissions
pbuf modules pull my-module v1.0.0 # Requires read permission
pbuf modules push v1.0.0 # Requires write permission- Tokens are generated using cryptographically secure random bytes (32 bytes)
- Tokens are encrypted in the database using PostgreSQL pgcrypto extension (bcrypt)
- Token format:
pbuf_<type>_<base64_random>(e.g.,pbuf_bot_abc123...) - Tokens are only displayed once during creation or regeneration
For more details, see ACL.md.
We recommend to use the pbuf CLI to interact with the registry.
The registry provides a REST API (:8080 port by default). You can find the swagger documentation here.
The registry provides a gRPC API (:6777 port by default). You can find the protobuf definition here
We welcome contributions! Please see CONTRIBUTING.md for:
- How to report issues and request features
- Pull request process
- Code style guidelines
- Issue templates and labels
- Run
make buildto build the registry - Run
make build-in-dockerto build linux binaries in docker
- Run
make testto run the tests.
- Run
make runto start the registry and test it. - Run
make stopto stop the running registry.