Run Palliora Node on a TEE

This document walks Palliora node operators through running their infrastructure inside a hardware‑backed Trusted Execution Environment (TEE) using Dstack.

The goal is to move from “ordinary Docker deployment” to a setup where every Palliora node runs inside an Intel TDX Confidential VM, with hardware‑enforced isolation and remotely verifiable attestations. Instead of trusting a generic cloud VM or Kubernetes cluster, operators will be able to show cryptographic proof that their node—and its configuration—ran in a specific, measured environment.

Dstack acts as the bridge between Palliora’s existing Docker‑based node stack and low‑level TEE features. It lets us:

• Take the standard Palliora docker-compose.yml.

• Run it inside a dedicated, attested CVM per deployment.

• Expose the same networking interfaces node operators expect.

• Generate TDX quotes directly from inside the node container for downstream verification.

This guide focuses on three practical outcomes:

1. Provisioning a TEE‑ready host Renting an Intel TDX‑capable machine from a cloud provider and preparing it to run confidential workloads.

2. Running Palliora under Dstack Installing Dstack’s components on the host, adapting Palliora’s docker-compose.yml for this environment, and deploying via Dstack’s UI.

3. Proving and observing execution Pulling TDX attestation reports and node logs from inside the TEE, so operators and verifiers can build higher‑level trust tools (e.g., a Palliora trust dashboard) on top.

By the end of this document, Palliora community members should be able to reproducibly launch their own TEE‑protected nodes, without relying on a specific managed cloud, while keeping the operational model as close as possible to “just run Docker Compose.”

---

1. What Dstack Is

Dstack is an SDK and orchestration layer that runs your existing Docker apps inside Confidential VMs (CVMs) backed by hardware TEEs (Intel TDX, etc.).

Core Components

• dstack‑vmm Runs on the bare‑metal TDX host. Manages CVMs: creates, boots and stops them. Provides CVM orchestration and monitoring service right out of the box.

• dstack‑gateway Reverse proxy on the host. Terminates TLS and routes https://<id>-<port>.<base_domain> to services inside CVMs.

• dstack‑kms Key Management Service. Generates and seals keys; only unseals them inside attested CVMs, secluded from the host (prevents host/operator access). Serves key derivation requests from dstack-guest-agent inside running CVMs via RPC.

• dstack‑guest‑agent Runs inside each CVM. Handles key derivation, remote attestation, and exposes /var/run/dstack.sock so containers can request TDX quotes.

• meta‑dstack (Yocto layer) Builds the minimal, hardened Linux image that runs inside CVMs and hosts Docker + guest‑agent. This uses the Yokto Linux guest image and provides dedicated memory/resources (secluded from the host) for confidentiality guarantees.

Key Features

• Drop‑in for Docker: Use your existing docker-compose.yml, no app code changes.

• Per‑app CVM isolation: Each compose app runs in its own TDX CVM with encrypted memory.

• Remote attestation: Containers can request TDX quotes via dstack.sock and prove they ran in the expected environment.

• Network ingress out of the box: Gateway gives you HTTPS endpoints for node RPCs, APIs, etc., without manual nginx.

See “Dstack – Getting Started” for architecture and concepts.​

---

2. Renting an Intel TDX Machine

To self‑host Dstack, you need a VM that supports Intel TDX Confidential VMs (C3‑class or similar) on your cloud provider.

Typical Requirements

• Machine family: Intel Sapphire Rapids with TDX enabled (for example, C3 c3-standard-* on some providers).

• vCPU/RAM: At least 8 vCPU, 32–64 GB RAM for comfortable Dstack builds and CVMs.

• Disk: 200+ GB SSD (Balanced PD/NVMe).

• OS: Recent Linux with TDX‑capable kernel (e.g., Ubuntu 24.04 LTS with TDX_CAPABLE flag).

• Security: Enable Confidential VM service > Intel TDX under security menu.

Checklist When Creating the Host VM

