RFC: dstack-webhost – A Verifiable TEE Web Hosting Platform

Status: Draft
Repo: https://github.com/amiller/dstack-webhost

Problem

Deploying a web app inside a Phala dstack CVM is technically possible today, but the experience is raw – you write a docker-compose, push it through the phala CLI, and you’re on your own. There’s no framework for:

Vision

dstack-webhost is a hosting platform that lives inside a Phala dstack CVM and makes it easy to deploy, promote, and verify web applications with TEE attestation guarantees. It has three interacting concerns:

  1. Hosting – two layers of deployment granularity
  2. Trust modes – dev and attested, with promotion between them
  3. Verification – end-to-end trust chain from smart contract to running code

1. Hosting: Two Layers

Layer 1: Docker Service Hosting

Full docker-compose subnetworks running inside the CVM. You bring a docker-compose.yaml and the daemon manages it as an attested (or dev) service. Use this for databases, multi-container apps, anything that needs its own network topology.

Layer 2: Lightweight App Hosting

Single-function apps in Deno, Node, Python, or static files. You point at a git repo and an entry file, and the daemon deploys it onto a shared runtime container. No Docker knowledge needed. Think of it like Cloudflare Workers but the workers are TEE-attested.

These compose naturally – a Layer 2 app can talk to a Layer 1 database service on the same CVM’s internal network.

2. Trust Modes: Dev and Attested

Every project exists in one of two modes:

Dev Mode

Attested Mode

Promotion

A deliberate action: POST /_api/projects/<name>/promote

This is intentionally not automatic. Promotion is a trust claim, and it should be a conscious step – like merging to main, but for trust.

3. Verification: The Trust Chain

This is the part that makes this project more than just a deployment tool. The whole point of running in a TEE is that someone else can verify what’s running. The trust chain looks like:

Base smart contract (CVM app ID)
  └── CVM attestation (dstack quote, includes TCB, boot measurements)
        └── tee-daemon code (verified via repo commit hash in quote)
              └── Per-project attestation
                    ├── Source code hash (git tree hash from deploy)
                    ├── Deployment manifest (runtime, entry, env)
                    └── Audit log (all management actions since promotion)

For Developers: Workflow Skills

The repo should provide guidance (and eventually agent skills) for:

  1. Local dev: Write your app in TypeScript, test locally
  2. Staging deploy: POST /_api/projects with your git repo, see it live on the CVM in dev mode
  3. Promote: When you’re happy, promote to attested. The daemon records your source hash and starts the audit trail
  4. Share verification: Your users can follow the verifier flow below

For End Users: Verification Skills

Someone visiting https://your-cvm.dstack.phala.network/your-app/ should be able to answer:

The repo should provide:

Status (2026-04-30)

The original “Next Steps” list is mostly landed:

The verifier page and audit guide together replace what RFC 0001 originally called the “verification page” and “agent skill.” The substrate is small enough that a project audit reduces to reading the project’s own handler against a known runtime contract; the audit guide is the runbook for that.

Correction to the section above on trust modes. This RFC framed “TEE-isolated containers on a separate network” as part of attested mode, conflating attestation and isolation. The current model treats them as orthogonal: every app runs under the daemon’s chosen OCI runtime regardless of mode (so dev apps are also sandboxed against each other), and isolation: "container" is opt-in per-project independent of attestation. Promotion to attested adds a publication surface (source hash in the quote, public verifier endpoints, audit log) — it does not add the sandbox, because the sandbox is universal. Hermes, currently a peer service to tee-daemon in the dstack compose, is an app-shaped workload that bypasses tee-daemon’s isolation policy; pulling it inside as a runtime: "image" app is a future migration (the substrate primitives now support it).

What’s still off:

Non-Goals (for now)