Intel TDX · Phala Cloud

Verify this server

This server runs inside an Intel TDX confidential VM. This page is served from inside that VM and explains how to inspect the public source, image identity, and runtime evidence for yourself.

This deployment

Version: v0.2.0
Source commit: f7b49f6 f7b49f66563a85a5de0fd4c17dcddb6eaca89228
Source code: https://github.com/open-software-network/os-clovy
Image: ghcr.io/open-software-network/clovy-api:f7b49f6
Attestation: Phala Trust Center report

Why this matters

Audio, transcripts, and notes pass through this server. Remote attestation makes the reported runtime identity independently inspectable. A changed image or source commit becomes visible in the evidence below.

The evidence has three links: source (a public git commit), image (a container image our CI builds from that commit, published with a content digest), and attestation (third-party-verifiable runtime evidence that reports the image executing inside an Intel TDX VM).

Check it yourself

Open the Trust Center report. Confirm the attestation verifies, then find the image reference pinned in the attested compose file. It should be:
```
ghcr.io/open-software-network/clovy-api:f7b49f6
```

Resolve that tag to its content digest in the public registry:

docker buildx imagetools inspect ghcr.io/open-software-network/clovy-api:f7b49f6 \
  --format '{{.Manifest.Digest}}'

Compare against the digest our CI recorded in the repository at deploy time, as an immutable deploy/<env>/<sha> git tag:
```
git clone https://github.com/open-software-network/os-clovy && cd os-clovy
git tag -l 'deploy/*/f7b49f6' -n3
```
The tag message states which image digest commit f7b49f6 deployed. It must match the digest from step 2.
Read the source at that commit. The commit linked above is the exact tree the image was built from. The build stamps it into the image itself.

A matching chain supports that the reported running digest is the one our public CI built and recorded for that commit. Bit-for-bit reproducible rebuilds (regenerating the digest yourself instead of trusting our CI) are in progress; see docs/reproducible-builds.md.

What this does not cover

This evidence supports the reported code identity inside the confidential VM, not what upstream providers do. Everything leaving the TEE for model inference (audio for transcription, prompts and context for note generation and the agent) goes through Venice. By default it runs on Venice private models: zero data retention, no training. If you select an anonymized model not run by Venice, the request is still routed and anonymized by Venice, but the underlying model provider may retain data under its own privacy policy. End-to-end private inference is a separate workstream.