What should you record about a build so someone else can rebuild it?

Record everything the build used that could change its output: the exact source revision, tool and dependency versions, build flags, and the environment variables the build reads. Store it as a separate file published next to the artifact, so it can be ignored, compared or distributed on its own.

What the reproducible builds project recommends

Its documentation says that, for reproducible builds, you either make aspects of the build environment irrelevant to the output, or you ensure they are available so the software can be rebuilt exactly as distributed. All relevant information should be defined as part of the development process or recorded during the build.

It suggests storing what is recorded as a separate build product that can easily be ignored or distributed separately. That helps identify which variations are irrelevant to the software itself. This product is usually called the buildinfo, though format and distribution differ across ecosystems.

The docs give examples. Debian shares plain text buildinfo files, usually clearsigned. Arch Linux's makepkg produces a BUILDINFO file of key and value pairs, included in the package. In the JVM world, the recommendation is to publish the buildinfo that describes the official build alongside each artifact.

One caveat from the JVM page: the project found a buildinfo file more useful as an internal format, and says Reproducible Central and its buildspec format are closer to what is needed to check that reproducibility was achieved. It adds that a buildinfo just records a build, reproducible or not, and that a rebuild attestation specification will probably be defined in the future. So treat any format you pick as a record, not as proof.

A practical field list

The project does not prescribe one format for application teams, so this is a suggested minimum built from the inputs its own pages describe.

The Go team's post gives a longer list of relevant inputs: the operating system, the CPU architecture, the compiler version and options, the name of the directory containing the source, and the user name and group of the account running the build. Record the ones your build is sensitive to, or better, remove them as inputs.

How to produce it

1. Generate the file in the same CI job that builds the artifact, so it describes the real build.
2. Write it as plain text or JSON, with sorted keys, so the file itself is stable.
3. Publish it next to the artifact, with the same retention.
4. Keep it out of the artifact, so adding fields never changes the checksum you are trying to verify.
5. Compare two buildinfo files when two builds disagree. The first difference is often the cause.

Buildinfo, provenance and SBOM

These are related but different. A buildinfo records inputs for rebuilding. Provenance is a signed statement about how and where an artifact was built. An SBOM lists what is in it. See provenance versus build logs and what a reproducible build is.

Try it yourself

Safeguard's SBOM and dependency scanning, generally available, produces the dependency part of this record. Click through the demo and look for how each component and version is listed.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Reproducible Builds: Recording the build environment
• Reproducible Builds: JVM
• Go blog: Perfectly Reproducible, Verified Go Toolchains

Last reviewed: 19 October 2026.