Rekor: the transparency log behind Sigstore signing

A ledger for metadata, not for artifacts

Rekor's stated goal is to provide an immutable, tamper-resistant ledger of metadata generated within a software project's supply chain. The word metadata is the whole design in one term. Maintainers and build systems record signed metadata to an immutable record, and other parties can then query that metadata to make informed decisions about trust and the non-repudiation of an object's lifecycle. The project provides a REST API based server for validation and a transparency log for storage, and a CLI application to make and verify entries, to query the log for an inclusion proof, to perform integrity verification of the log itself, or to retrieve entries by public key or by artifact. The name is Greek for Record, and the model borrows from Certificate Transparency, which is why a client can ask for an inclusion proof and check that a signature really is in the log rather than being shown a bare assertion. Rekor fulfils the signature transparency role of Sigstore's software signing infrastructure, but it can also be run on its own and is designed to be extensible to different manifest schemas and PKI tooling.

v1 is in maintenance mode, and v2 replaces the log's shape

The section titled the current state of Rekor v1 contains the most decision-relevant paragraph in the README. Rekor v1 is in maintenance mode, and the project is actively developing a new version designed to be easy to maintain and cheaper to operate. The new version is backed by a tile-based log and will use a modernized version of Trillian, Trillian-Tessera, building on active development in the Certificate Transparency ecosystem. The work is tracked in a separate repository, rekor-tiles, with a proposal and a design document, and the project states that as they near a v2 release they plan to merge the rekor-tiles codebase into this repository. For an adopter this is a migration to plan for rather than a detail to ignore. The v1 log stores entries as leaves in a Trillian tree with a signed tree head, which is the classic Certificate Transparency layout and the reason it is comparatively expensive to run. Tiles are the newer approach, storing a log as a sequence of fixed-size tiles that can be served and verified in pieces, which is where the cheaper operation comes from. If you are starting a new integration now, reading the v2 design before you write code against the v1 API is the sensible order.

The public instance, its SLO and the 100KB ceiling

The public instance is the reason most people will touch Rekor at all, and its terms are stated precisely. Rekor is officially Generally Available with a 1.0.0 release and follows semver rules for API stability, which means production workloads can rely on the public instance, which has a 24/7 oncall rotation supporting it and offers a 99.5% availability SLO for a specific set of endpoints: /api/v1/log, /api/v1/log/publicKey, /api/v1/log/proof, /api/v1/log/entries and /api/v1/log/entries/retrieve. Uptime data is published at status.sigstore.dev and further detail is in the public instance documentation. The limit that matters for design is the size one. The attestation size limit for uploads to the public instance is 100KB, and if you need to upload larger files the instruction is to run your own instance of Rekor, with installation instructions in the documentation. A 100KB attestation is generous for a signed statement about a build, and it is the right order of magnitude for the Sigstore model, but it is a hard limit, and a team that wants to push larger artifacts through a log has to self-host. That is the fork in the road the public instance documentation keeps pointing at.

Types are the extension point, and they are where the semantics live

Rekor is extensible through what it calls types, which are the manifest schemas describing what a particular kind of entry contains. The README points to the type customization documentation in the pkg/types directory of the repository, and says that Rekor allows customized manifests. The companion documentation in the repository is types.md, which covers how to sign and upload data in different pluggable types, and there is a separate oid-info.md listing the Rekor OID values. The reason this matters more than a normal plugin system is that the log is a schema-agnostic container. A verifier given an entry needs to know which manifest schema it is looking at in order to interpret it, and the OID values are how a type is identified. If you are deciding whether Rekor fits your pipeline, the question to answer is not whether the server is good but whether a type exists that matches the metadata you want to record, and if not whether you can add one.

Running your own: Trillian, MySQL and Valkey in compose

The compose file in the repository shows the shape of a self-hosted deployment, and it is more than a single container. There is a MySQL service built from the Trillian open source CI database image at version 1.4.0, with a healthcheck that pings the server, and a Redis service running the valkey image at 9.1.1 with appendonly enabled and a password, healthchecked with valkey-cli. Then a trillian-log-server service built from a dedicated Dockerfile.trillian-log-server, started with the quota system set to noop and the storage system set to mysql. Separate Dockerfiles exist for the log server and the log signer, and the compose file has variants for testing, for debugging and for a backfill test, alongside an e2e-test.sh script. The image build itself is a multi-stage Go build on golang:1.27.1 pinned by digest, producing the rekor-server binary and running it with the command rekor-server serve, with a separate debug stage that installs delve. The operational footprint is a log server, a signer, a database and a cache, which is the honest cost of running the classic transparency log yourself, and the thing v2 is designed to reduce.

Reproducible builds, fuzzing and generated API code

The build tooling shows a project that treats its release artefacts as security-relevant. The Makefile derives the version from git describe with the dirty flag, takes the commit hash from git rev-parse, and uses SOURCE_DATE_EPOCH from the last commit timestamp to compute a build date, with a fallback to the current date when the variable is not set, which is the standard recipe for a reproducible build date. The default target builds both the CLI and the server, and the file includes Makefile.swagger, with a swagger template directory under hack/swagger-templates and a dependency list that ties the generated OpenAPI code to openapi.yaml, the JSON schemas under pkg/types and the templates themselves, so the API surface cannot drift from the manifest schemas. The Makefile also carries a FUZZ_DURATION variable defaulting to ten seconds, and the module depends on go-fuzz-headers, which points to fuzzing being part of the test story for a service that parses untrusted signed material. The linting is golangci-lint, the release is goreleaser, and there is a separate .ko.yaml for building container images without a Dockerfile, alongside the runtime image default of gcr.io/distroless/static.

Where Rekor is the wrong tool

Four limits are clear. The first is the version churn, which is the headline: v1 is in maintenance mode, v2 is a different log design with a different backend, and the two are not interchangeable. Code written against the v1 API will need work, and the merge of rekor-tiles into this repository means the shape of the project itself is changing. The second is that Rekor is a transparency log, not a general transparency service. It stores signed metadata about artefacts and it can prove inclusion, but it does not store your artefacts, it does not build them and it does not sign them, and it is not a replacement for a provenance system that produces the attestation in the first place. The third is the cost and the operational surface of self-hosting, which is a log server, a signer, a database and a cache, and which is exactly the burden v2 promises to reduce. The fourth is the scope of trust. The public instance gives you a 99.5% availability SLO on a specific endpoint list, and it is a shared public service, so an operator with a compliance requirement about who holds your signing metadata will want their own instance and their own key management. The README is refreshingly clear about all of this, and the documentation links, including the installation page and the swagger editor, are where the operational detail lives.

Editorial conclusion

Adopt Rekor if you need an auditable, publicly verifiable record of signed build metadata and you want the Sigstore ecosystem's tooling rather than your own transparency log. Do not build on v1 expecting a long life, because the README states it is in maintenance mode with v2 planned to replace it, and do not treat the public instance as a bulk store, because uploads are limited to 100KB. Before you integrate, decide whether you will run your own instance, check the rekor-tiles repository for the v2 design, and read the per-type documentation because the manifest types determine what you can actually record.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sigstore/rekor on GitHub