Cache
Restored archives are checked against content fingerprints before extraction. The BoringCache Action fails closed on server-signature verification by default. Unused cache remains reclaimable under the workspace's cache policy.
Security
Control who can use your build data.
Give each job access to the workspace and product it needs. Separate consumption from publication and preserve the integrity checks for each kind of build data.
Use short-lived access for supported CI.
- Use workload identity in CI
- Approve a Machine connection once. A supported CI job can present its OIDC assertion through that connection and receive short-lived, product-scoped credentials, so the workflow does not store a reusable BoringCache secret.
- Keep access workspace-scoped
- Members, Machine connections, and scoped credentials can access only their authorized workspaces. Each product operation receives only the access needed for that workspace and product.
- Readers do not need publishing rights
- trust-policy: auto keeps pull requests and other low-trust jobs restore-only while eligible trusted jobs can publish. The job cannot use restore access to replace shared state.
- Use scoped credentials when OIDC is unavailable
- Local, headless, and non-OIDC environments can use explicit restore, stage, or save credentials. BoringCache does not switch from failed workload identity to a stored credential without an explicit setup choice.
- Issue narrow Registry grants
- Docker authentication exchanges a workspace token for a short-lived bearer grant scoped to one repository and its allowed pull, push, or delete operations.
- Authorize direct transfers
- Cache and Artifact transfers go directly between the CLI and storage using signed, object-specific requests. A signed request does not grant access to another workspace object.
Integrity is checked for each product.
Artifacts
Each ready Artifact is an immutable stored representation with an expected SHA-256 checksum and explicit retention. BoringCache records when the object store also confirms that representation checksum. Artifacts are never reclaimed as cache.
Registry
Registry uploads are streamed through exact SHA-256 verification before promotion to immutable OCI digest keys. Repository authorization is checked before a manifest or blob is returned, even when its digest is known.
Choose the publisher trust decision outside BoringCache.
Cache can require a Sigstore attestation from a GitHub publisher selected by your pinned policy before restoring Archive, Archive Graph, or OCI content. Remote compiler and GitHub Actions-compatible entries cannot satisfy that policy yet. Artifact receipts record BoringCache publication, while producer attestations require separate verification. Registry exposes digest-addressed images and OCI referrers; image pulls do not enforce a signer policy.
See the trust checks for each product →Choose where Cache and Artifacts are stored.
Cache and Artifacts can use managed storage or your own S3-compatible bucket or Azure Blob container on Custom. With BYOC, you control storage credentials, encryption, access policy, and lifecycle while BoringCache retains the metadata needed to authorize and locate objects.
Registry storage is currently managed by BoringCache. It does not use the workspace's BYOC destination.
Read the storage setup →Where build data is stored
Managed storage
Every planCache · Artifacts · Registry
Included for Cache, Artifacts, and Registry on every plan. Start without setting up a storage account.
View plans →Your own storage
Custom planCache · Artifacts
S3
Azure Blob
Azure Blob
Connect an S3-compatible bucket or Azure Blob container for Cache and Artifacts on the Custom plan. Your provider bills storage and transfers.
About BYOC →Verify release checksums, signatures, and attestations.
CLI releases publish checksums and a signed checksum bundle. The Action can be pinned to an immutable commit. Managed BuildKit images are signed by digest and published with provenance and SBOM attestations.
Report security issues privately.
Email security@boringcache.com or use private vulnerability reporting in the affected public repository. Include the affected product, version or page, expected impact, and enough reproduction detail for us to investigate.
Do not include live credentials, customer data, or secrets. Test only with accounts, workspaces, and data you control. Do not degrade service, access another customer's data, use social engineering, or run high-volume automated scans. These reporting instructions do not authorize disruptive testing.
Please validate findings before sending them. Scanner output without a reproducible security impact may not receive a response.