Rekor v2, aka rekor-tiles or Rekor on Tiles, is a redesigned and modernized Rekor, Sigstore's signature transparency log, transitioning its backend to a modern, tile-backed transparency log implementation to simplify maintenance and lower operational costs.
More information (documents are shared with sigstore-dev, join the group to get access):
The Sigstore community hosts a productionized instance of Rekor v2 with a 99.5% availability SLO. See the status page for uptime metrics.
Use the public-good instance's TUF repository to determine the URL of the active instance. Note that the community instance's URL will change approximately every 6 months when we "shard" the log, creating a new log instance to keep the size of the log maintainable. Sigstore clients will pull the latest log shard URL from the TUF-distributed SigningConfig, and will fetch both active and inactive shard public keys from the TrustedRoot.
As of October 2025, we have not yet distributed the current Rekor v2 URL in the SigningConfig, to give users adequate time to update their clients to support verifying entries from Rekor v2. We are planning to distribute the latest Rekor v2 URL by end of 2025/early 2026.
If you want to start using Rekor v2, construct a signing config, using the
TUF-distributed signing config
as a base, and adding the following instance as the first entry in the rekorTlogUrls list:
{
"url": "https://log2025-1.rekor.sigstore.dev",
"majorApiVersion": 2,
"validFor": {
"start": "2025-10-06T00:00:00Z"
},
"operator": "sigstore.dev"
},
Note: We will eventually turn down the 2025 Rekor v2 instance when we deploy a 2026 instance. We strongly advise against hardcoding this URL into any pipelines that cannot be easily updated.
We provide prebuilt binaries and containers for private deployments.
- Download the latest binary from Releases
- Pull the latest container from GHCR
- Install Rekor v2 via Helm
If you find any issues, follow Sigstore's security policy to report them.
Run docker compose up --build --wait to start the service along with emulated Google Cloud Storage and Spanner instances.
Run docker compose down to turn down the service, or docker compose down --volumes to turn down the service and delete
persisted tiles.
Follow the client documentation for constructing a request and parsing a response.
Run unit tests with go test ./....
Follow the end-to-end test documentation for how to run integration tests against a local instance.
Tessera supports multiple storage backends for different cloud providers and infrastructure. We will add support in Rekor for different storage backends with user demand.
Rekor will produce different binaries and containers for each storage backend. Binaries will be named
rekor-server-<backend> and containers github.com/sigstore/rekor-tiles/pkgs/container/rekor-tiles/<backend>.
To add support for a new backend, with the example below for the gcp backend from PR #630:
- Create a backend-specific driver
- If needed, create a backend-specific signer/verifier. At a minimum, you should support the file-based signer/verifier. To support a KMS-backed key, import the cloud provider-specific driver (example).
- Create a backend-specific main package
- Create a Docker compose file, and set the
STORAGE_BACKENDarg for building the containerized binary - Add an end-to-end test configuration
- Add the binary to goreleaser
- Add the storage backend to the matrix for container building
- Update the build test matrix
- Update the end-to-end test matrix
- Add a Makefile target and update
make all - Once merged, update the list of required tests