buf.lock v1 configuration

This file now has a v2 configuration available. See the v2 buf.lock reference and the v1 to v2 migration guide for details about the new configuration and migration instructions.

If your buf.yaml declares any deps, it will be accompanied by a buf.lock file that contains your module's dependency manifest. This manifest represents a single, reproducible build of your module.

You can create or update a buf.lock file for your module by running the buf dep update command. For example, given this directory layout and buf.lock content for the module:

├── acme
│   └── pet
│       └── v1
│           └── pet.proto
├── buf.lock
└── buf.yaml
# Generated by buf. DO NOT EDIT.
version: v1
  - remote:
    owner: acme
    repository: paymentapis
    commit: 9a877cf260e1488d869a31fce3bea26d
    digest: b4:4af5b88c9a1d9b36421ad84a2cff211fc74995040188dafc1c8508d36406140e40eb0ab82d21e761961e4a71631d4474e3d0608b987ca3d02d5d19012edff21d

As the file itself notes, buf.lock should never be hand-edited, as it's the result of actually resolving the dependencies.


Each entry in the buf.lock deps key is a module pin, which uniquely represents a specific snapshot of the given module ( in this case), protected with a cryptographic digest of all of the files in it (see how we protect dependencies against tampering). With this, the local snapshot of the module and all of its dependencies are uniquely represented, reproducible, and protected against tampering.

  1. deps