Skip to main content
This page lists the values that the production gateway at api.redpill.ai, tee.redpill.ai, and inference.phala.com attests today. Use it to keep the pins in your verifier current. Each value comes from a GitHub release in Dstack-TEE/private-ai-gateway, and the release is the authenticated source. Check a value against its release, not only against this page, and never against a value copied from the endpoint.

​
Current values

Release: gateway-prod-2026-11-03, live on all replicas since 2026-11-03 17:10 PST.

​
Application

​
KMS

mr-kms is the aggregated measurement of the dstack KMS instance that released the gateway’s keys. A replica records it once, when it boots and requests its keys, so it reflects the KMS at that moment, not the gateway code. If the KMS operator changed the KMS since the last boot, any restart records a new value: a gateway rollout, a keyset renewal restart, host maintenance, or crash recovery. That is why mr-kms changed on 2026-11-03 although the gateway does not control the KMS. The KMS root key is the KMS identity that the workload keys derive from, and it stays the same across KMS builds. To check which KMS serves the gateway, pin the KMS root key. Pin mr-kms only if you also track KMS builds, and expect it to change without notice. The 3-day notice below does not cover these KMS values: we publish a new release with the new value as soon as we see the change.

​
OS and virtual machine

RTMR0 depends on the VM configuration as well as the image: 32 vCPUs and 32 GiB of memory.

​
TLS keys

The keyset in each attestation lists these SPKI pins. The keys are derived from the KMS, so every replica serves the same ones. Do not pin instance-id, report_data, RTMR3 itself, or workload_keyset_digest. They differ between replicas or change when the keyset renews.

​
Scheduled changes

None scheduled.

​
Notice before a change

  • At least 3 days before a gateway rollout that changes the compose hash, app ID, OS image, MRTD, RTMR0-2, or TLS keys, we create a prerelease gateway-prod-<date> in Dstack-TEE/private-ai-gateway with the new values and the planned rollout window, and list it under Scheduled changes and in the changelog.
  • Add the new values to your allowlist next to the current ones. acceptedComposeHashes takes a list for this reason. During a rollout, replicas switch one at a time, so both sets are served until the last replica is done.
  • KMS values (mr-kms, KMS root key) are the exception described under KMS: they are published when they change, without advance notice.
  • An urgent security fix can ship with less notice. Its release states why.
  • When every replica runs the new release, we mark the release as rolled out and update Current values. Remove the old values after that.
To get notified, subscribe to the changelog RSS feed at https://docs.redpill.ai/changelog/rss.xml, or watch the repository’s releases on GitHub (Watch, Custom, Releases).

​
Check a release yourself

Each release attaches the exact app_compose.json the workload measures. Recompute the compose hash from that file and compare it with both the release notes and the live attestation:
The digest must equal the published compose hash. docker_compose_file inside that JSON shows the launcher image, the gateway commit, and every sidecar image, each pinned by digest. For the OS values, run the dstack verifier on the quote, event log, and VM configuration, as described in Verify a response.