> ## Documentation Index > Fetch the complete documentation index at: https://phalanetwork.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Terms / Glossary > An authoritative reference for every core concept, component, and cryptographic primitive that powers the dstack confidential-computing platform. > This glossary defines key dstack terms—what they mean, why they matter, and how they're used—organised A-Z with **bold terms**, *italic highlights*, and helpful links. *** ## A – C ### **ACME (Automatic Certificate Management Environment)** Open IETF protocol ([RFC 8555](https://www.rfc-editor.org/rfc/rfc8555)) that lets software request, renew, and revoke TLS certificates without human intervention.\ *In dstack*: **dstack-gateway** calls *Certbot* in the DNS-01 flow so you can obtain a valid certificate even when ports 80/443 are fire-walled, guaranteeing "zero-touch" HTTPS for every app. ### **ACME DNS-01 Challenge** Flow in which domain control is proven by publishing a TXT record under `_acme-challenge.`.\ *In dstack*: used at first boot; the gateway automation injects the TXT record via your DNS provider's API, then cleans it up after issuance. ### **App-id** Unique identifier for deployed applications in dstack, typically derived from the application's cryptographic hash.\ *In dstack*: used for routing (`.domain.com`), key derivation, and authorization checks with smart contracts. ### **AppAuth** Ethereum smart-contract that stores the *allowed container-image hash* for a given application and signals the gateway that a CVM may expose traffic once its **Attestation Quote** matches that hash.\ *In dstack*: every new deployment registers its image digest with AppAuth; the gateway consults this contract before adding a route.\ Further reading: [Smart-contract basics](https://ethereum.org/en/developers/docs/smart-contracts/) • [dstack component map (GitHub)](https://github.com/Dstack-TEE/dstack#architecture). ### **Attestation Quote** Signed report produced by a TEE (e.g. Intel TDX) that hashes each boot component (`RTMR0-3`) and binds them to a verifier-supplied nonce.\ *In dstack*: **dstack-guest-agent** forwards the quote to **dstack-kms**; keys flow only when the measurements match the on-chain allow-list. ### **Blockchain & Smart Contracts** Deterministic programs (e.g. **KmsAuth**, **AppAuth**) stored on a public chain. They record trusted hashes and decide whether a node, image, or user may receive keys.\ *In dstack*: provide decentralised governance and an immutable audit trail—removing single points of failure typical in classical PKI. ### **CAA Records (Certification Authority Authorization)** DNS records that specify which certificate authorities are allowed to issue certificates for a domain.\ *In dstack*: automatically managed by the gateway to restrict certificate issuance and prevent unauthorized certificates. ### **Certificate Transparency (CT)** Public log system ([RFC 6962](https://www.rfc-editor.org/rfc/rfc6962)) for every certificate issued by participating CAs.\ *In dstack*: the gateway subscribes to CT feeds and automatically revokes or alerts on rogue certs for your domains. ### **Certbot** EFF-maintained ACME client that automates Let's Encrypt operations.\ *In dstack*: shipped inside the gateway image; runs on a timer to renew certs \~30 days before expiry without downtime. ### **CID (Container ID)** Unique identifier for QEMU virtual machines in dstack, managed by the VMM's allocation pool.\ *In dstack*: prevents conflicts between VMs; configured via `cid_start` and `cid_pool_size` in VMM settings. ### **Compose-hash** Cryptographic hash of the `docker-compose.yml` file content used for application verification.\ *In dstack*: measured into RTMR registers and validated against blockchain records for secure deployments. ### **Confidential Virtual Machine (CVM)** VM backed by a hardware TEE (Intel TDX today) providing automatic memory encryption and verifiable launch measurements.\ *In dstack*: every user workload lives in a CVM so that the cloud operator, host OS, and hypervisor cannot read or tamper with data in use. ### **Container Runtime** Minimal OCI runtime (*runc* / *crun*) inside the CVM image.\ *In dstack*: obtains secrets through the guest-agent's Unix socket rather than env-vars, reducing the attack surface for in-container code. *** ## D – F ### **DCAP (Data-Center Attestation Primitives)** Intel open-source libraries for local verification of SGX / TDX quotes.\ *In dstack*: bundled with KMS to avoid external Intel Attestation Service dependencies.\ [GitHub](https://github.com/intel/SGXDataCenterAttestationPrimitives) ### **Device-id** Hardware-specific identifier used in attestation and authorization processes.\ *In dstack*: helps ensure deployments run only on authorized hardware and prevents unauthorized migration. ### **DNS TXT Record Lookup** Method for service discovery using DNS text records with the `_dstack-app-address` prefix.\ *In dstack*: enables custom domain routing by publishing application endpoints in DNS records. ### **Docker Compose** YAML file describing a multi-container app.\ *In dstack*: your unchanged Compose file is parsed by the VMM; each service is mapped to a secure network endpoint. ### **dstack CLI** Command-line interface for deploying and managing applications in dstack.\ *In dstack*: primary user interface for `deploy`, `list`, `stop` operations and application lifecycle management. ### **dstack-gateway** Security-aware reverse proxy: performs WireGuard ingress, RA-TLS validation, automatic certificate management, and CT monitoring.\ *Role*: single public entry-point for all CVMs. ### **dstack-guest-agent** Small Rust daemon inside every CVM. Exposes RPC for `get_quote`, `get_key`, and `start_container`.\ *Role*: sole entity allowed to unseal keys, ensuring secrets never leave the encrypted memory domain. ### **dstack-kms (Key Management Service)** CVM-resident service that uses **DCAP** to verify quotes, then deterministically derives per-app keys (disk, TLS, JWT) from a master seed.\ *Role*: dstack's root of cryptographic trust. ### **dstack-os** Minimal, security-hardened Linux image (\~40 MiB) built by **meta-dstack**, stripping out shells, compilers, and package managers to shrink the attack surface.\ *Benefit*: identical runtime across TEE hardware and faster boot times.\ Further reading: [Phala blog](https://phala.network/posts/Dstack-A-Zero-Trust-Framework-for-Confidential-Containers) • [meta-dstack layer](https://github.com/Dstack-TEE/dstack/tree/main/meta-dstack). ### **dstack-util** Comprehensive command-line utility providing TDX attestation, system initialization, cryptographic services, and container management.\ *In dstack*: handles full disk encryption setup, RTMR extensions, certificate generation, and system bootstrapping within CVMs. ### **dstack-vmm (Virtual Machine Manager)** Rust supervisor on the host that spawns, monitors, and tears down CVMs via QEMU + TDX, and presents a REST/GUI that accepts your `docker-compose.yaml`.\ *Role*: bridges DevOps tooling to hardware TEE features. ### **FDE (Full-Disk Encryption)** Block-level encryption via Linux *dm-crypt/LUKS*.\ *In dstack*: `dstack-util setup` seals the volume key so disks remain unreadable until the CVM passes attestation. *** ## G – M ### **Gateway Agent** Service component within the gateway that handles communication with CVMs and manages WireGuard connections.\ *In dstack*: configured on port 8090 by default and manages the VPN tunnel establishment. ### **Guest Agent Socket (`/var/run/dstack.sock`)** Unix socket through which containers request keys or quotes.\ *Guarantee*: secrets bypass the filesystem and environment variables, minimising leakage. ### **Guest API** VMM endpoint (`/guest`) that provides proxied access to CVM guest agents.\ *In dstack*: enables secure communication between host components and applications running inside CVMs. ### **Hardware Random Number Generator (RNG)** On-die entropy source conforming to NIST SP 800-90.\ *In dstack*: feeds all cryptographic operations inside the TEE; host RNGs are used only as a secondary pool. ### **Host API** VMM endpoint (`/api`) for CVM notifications and host information exchange.\ *In dstack*: handles communication between the host system and running CVMs for management operations. ### **Instance-id** Unique identifier for specific CVM instances within an application deployment.\ *In dstack*: used for tracking individual VM instances and managing their lifecycle and resources. ### **Intel Trust Domain Extensions (TDX)** CPU feature set providing encrypted VM memory, DMA isolation, and a new attestation leaf.\ *In dstack*: exclusive hardware backend for CVMs (AMD SEV-SNP & ARM CCA on the roadmap). See [Intel TDX specification](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html). ### **iohash / RTMR Measurement** SHA-384 hash stored in TDX Runtime Measurement Registers.\ *In dstack*: compared against the allow-list in **KmsAuth** before keys are released. ### **KmsAuth** Smart-contract that keeps an *allow-list of trusted RTMR hashes* and authorises **dstack-kms** to release keys only when a presented quote matches one of those hashes.\ *In dstack*: policy gate for every key-release request.\ Further reading: [Ethereum smart-contract docs](https://ethereum.org/en/developers/docs/smart-contracts/) • [dstack README](https://github.com/Dstack-TEE/dstack#readme). ### **LUKS (Linux Unified Key Setup)** Standard on-disk format for FDE keys; supports multiple keyslots and PBKDF2/Argon2 hardening.\ *In dstack*: initialises NVMe drives attached to CVMs using AES-XTS-Plain64 cipher. ### **meta-dstack** Yocto meta-layer that builds the dstack-os image with only the guest-agent, container runtime, and attestation libs.\ *Benefit*: smaller footprint and reproducible builds. ### **MRTD (Measurement of Runtime TDX Data)** CPU register that records a SHA-384 hash of the *static* TD state (e.g. firmware) at build time—complements dynamic `RTMR0-3`.\ *In dstack*: **dstack-kms** and **KmsAuth** validate MRTD inside each quote.\ See [kernel.org TDX docs](https://www.kernel.org/doc/html/next/x86/tdx.html). *** ## N – R ### **Nonce (Attestation)** Verifier-supplied random value inside the quote to guarantee freshness and stop replay attacks.\ *In dstack*: the VMM generates a 256-bit nonce for every attestation request. ### **OCI (Open Container Initiative)** Industry standard for container formats and runtimes.\ *In dstack*: ensures compatibility with standard Docker containers while adding TEE security layers. ### **Phala Cloud** Managed service that runs dstack on bare-metal TDX clusters, providing click-to-deploy CVMs, automatic upgrades, and usage-based billing—ideal for teams that want confidential computing without operating hardware.\ Further reading: [Phala docs](https://docs.phala.network/overview/phala-network/dstack) • [dstack architecture blog](https://phala.network/posts/Dstack-A-Zero-Trust-Framework-for-Confidential-Containers) ### **QEMU** Open-source machine emulator and virtualizer used by dstack-vmm to create and manage CVMs.\ *In dstack*: provides the foundation for running CVMs with TDX support and hardware isolation. ### **RA-TLS (Remote-Attestation TLS)** Technique ([arXiv 1801.05863](https://arxiv.org/pdf/1801.05863.pdf)) of embedding a quote in an X.509 extension so the TLS handshake authenticates enclave state.\ *In dstack*: the gateway proxies traffic only after validating this extension. ### **ra-rpc** Wrapper around pRPC that tunnels every request through RA-TLS, giving internal API calls the same attestation guarantees as HTTPS.\ *In dstack*: used by control-plane traffic (VMM ↔ KMS ↔ Guest Agent). ### **Remote Attestation** Two-party protocol where a quote is generated and verified (using DCAP certs & CRLs).\ *In dstack*: prerequisite for key release, network exposure, and service registration. ### **Resource Allocation** Policy-driven distribution of CPU, RAM, and network to CVMs—enforced by cgroups and tc filters.\ *Goal*: prevent noisy-neighbour issues while upholding TEE guarantees. ### **RPC API** VMM endpoint (`/prpc`) for VM lifecycle management and operations using Protocol Buffers.\ *In dstack*: primary interface for programmatic control of CVM deployment and management. ### **RTMR (Runtime Measurement Registers)** TDX hardware registers (RTMR0-3) that store cryptographic measurements of system state and boot process.\ *In dstack*: extended with application events and verified against blockchain allow-lists for security. *** ## S – Z ### **Secure Ingress** Layered design: WireGuard tunnel → RA-TLS termination → service routing.\ *Outcome*: traffic is encrypted on the WAN and remains cryptographically bound to the attested CVM on the LAN. ### **SGX Sealing** Intel SGX feature for encrypting data with hardware-derived keys that persist across reboots.\ *In dstack*: used in Local-Key-Provider mode for persistent key storage without external KMS dependency. ### **Supervisor** Process management component that handles CVM lifecycle operations and resource monitoring.\ *In dstack*: integrates with VMM to ensure reliable CVM startup, monitoring, and cleanup operations. ### **TDX Module Specification** Official Intel document detailing TDX semantics—recommended starting point for low-level implementers. ### **tdx-attest** Rust crate that talks to the TDX module to fetch quotes, extend RTMRs, and bundle them into RA-TLS certificates.\ *In dstack*: compiled into the guest-agent so every CVM can self-serve attestation material.\ GitHub: [tdx-attestation-sdk](https://github.com/automata-network/tdx-attestation-sdk) ### **TLS Passthrough** Gateway routing mode where TLS termination is handled by the application rather than the gateway.\ *In dstack*: enabled by appending 's' to domain names (`s.domain.com`) for end-to-end encryption. ### **TLS Termination** Gateway mode where HTTPS connections are decrypted at the gateway and forwarded as HTTP to applications.\ *In dstack*: default mode for `.domain.com` routing with automatic certificate management. ### **Trusted Execution Environment (TEE)** Hardware-enforced enclave yielding confidentiality and integrity even against a malicious OS.\ *In dstack*: foundational primitive—everything else is orchestration.\ See [GlobalPlatform TEE architecture](https://globalplatform.org/specs-library/tee-systems-architecture/). ### **Web UI** VMM endpoint (`/`) providing HTML console for browser-based management of CVMs and applications.\ *In dstack*: accessible at `http://localhost:9080` for deployment monitoring and log viewing. ### **WireGuard** Modern VPN protocol using Curve25519 + ChaCha20-Poly1305.\ *In dstack*: links gateway replicas into an authenticated mesh and protects east-west traffic.\ Whitepaper: [WireGuard paper](https://www.wireguard.com/papers/wireguard.pdf) ### **X25519** Elliptic curve Diffie-Hellman key agreement protocol using Curve25519.\ *In dstack*: used for cryptographic key derivation and secure communication establishment. ### **Zero Trust TLS** Security model where every connection is authenticated and encrypted regardless of network location.\ *In dstack*: implemented through RA-TLS to ensure all communications are cryptographically bound to attested CVM state. ### **Zero-Knowledge Proof (ZKP)** Cryptographic proof that reveals nothing except validity—enabling privacy-preserving audits.\ *Future use*: optional layer for apps that must prove correct execution off-chain. ### **ZFS** Advanced file system providing data integrity, snapshots, and encryption features.\ *In dstack*: used with Blake3 checksums and encryption for secure data storage within CVMs. *** ## 📑 Reference Index | Spec / Paper / Repo | Description | | -------------------------- | --------------------------------------------------- | | RFC 8555 | Automatic Certificate Management Environment | | RFC 6962 | Certificate Transparency | | Intel DCAP repo | github.com/intel/SGXDataCenterAttestationPrimitives | | WireGuard Whitepaper | wireguard.com/papers/wireguard.pdf | | Intel TDX Spec | intel.com → Trust Domain Extensions | | arXiv 1801.05863 | Integrating SGX Remote Attestation with TLS | | LUKS FAQ | cryptsetup wiki | | GlobalPlatform TEE SysArch | globalplatform.org specs | | OCI Runtime Spec | opencontainers.org/about/overview/ | | dstack GitHub | github.com/Dstack-TEE/dstack | | Phala Network | phala.network |