• Enable Confidential VM / Intel TDX in the provider’s UI.

• Use a TDX‑capable OS image (check provider docs for “TDX_CAPABLE” images).

• Ensure firewall/security groups allow:

  • SSH: 22 (admin access)

  • Dstack‑vmm UI: 9080

  • Dstack‑gateway HTTP/HTTPS: 80, 443, and optionally 9070 for the gateway dashboard.[docs.phala]​

Example firewall rule (conceptually):

bash# conceptual: open needed ports to your IP or trusted ranges
allow tcp:22,tcp:80,tcp:443,tcp:9070,tcp:9080 to host_ip

---

3. Installing and running Dstack (vmm, gateway, kms)

On your Intel TDX host VM, follow the upstream Dstack- Get started guide.

3.1 Summary of Dstack setup

bash# Install build deps (example for Ubuntu)
sudo apt update
sudo apt install -y build-essential chrpath diffstat lz4 wireguard-tools xorriso

# Install Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Clone meta-dstack
git clone https://github.com/Dstack-TEE/meta-dstack.git --recursive
cd meta-dstack
mkdir build && cd build

# Generate config template
../build.sh hostcfg
# Edit build-config.sh to match your environment (domain, ports, etc.)
vim ./build-config.sh

# Re-run host build
../build.sh hostcfg
# You should now see artifacts:
ls
# certs images dstack-kms kms.toml run dstack-vmm vmm.toml dstack-gateway gateway.toml

You can either download a prebuilt CVM guest image:

../build.sh dl 0.5.2

or build it from source:

../build.sh guest

3.2 Run Core Services

Run three terminals on the host:

./dstack-kms -c kms.toml

sudo ./dstack-gateway -c gateway.toml

./dstack-vmm -c vmm.toml

• dstack-vmm UI: http://<host-ip>:9080

• dstack-gateway dashboard: https://<host-domain-or-ip>:9070 (if configured)

---

4. Preparing Palliora’s docker-compose for Dstack

Palliora’s existing compose uses host‑mounted genesis config and private ECR images. For TDX+Dstack we’ll make it TEE‑friendly and easy for operators.

4.a Genesis Config from Remote

Instead of mounting a local path like:

volumes:
    - "./palliora-manas.json:/root/palliora-manas.json"

Publish the Palliora genesis config in a public Google Drive/GitHub repo/Gist, then adjust compose to fetch it on container start.

Example pattern:

services:
  # New service to fetch the config file
  fetch-config:
    image: alpine:3.19
    volumes:
      - palliora-config-data:/root
    working_dir: /root
    command: wget -O /root/palliora-manas.json "https://drive.google.com/uc?export=download&id=1VX0Ei12kvGU2nnjXlzjMfAd53tVAaF42"
    restart: "no"
    
  palliora-node:
    image: public-registry/palliora-node:latest
    entrypoint: ["/bin/sh", "-c"]
    volumes:
      - palliora-config-data:/root/
volumes:
  palliora-config-data:

I've hosted one on Google Drive at https://drive.google.com/uc?export=download&id=1VX0Ei12kvGU2nnjXlzjMfAd53tVAaF42

4.b Switch to Public Images

To avoid ECR auth complexity for community operators we've pushed Palliora images to a public registry on public AWS ECR and reference them directly in compose:

services:
  palliora-node:
    image: public.ecr.aws/palliora/palliora/node:latest

This removes the need for AWS credentials or ECR login inside TEEs.

4.c Mount /var/run/dstack.sock for Attestation

To allow the node container to request TDX quotes, mount the Dstack socket as documented.

Example Palliora service snippet:

palliora-node:
    image: public.ecr.aws/palliora/palliora/node:latest
    working_dir: /
    volumes:
      - /var/run/dstack.sock:/var/run/dstack.sock
      - palliora-config-data:/root/

The /var/run/dstack.sock path is provided by the dstack guest‑agent inside the CVM; the mount just passes it into your container.

