Skip to main content
Beekeeper Docs

Installation

Install Beekeeper and verify the binary with cosign and SLSA provenance.

Beekeeper ships as a single static Go binary with no external runtime dependencies. You can install it with go install, download a signed pre-built binary, or build it from source. Because Beekeeper runs with your full filesystem and network privileges, verify the binary before trusting it: the cosign and SLSA steps below let you confirm it was built by the release pipeline and not tampered with.

go install

Beekeeper is a supply-chain security tool, so its own commands follow the practice it recommends: pin an exact release rather than a mutable @latest tag. A mutable tag pulls whatever the proxy resolves the moment it publishes, with no vetting window. Bump the tag to the current release when you upgrade.

go install github.com/home-beekeeper/beekeeper/cmd/beekeeper@v1.2.0

This builds from source on your machine (Go verifies it against its checksum database) and places the binary on your PATH.

Pre-built binaries (GitHub Releases)

Signed binaries are published on the GitHub Releases page, one per platform:

https://github.com/home-beekeeper/beekeeper/releases/tag/v<version>

Each release includes:

  • A per-platform archive with the beekeeper binary inside.
  • A checksums.txt keylessly signed by cosign, with its bundle (checksums.txt.sigstore.json).
  • SLSA provenance (multiple.intoto.jsonl).
  • A CycloneDX SBOM per archive (beekeeper_<version>_<os>_<arch>.<ext>.cdx.json).

Download your platform's archive, then verify it with the steps below.

Verify a release

Four short steps: download the assets, confirm the cosign signature on checksums.txt, confirm your archive's hash is in that now-trusted list, and (optionally) check the SLSA provenance. cosign signs checksums.txt, which transitively covers every archive and SBOM listed inside it.

Tools you need

  • cosign: installation guide (pin a specific cosign release rather than building @latest)
  • slsa-verifier: download the prebuilt binary from the releases page (e.g. slsa-verifier-windows-amd64.exe); go install does not resolve this module's command path
  • jq: winget install jqlang.jq (Windows), brew install jq (macOS), sudo apt-get install -y jq (Linux)
  • gh (optional, used for the download step): installation guide

Every command below is a single line and pastes-and-runs in PowerShell, cmd, and POSIX shells. (Earlier versions of this page used \ line continuations, which only work in bash and break in PowerShell with Missing expression after unary operator '--'.) Where a step genuinely differs by OS it is shown per shell. The examples use v1.2.0 and the Windows archive beekeeper_1.2.0_windows_amd64.zip; replace the version and the _<os>_<arch> part with the release and platform you downloaded (_darwin_arm64.tar.gz, _linux_amd64.tar.gz, and so on).

1. Download the assets (checksums, cosign bundle, SLSA provenance, your archive + its SBOM)any shell
gh release download v1.2.0 -R home-beekeeper/beekeeper --pattern "checksums.txt" --pattern "checksums.txt.sigstore.json" --pattern "multiple.intoto.jsonl" --pattern "beekeeper_1.2.0_windows_amd64.zip*"

No gh? Download the same files from the release page in a browser into one folder, then run the remaining steps there.

2. Verify the cosign signature on checksums.txtany shell
cosign verify-blob checksums.txt --bundle checksums.txt.sigstore.json --certificate-identity "https://github.com/home-beekeeper/beekeeper/.github/workflows/release.yml@refs/tags/v1.2.0" --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

Verified OK means checksums.txt was signed by a GitHub OIDC token bound to the release workflow, not by a manually held key. Now confirm your archive appears in that trusted list:

3. Confirm your archive's hash is in checksums.txtPowerShell
if (Select-String checksums.txt -Pattern (Get-FileHash -Algorithm SHA256 beekeeper_1.2.0_windows_amd64.zip).Hash -Quiet) { "checksum OK" } else { "MISMATCH" }
3. Confirm your archive's hash is in checksums.txtLinux
sha256sum --ignore-missing -c checksums.txt
3. Confirm your archive's hash is in checksums.txtmacOS
shasum -a 256 --ignore-missing -c checksums.txt
4. Verify SLSA L3 provenance (swap the archive name for your platform)any shell
slsa-verifier verify-artifact beekeeper_1.2.0_windows_amd64.zip --provenance-path multiple.intoto.jsonl --source-uri github.com/home-beekeeper/beekeeper --source-tag v1.2.0

SLSA Level 3 confirms the build environment was ephemeral, the build was triggered by a source commit, and the provenance was produced by the SLSA generator, not by the project's own workflow. The provenance subjects are the archives listed in checksums.txt, so verify-artifact targets your downloaded archive, not the unpacked binary.

Inspect the SBOM

A CycloneDX Software Bill of Materials (beekeeper_<version>_<os>_<arch>.<ext>.cdx.json, one per archive) lists every direct and transitive Go dependency with its version:

List every dependency in the SBOMany shell
jq -r '.components[] | "\(.name)@\(.version)"' beekeeper_1.2.0_windows_amd64.zip.cdx.json

Reproducible build verification

Beekeeper builds are reproducible (-trimpath -buildvcs=false -mod=readonly). You can rebuild a release from its source tag and confirm the output hash matches the published binary. This needs make and Go 1.25+ (on Windows, run it under WSL or Git Bash):

Rebuild from the tag and compare hashesmake + Go
make verify-release VERSION=1.2.0

A mismatch means the released binary was not produced from the tagged source.

Build from source

git clone https://github.com/home-beekeeper/beekeeper
cd beekeeper
make build

make build uses the reproducible flags above. Requires Go 1.25+.

State directory

Beekeeper stores its configuration, policies, catalogs, audit log, and runtime state in a per-user directory:

OSState directory
Linux / macOS~/.beekeeper/
Windows%APPDATA%\beekeeper\

See Configuration for what lives there and how the layered config is merged.

Distribution. The canonical module path and GitHub Releases are the distribution channels. The verification commands above are exactly the ones the release pipeline produces signatures for.

On this page