Registry stack documentation: machine-readable Markdown.
Index of all pages: https://docs.registrystack.org/dev/llms.txt
Full corpus: https://docs.registrystack.org/dev/llms-full.txt

# What you need to run Evidence Gateway

> The infrastructure, keys, and people a production Evidence Gateway deployment needs, what it does not depend on, and what stays your job once it runs.

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

- **A host for one process.** Evidence Gateway is a single binary that serves one trust domain.
  It runs on the platforms in [platform support](../../explanation/known-limitations/#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](../../configure/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.

{/* Evidence: products/evidence/OPERATOR-CONTRACT.md, "Supported deployment" and "Governed bundle
    and operator runtime"; products/evidence/CONCEPT.md; crates/registry-evidence/src/audit.rs. */}

## 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.

{/* Evidence: products/evidence/OPERATOR-CONTRACT.md, "Supported deployment"; products/evidence/CONCEPT.md;
    AGENTS.md. */}

## 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](../../tutorials/integrate-evidence-candidate-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.

{/* Evidence: crates/registry-evidencectl/install.sh; release/docker/Dockerfile.evidence;
    release/docker/Dockerfile.mint; release/VERIFY.md; products/evidence/README.md. */}

## 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.

{/* Evidence: products/evidence/OPERATOR-CONTRACT.md, "Secrets and keys", "Audit chain rotation and
    rollback", "Listener placement", and "Startup and readiness"; crates/registry-evidence/src/audit.rs. */}

## 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.

{/* Evidence: products/evidence/PERFORMANCE.md; products/evidence/OPERATOR-CONTRACT.md, "Measured throughput"
    and "Capacity planning"; crates/registry-evidence/src/audit.rs. */}

## 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](../../security/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.

{/* Evidence: AGENTS.md; products/evidence/README.md; products/evidence/CONCEPT.md;
    products/evidence/OPERATOR-CONTRACT.md, "Verification and release limit". */}

## Next

- [Test with fixtures](../../tutorials/prove-an-evidence-project/)
- [Configure a deployment](../../configure/evidence/)
- [Build a production candidate](../../tutorials/build-and-deploy-evidence-project/)
- [Configure Transit signing](../../tutorials/move-evidence-to-production-signing/)
- [Evidence Gateway security model](../../security/evidence/)