Rekor v2

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, please don't request access):

• Proposal
• Design doc

Storage Backends

Rekor v2 supports multiple storage backends. Separate binaries for each backend are provided:

• rekor-server-gcp: GCP-specific binary (includes only Google Cloud dependencies)
• rekor-server-aws: AWS-specific binary (includes only AWS dependencies)
• rekor-server-posix: POSIX-based storage (lightweight, no cloud dependencies)
• rekor-server-gcpcloudsql: Alternative to GCP binary that uses CloudSQL instead of Spanner

Google Cloud Platform (GCP)

• Binary: rekor-server-gcp
• Container rekor-tiles/gcp
• Sequencing entries: Cloud Spanner
• Tile storage: Google Cloud Storage (GCS)
• Use case: Preferred deployment architecture for GCP, highly scalable

Amazon Web Services (AWS)

• Binary: rekor-server-aws
• Container rekor-tiles/aws
• Sequencing: Aurora MySQL or RDS MySQL
• Tile storage: Amazon S3
• Use case: Deployment architecture for AWS

POSIX

• Binary: rekor-server-posix
• Container rekor-tiles/posix
• Sequencing: Atomic POSIX operations
• Tile storage: POSIX-compliant filesystem
• Use case: Lower cost, easy to serve

GCP CloudSQL + Cloud Storage

• Binary: rekor-server-gcpcloudsql
• Container rekor-tiles/gcpcloudsql
• Sequencing: CloudSQL
• Tile storage: Google Cloud Storage (GCS)
• Use case: Alternative to Spanner sequencing, would only recommend if Spanner cannot be used

To authenticate to GCS, you must create HMAC access keys and set the following environment variables:

• GCS_HMAC_ACCESS_KEY_ID
• GCS_HMAC_SECRET
• GCS_REGION, the region of the bucket
• GCS_ENDPOINT_URL, which should equal https://storage.googleapis.com

Public-good instance

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.

Installation

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

Security Reports

If you find any issues, follow Sigstore's security policy to report them.

Local Development

Deployment

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.

Making a request

Follow the client documentation for constructing a request and parsing a response.

Testing

Run unit tests with go test ./....

Follow the end-to-end test documentation for how to run integration tests against a local instance.

Adding a storage backend

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_BACKEND arg 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