A personal Vercel for web apps whose readers can verify what code actually ran.
Lambda, Vercel, and Cloudflare Workers host code cheaply and call it on demand. None of them tell the consumer of the output what code ran. For most apps that’s fine. For receipts, credentials, sealed-time releases, or evidence in disputes, it’s the whole point.
A function running inside a Phala dstack TEE can answer the question. The platform produces a hardware-rooted attestation that binds the running code’s measurements into the output. dstack-webhost wraps that into a normal dev loop: push to a git repo, deploy to your CVM, promote to attested when you’re ready, share the URL. Whoever you share with sees the source on GitHub and the running code as the same thing.
Two modes per project
Dev is for iteration. Push code, test, change it, throw it away. No audit log, no public verifier; trust is whatever you’d get on Vercel.
Attested is the trust claim. The daemon records the source hash, opens an audit log, binds the hash into the TEE quote, and exposes the verifier endpoints to anonymous callers. Promotion is deliberate — like cutting a release.
A single CVM holds as many of each as you like. Most apps stay private. You share the URL of an attested project when someone needs to verify it.
See it live, then verify it yourself
The worked example is the isolation probe: a small app on hermes-staging that exposes its own kernel-namespace view so a relying party can corroborate the substrate’s runtime claim from inside one app.
Start with the live probe, then read the probe walkthrough. The CVM’s root page serves the list of attested apps with verifier links beside each one.
Things you might build
- Multi-app isolation, verifiable. Two apps on the same CVM, sandboxed from each other under
sysbox-runc. A small probe app exposes its own kernel-namespace view so a relying party can corroborate the substrate’s runtime claim from inside one app — covered on the isolation probe page. - Prompt receipts. Call a model provider through a TEE function and emit the response together with a signed record of the exact prompt and response.
- Timelock encryption. Hold an encrypted message and only release the key after a deadline. The TEE seals the key; a quorum of clocks gates the release. A working demo runs on hermes-staging.
Why audits stay small
Every project on a tee-daemon CVM rides the same daemon, the same shared runtime, and the same verifier surface. An auditor learns that substrate once — it’s public source — and reuses the understanding across every project they review on it. A specific project’s audit reduces to “given this known substrate, does this small handler hold the invariant it claims?” The platform’s payoff is keeping each per-project audit small.
Status
Pre-v1. The hosting flow works across Deno, Node, Bun, Python, static, and custom Dockerfiles. Attested promotion, the audit log, and public verifier endpoints landed in late April. Next milestones live in the RFC log.
Reading and discussion
The substance lives in the RFC log. Issues there track the work in flight.
- Platform vision (RFC 0001) — the original framing, with a current-state update
- RFC log — design notes, dated and status-tagged
- Developer guide — deploying a project
- Audit guide — auditing a deployed project, agent-runnable
- Verifier skill — for an agent handed just a URL: walk the chain, produce a verdict
- Isolation probe — a sample app that corroborates the substrate’s OCI-runtime claim from inside one container
- GitHub repo
Open a GitHub issue. Most of the design is still up for revision.