Here's the compiled changes to Palliora's docker-compose.yml

3KB

docker-compose.yml

Open

---

5. Deploying Palliora via Dstack UI

For the community doc, describe deployment entirely via the generic Dstack‑vmm UI.

5.1 Open Dstack-vmm

Navigate to:

http://<your-tdx-host-ip>:9080

You’ll see the dstack‑vmm web interface.

5.2 Upload and Deploy docker-compose

• Click “Deploy App” (or equivalent button).

• Paste or upload the Palliora docker-compose.yml prepared in section 4.

• (Optional) Configure Encrypted Environment Variables if Palliora needs secrets, incase of using private ECR images — they are encrypted client‑side and only decrypted inside the CVM.

• Click Deploy.

Dstack will:

1. Create a new TDX CVM.

2. Boot the Yocto guest image with guest‑agent.

3. Pull the public Palliora node image.

4. Start the Palliora containers inside the CVM.

5.3 Checking Status

In the vmm UI:

• Logs: For CVM boot logs and container startup; use the [Logs] button.

• Dashboard: See container status, resource usage, and guest‑agent health.

On shutdown, TEE setup will wipe away the ollama and model installations to enable a clean slate boot expected from the TEE. In order to persist it, we need to move the ollama dir into the persistent storage of the TEE.

5.4 Palliora Setup

Once you have the Palliora client running, next up is setting up: 1. Ollama

1. Installing models

2. Creating a Palliora account

3. Staking

4. Finally joining as a guardian

For the above steps, you can follow our Becoming a Guardian guide.

---

6. Getting TDX Attestations and Logs from the TEE

Once the Palliora node is running inside the TDX CVM, operators can generate attestation reports and fetch logs programmatically or use the Trust-Centre to verify attestations automatically.

6.1 Trust Centre

A comprehensive open-source platform for managing and verifying Trusted Execution Environment (TEE) attestations in the dstack ecosystem. The Trust Center provides end-to-end verification of hardware attestation, OS integrity, source code authenticity, and domain ownership for TEE-protected applications.

Repo: https://github.com/Phala-Network/trust-center

The following is verified automatically by the Trust Centre client:

• Verify Hardware Authenticity: Cryptographically prove your app runs on genuine Intel TDX and Nvidia CC hardware

• Confirm Code Integrity: Verify the exact Docker compose configuration deployed matches your source code

• Validate OS Security: Ensure the operating system hasn’t been tampered with

• Prove Zero Trust: For gateway deployments, verify domain certificates are managed entirely within the TEE

For automated verification of your application’s attestation, see the Trust Centre Technical Documentation which explains how to use these quotes with the Trust Centre verification platform.

6.2 Requesting a TDX Quote from the Container

With /var/run/dstack.sock mounted, use the documented curl command from inside the Palliora container:

# inside the palliora-node container
curl -X POST --unix-socket /var/run/dstack.sock \
  -H 'Content-Type: application/json' \
  -d '{
        "reportData": "0x1234deadbeef00000000000000000000000000000000000000000000000000"
      }' \
  http://dstack/GetQuote | jq .

Or, with the newer interface

curl --unix-socket /var/run/dstack.sock \
  "http://localhost/GetQuote?report_data=0x1234deadbeef" | jq .

Code integrity verification

• reportData is a 64‑byte app‑defined field (hex string) that is hashed into the TDX report; Palliora can use it to bind the quote to a particular genesis hash or config version.

• The response JSON contains:

  • The TDX quote (base64)

  • The embedded report_data

  • Measurement fields and signatures

---

Recap

• You rented a TDX‑capable machine.

• Installed and ran Dstack (vmm, gateway, kms).

• Adapted Palliora’s docker-compose.yml for Dstack (remote genesis, public images, dstack.sock mount).

• Deployed via the Dstack UI.

• Verified attestation through Trust Centre/Retrieved TDX quotes from inside the TEE.