Unreleased documentation. These pages follow the main branch and can change before the next release. For supported guidance, use v0.26.1.
If you are planning a production Evidence Gateway deployment, this is what you provide, what the product does not depend on, and what stays your job once it runs. None of it is needed for the local tutorials, which start disposable versions of everything on your machine.
What you provide
Section titled “What you provide”- A host for one process. Evidence Gateway is a single binary that serves one trust domain. It runs on the platforms in platform support.
- HTTPS in front of it. The process listens on a private address; your reverse proxy or ingress terminates TLS and routes traffic to it.
- A token issuer. Evidence Gateway verifies bearer tokens from one OpenID Connect issuer and issues none. Your identity provider fills this role, or Registry Mint does when you have none.
- A signing key you control. Production signing uses a Vault or OpenBao Transit key that never leaves the vault, reached through a proxy on the same host. A local development profile may use a key file instead.
- Durable storage for the audit trail. Every request appends to a keyed, hash-chained log on disk. The disk it lands on, and its backups, are yours.
- The authoritative source. Each question makes one fixed request to a system your institution already operates, over HTTP or against a read-only SQLite extract. That system has to answer within the timeout you configure.
- A reviewed bundle. Your authors write the questions, sources, and derivations as a project and hand you an immutable bundle. You mount it read-only beside a runtime file that names the listener, paths, and secrets for this host.
What it does not need
Section titled “What it does not need”There is no database. Evidence Gateway stores no records, no requests, and no answers; the only durable state it writes is the audit trail. There is no message broker, worker pool, cache, or service mesh, and nothing requires Kubernetes. One process, one bundle, and one audit path make one deployment. A second issuer, or a second customer who must not trust the first, means a second deployment.
Registry Relay and Base Registry Engine are separate products, not dependencies. Evidence Gateway can use either one as a source through the same fixed HTTP request it makes to any other system.
How it ships
Section titled “How it ships”Each release publishes reproducible binaries for the runtime, the evidencectl authoring tool,
Registry Mint, and the wallet delivery service, with an installer that verifies checksums before
installing. Each release also publishes container images built on a distroless base with no shell,
running as a non-root user, and records the digest of every image it promotes. Pin that digest
rather than a movable tag.
The release ships no Helm chart or hosted offering. A Docker Compose file is a reasonable adapter around the published image, and Deploy with Docker Compose shows the shape: the reviewed bundle mounted unchanged, a separate runtime file and secret root, a persistent audit volume, and TLS in front.
What stays your job
Section titled “What stays your job”Keys. You generate the signing key and the two audit and subject-binding secrets, and you rotate them. When you rotate the signing key, the published key set has to keep every previous public key for as long as an assertion signed with it may still be verified, or a verifier holding an older assertion fails.
Immutable inputs. The runtime file and the bundle must not be writable by the service, and the process refuses to start when they are. There is no hot reload or override layer; a change means a new bundle, a fresh check, and a restart.
The audit trail. One process owns one audit path, so scaling out means several processes with several audit paths, run active-passive rather than active-active. Segments rotate on their own, but retention, backup, restore, and chain verification are operator work, and the runtime never deletes a sealed segment.
Readiness. The health endpoint answers when the process is alive. The readiness endpoint fails closed while any secret, signing provider, audit sink, or source credential is unavailable. Route traffic on readiness. Metrics are off until you open a second, private-address listener for them.
Capacity
Section titled “Capacity”No throughput or latency figure is part of the Version 1 contract. The cost that shapes throughput is durability: a successful request pays two durable audit writes, or three when it searches before it fetches, and the audit sink batches writes that overlap so a busy deployment amortizes the disk barrier. Measurements taken on macOS are kept in the product’s performance note, and it asks you to measure again on the Linux host you will run before you size anything. Because each process owns its own audit path, N processes give close to N times the throughput.
Stability
Section titled “Stability”Registry Stack is pre-1.0, so a minor release may change APIs and deployment contracts, and security fixes land only in the latest release; see the support window. Within that, the Evidence Gateway Version 1 assertion contract, runtime, and operator contract are implemented, not exploratory. Document evidence, credential lifecycles beyond the SD-JWT VC serialization, multi-source answers, and a public catalog are named non-goals, and a future profile would need its own approved concept.