diff --git a/src/content/Docs/developers/deployment/akash-sdl/advanced-features/index.md b/src/content/Docs/developers/deployment/akash-sdl/advanced-features/index.md
index 559ab3c9f..f4b962121 100644
--- a/src/content/Docs/developers/deployment/akash-sdl/advanced-features/index.md
+++ b/src/content/Docs/developers/deployment/akash-sdl/advanced-features/index.md
@@ -256,6 +256,80 @@ If the `reclamation` block is omitted, reclamation is not required and any provi
 
 ---
 
+## Confidential Compute (TEE)
+
+Request hardware-isolated Trusted Execution Environments (TEE) to fully secure your workloads during processing. Akash supports AMD SEV-SNP and Intel TDX with optional NVIDIA GPU Confidential Computing.
+
+### Basic TEE Request
+
+Add a `params.tee` block to any service:
+
+```yaml
+services:
+  web:
+    image: nginx
+    expose:
+      - port: 80
+        to:
+          - global: true
+    params:
+      tee:
+        type: sev-snp
+```
+
+Use `tdx` for Intel TDX instead of `sev-snp`.
+
+### GPU + TEE
+
+Combine GPU workloads with Confidential Compute:
+
+```yaml
+services:
+  inference:
+    image: my-model:latest
+    expose:
+      - port: 8080
+        to:
+          - global: true
+    params:
+      tee:
+        type: tdx-gpu
+
+profiles:
+  compute:
+    inference:
+      resources:
+        cpu:
+          units: 0.5
+        memory:
+          size: 256Mi
+        storage:
+          size: 128Mi
+        gpu:
+          units: 1
+          attributes:
+            vendor:
+              nvidia:
+```
+
+Use `sev-snp-gpu` instead of `tdx-gpu` for AMD hardware.
+
+### TEE Type Reference
+
+| Value | Runtime Class | Hardware |
+|-------|---------------|----------|
+| `sev-snp` | `kata-qemu-snp` | AMD with SEV-SNP |
+| `sev-snp-gpu` | `kata-qemu-nvidia-gpu-snp` | AMD SEV-SNP + NVIDIA CC GPU |
+| `tdx` | `kata-qemu-tdx` | Intel with TDX |
+| `tdx-gpu` | `kata-qemu-nvidia-gpu-tdx` | Intel TDX + NVIDIA CC GPU |
+
+For attestation, security model details, and provider setup, see:
+
+- [Confidential Compute (TEE) Core Concepts](/docs/learn/core-concepts/confidential-compute)
+- [Provider Confidential Compute Setup](/docs/providers/setup-and-installation/kubespray/confidential-compute)
+
+---
+
 ## IP Endpoints (Dedicated IPs)
 
 ### Basic IP Endpoint
diff --git a/src/content/Docs/learn/core-concepts/confidential-compute/index.md b/src/content/Docs/learn/core-concepts/confidential-compute/index.md
new file mode 100644
index 000000000..beb929d3d
--- /dev/null
+++ b/src/content/Docs/learn/core-concepts/confidential-compute/index.md
@@ -0,0 +1,316 @@
+---
+categories: ["Learn", "Core Concepts"]
+tags: ["Confidential Compute", "TEE", "Security", "Privacy", "GPU"]
+weight: 7
+title: "Confidential Compute (TEE)"
+linkTitle: "Confidential Compute"
+description: "Deploy workloads inside hardware-backed Trusted Execution Environments on Akash Network"
+---
+
+**Deploy workloads inside hardware-isolated Trusted Execution Environments (TEEs) where neither the provider nor any other party can access your data or code in memory.**
+
+Standard cloud deployments require trusting the infrastructure operator. Confidential Compute eliminates that requirement. Containers run inside encrypted virtual machines where the CPU hardware enforces isolation, the provider's OS, hypervisor and administrators cannot inspect the workload's memory.
+
+Akash supports AMD SEV-SNP and Intel TDX, with optional NVIDIA GPU Confidential Computing for GPU-accelerated workloads.
+
+---
+
+## Why Confidential Compute?
+
+### Hardware-Enforced Isolation
+
+In a standard deployment, the provider's operating system has full access to container memory. With Confidential Compute:
+
+- **Memory is encrypted by the CPU**, this means the provider's OS, hypervisor and administrators cannot read it
+- **Workloads run in a Trusted Execution Environment (TEE)**, which is an hardware-level isolation, not software sandboxing
+- **Attestation provides cryptographic proof** that the workload is running in a genuine TEE with the expected configuration
+- **GPU memory can also be protected** via NVIDIA Confidential Computing
+
+### Use Cases
+
+**AI & Machine Learning:**
+- Private model inference (protect proprietary models)
+- Confidential fine-tuning on sensitive data
+
+**Healthcare:**
+- Processing protected health information (PHI)
+- Drug discovery on confidential compounds
+
+**General Privacy:**
+- Any workload handling secrets, PII or proprietary algorithms
+- Zero-trust deployments where you cannot trust the infrastructure
+
+---
+
+## Supported TEE Types
+
+Akash currently supports four TEE configurations:
+
+| TEE Type | SDL Value | Description |
+|----------|-----------|-------------|
+| AMD SEV-SNP | `sev-snp` | CPU-only confidential VM on AMD hardware |
+| AMD SEV-SNP + GPU | `sev-snp-gpu` | SEV-SNP with NVIDIA GPU Confidential Computing |
+| Intel TDX | `tdx` | CPU-only confidential VM on Intel hardware |
+| Intel TDX + GPU | `tdx-gpu` | TDX with NVIDIA GPU Confidential Computing |
+
+Both `sev-snp` and `tdx` provide equivalent security guarantees. The choice depends on the provider's hardware. Use the `-gpu` variants when your workload requires GPU acceleration (e.g., AI inference or training).
+
+---
+
+## How It Works
+
+Deploying a confidential workload requires only a `params.tee` block in your SDL. The platform handles the rest:
+
+1. **Your SDL specifies the TEE type** via `params.tee.type`
+2. **The provider schedules the workload** on a TEE-capable node
+3. **A Kata Container VM launches inside the hardware TEE** (AMD SEV-SNP or Intel TDX)
+4. **Your container runs inside the encrypted VM** and all memory is hardware-encrypted
+5. **Bring your own attestation stack or Akash injects its own** alongside your workload
+6. **You can verify the TEE** by requesting to the provider a hardware-signed attestation report at any time
+
+Everything inside the VM boundary is encrypted. The provider's OS and administrators cannot access it.
+
+---
+
+## SDL Configuration
+
+Add a `params.tee` block to your service definition. The rest of the SDL remains unchanged.
+
+### Basic Example — AMD SEV-SNP
+
+```yaml
+---
+version: "2.1"
+
+services:
+  web:
+    image: nginx
+    expose:
+      - port: 80
+        as: 80
+        to:
+          - global: true
+    params:
+      tee:
+        type: sev-snp
+
+profiles:
+  compute:
+    web:
+      resources:
+        cpu:
+          units: 0.5
+        memory:
+          size: 256Mi
+        storage:
+          size: 128Mi
+  placement:
+    westcoast:
+      pricing:
+        web:
+          denom: uact
+          amount: 1000
+
+deployment:
+  web:
+    westcoast:
+      profile: web
+      count: 1
+```
+
+### Basic Example — Intel TDX
+
+The only change is the TEE type:
+
+```yaml
+services:
+  web:
+    image: nginx
+    expose:
+      - port: 80
+        as: 80
+        to:
+          - global: true
+    params:
+      tee:
+        type: tdx
+```
+
+### GPU + TEE Example
+
+To combine GPU workloads with Confidential Compute, use a GPU TEE type and add GPU resources:
+
+```yaml
+---
+version: "2.1"
+
+services:
+  inference:
+    image: my-private-model:latest
+    expose:
+      - port: 8080
+        as: 80
+        to:
+          - global: true
+    params:
+      tee:
+        type: tdx-gpu
+
+profiles:
+  compute:
+    inference:
+      resources:
+        cpu:
+          units: 0.5
+        memory:
+          size: 256Mi
+        storage:
+          size: 128Mi
+        gpu:
+          units: 1
+          attributes:
+            vendor:
+              nvidia:
+  placement:
+    westcoast:
+      pricing:
+        inference:
+          denom: uact
+          amount: 10000
+
+deployment:
+  inference:
+    westcoast:
+      profile: inference
+      count: 1
+```
+
+> You can also use `sev-snp-gpu` instead of `tdx-gpu` depending on which TEE hardware the provider offers.
+
+### TEE Type Reference
+
+The `params.tee.type` field accepts the following values:
+
+| Value | Runtime Class | Hardware Required |
+|-------|---------------|-------------------|
+| `sev-snp` | `kata-qemu-snp` | AMD with SEV-SNP |
+| `sev-snp-gpu` | `kata-qemu-nvidia-gpu-snp` | AMD with SEV-SNP + NVIDIA CC GPU |
+| `tdx` | `kata-qemu-tdx` | Intel with TDX |
+| `tdx-gpu` | `kata-qemu-nvidia-gpu-tdx` | Intel with TDX + NVIDIA CC GPU |
+
+---
+
+## Attestation
+
+Attestation is how you verify that your workload is genuinely running inside a hardware TEE. The attestation report is signed by the CPU hardware itself and the provider cannot forge or tamper with it.
+
+### Overview
+
+The attestation flow has three stages:
+
+1. **Discovery**: Query the provider's directory API to locate the attestation component for your lease
+2. **Challenge**: Send a random 64-byte nonce (your challenge) to the provider. The nonce ensures the report is fresh and was generated for your specific request
+3. **Verification**: The attestation component returns a hardware-signed report. Verify it against AMD or Intel root-of-trust certificates to confirm the TEE is genuine
+
+### Using the CLI
+
+The simplest way to request attestation:
+
+```bash
+provider-services lease-attestation \
+  --dseq <deployment-sequence> \
+  --gseq <group-sequence> \
+  --oseq <order-sequence> \
+  --provider <provider-address> \
+  --from <your-key>
+```
+
+### API Reference
+
+For programmatic verification, the attestation API has two endpoints.
+
+#### Discovery (Directory)
+
+Returns routing hints to locate the attestation sidecar. This endpoint is unauthenticated.
+
+```
+GET /attestation/directory/{dseq}/{gseq}/{oseq}
+```
+
+```json
+{
+  "endpoint": "https://<sidecar-url>/quote",
+  "tee_type": "amd-sev-snp",
+  "runtime_class": "kata-qemu-snp",
+  "protocol_version": "2",
+  "expected_launch_measurement": "<hex>",
+  "expected_image_digest": "<digest>"
+}
+```
+
+> **Important:** The directory response is **untrusted**. All values are advisory routing hints only. You must verify claims against the hardware-signed attestation report.
+
+#### Quote (Challenge-Response)
+
+Send your nonce to receive a hardware-signed attestation report:
+
+```
+POST /lease/{dseq}/{gseq}/{oseq}/attestation/quote
+```
+
+Request:
+```json
+{
+  "nonce": "<base64-encoded-64-bytes>",
+  "bind_tls": false
+}
+```
+
+Response:
+```json
+{
+  "report": "<base64-raw-attestation-report>",
+  "cert_chain": "<base64-certificate-chain>",
+  "tee_type": "snp",
+  "auxblob": "<base64-auxiliary-blob>",
+  "gpu_reports": [
+    {
+      "device_index": 0,
+      "report": "<base64-gpu-attestation>"
+    }
+  ],
+  "tls_bound": false
+}
+```
+
+The `report` field contains the raw hardware-signed attestation evidence (an SNP report or TDX quote). For GPU TEE types, `gpu_reports` contains a per-device entry for every GPU in the workload, each with its own hardware-signed attestation evidence. Verify GPU reports against NVIDIA's published root certificates.
+
+### TLS Channel Binding
+
+Setting `bind_tls: true` binds the attestation report to the current TLS session. The sidecar computes `SHA-512(tls_public_key || nonce)[:64]` and places the result in the report's `REPORT_DATA` field. This proves the attestation came from the same endpoint you're connected to, preventing relay attacks.
+
+### Security Model
+
+The attestation design enforces these properties:
+
+- **Provider cannot modify evidence** — the nonce and hardware report are passed through verbatim
+- **Directory hints are untrusted** — they are routing aids only; always verify against the hardware-signed report
+- **Nonce proves freshness** — the hardware includes your nonce in `REPORT_DATA`, proving the report was generated for your request
+- **Channel binding is optional but recommended** — for sensitive workloads, use `bind_tls: true` to prevent attestation relay
+
+---
+
+## Limitations and Considerations
+
+- **Provider availability**: Only providers with TEE-capable hardware can accept confidential workloads. Look for the `tee/type` attribute when selecting a provider.
+- **Performance**: Memory encryption adds a small overhead (~1-5%). GPU Confidential Computing may add further overhead depending on the workload.
+- **Sidecar resources**: The attestation sidecar consumes modest resources (10m CPU, 32-64Mi memory) which are automatically included in resource accounting.
+- **Runtime environment**: TEE workloads run inside Kata VMs rather than standard containers. Most workloads are unaffected, but features that depend on direct host kernel access may behave differently.
+
+---
+
+## Related Topics
+
+- [Provider Confidential Compute Setup](/docs/providers/setup-and-installation/kubespray/confidential-compute) — How providers enable TEE support
+- [GPU Deployments](/docs/learn/core-concepts/gpu-deployments) — General GPU deployment guide
+- [Provider Attributes](/docs/providers/operations/provider-attributes) — How providers advertise TEE capabilities
diff --git a/src/content/Docs/providers/operations/provider-attributes/index.md b/src/content/Docs/providers/operations/provider-attributes/index.md
index 1eeeefd2c..f22f4aee3 100644
--- a/src/content/Docs/providers/operations/provider-attributes/index.md
+++ b/src/content/Docs/providers/operations/provider-attributes/index.md
@@ -470,6 +470,26 @@ Advertise support for advanced features.
   value: true
 ```
 
+### tee/type
+
+- **Values**: `sev-snp`, `sev-snp-gpu`, `tdx`, `tdx-gpu`
+- **Purpose**: Advertise Trusted Execution Environment (Confidential Compute) support
+- **Required**: Only if your provider supports TEE workloads
+
+| Value | Description |
+|-------|-------------|
+| `sev-snp` | AMD SEV-SNP (CPU-only confidential VMs) |
+| `sev-snp-gpu` | AMD SEV-SNP with NVIDIA GPU Confidential Computing |
+| `tdx` | Intel TDX (CPU-only confidential VMs) |
+| `tdx-gpu` | Intel TDX with NVIDIA GPU Confidential Computing |
+
+```yaml
+- key: tee/type
+  value: sev-snp
+```
+
+> See [Confidential Compute Setup](/docs/providers/setup-and-installation/kubespray/confidential-compute) for full TEE configuration instructions.
+
 ---
 
 ## GPU Capabilities
@@ -638,6 +658,10 @@ attributes:
     value: "true"
   - key: cuda
     value: "12.7"
+
+  # Confidential Compute (if TEE hardware is available)
+  # - key: tee/type
+  #   value: sev-snp
 ```
 
 ---
@@ -658,6 +682,7 @@ Look for your attributes in the `attributes` section of the output.
 
 - [Provider Installation](/docs/providers/setup-and-installation/kubespray/provider-installation)
 - [GPU Support Setup](/docs/providers/setup-and-installation/kubespray/gpu-support)
+- [Confidential Compute Setup](/docs/providers/setup-and-installation/kubespray/confidential-compute) — TEE configuration guide
 - [Provider Audit](/docs/providers/operations/provider-audit) — Official audit process and attribute checklist
 - [Provider Attributes Schema](https://github.com/akash-network/console/blob/main/config/provider-attributes.json) (canonical key list)
 - [Provider Configs Repository](https://github.com/akash-network/provider-configs)
diff --git a/src/content/Docs/providers/setup-and-installation/kubespray/confidential-compute/index.md b/src/content/Docs/providers/setup-and-installation/kubespray/confidential-compute/index.md
new file mode 100644
index 000000000..5f4a9e128
--- /dev/null
+++ b/src/content/Docs/providers/setup-and-installation/kubespray/confidential-compute/index.md
@@ -0,0 +1,511 @@
+---
+categories: ["Providers"]
+tags: ["Confidential Compute", "TEE", "Advanced Features", "Configuration"]
+weight: 3
+title: "Confidential Compute (TEE) Support"
+linkTitle: "Confidential Compute"
+description: "Enable Trusted Execution Environment support on your Akash provider"
+---
+
+This guide shows how to enable Confidential Compute (TEE) support on your Akash provider, allowing tenants to deploy workloads inside hardware-backed Trusted Execution Environments.
+
+> **Prerequisites:** You must have a working Akash provider with Kubernetes already deployed. See [Kubernetes Setup](/docs/providers/setup-and-installation/kubespray/kubernetes-setup) and [Provider Installation](/docs/providers/setup-and-installation/kubespray/provider-installation).
+
+> **Hardware required:** Your nodes must have TEE-capable processors, AMD EPYC (Milan or later) for SEV-SNP, or Intel Xeon (Sapphire Rapids or later) for TDX.
+
+> **Do not enable LUKS (full-disk encryption) on TEE host nodes.** SEV-SNP and TDX encrypt guest VM memory at the hardware level, that is the security boundary that matters for tenant workloads. LUKS on the host root filesystem adds boot-time complexity without providing additional protection.
+
+---
+
+## Overview
+
+Confidential Compute on Akash uses [Kata Containers](https://katacontainers.io/) to run tenant workloads inside hardware-encrypted virtual machines. The provider automatically:
+
+1. Schedules TEE workloads onto nodes with the correct runtime class
+2. Injects an attestation sidecar into each confidential workload
+3. Proxies attestation requests from tenants to the sidecar inside the TEE
+
+### Supported Configurations
+
+| TEE Type | Runtime Class | Hardware |
+|----------|---------------|----------|
+| AMD SEV-SNP | `kata-qemu-snp` | AMD with SEV-SNP enabled in BIOS |
+| AMD SEV-SNP + GPU | `kata-qemu-nvidia-gpu-snp` | Above + NVIDIA CC-capable GPU |
+| Intel TDX | `kata-qemu-tdx` | Intel with TDX enabled in BIOS |
+| Intel TDX + GPU | `kata-qemu-nvidia-gpu-tdx` | Above + NVIDIA CC-capable GPU |
+
+---
+
+## STEP 1 — Verify Hardware Support
+
+### AMD SEV-SNP
+
+Run on each TEE node:
+
+```bash
+# Check CPU supports SEV-SNP
+dmesg | grep -i sev
+```
+
+You should see output indicating SEV-SNP is enabled:
+
+```
+ccp 0000:22:00.1: sev enabled
+ccp 0000:22:00.1: SEV-SNP API:1.51 build:3
+SEV supported: 410 ASIDs
+SEV-ES and SEV-SNP supported: 99 ASIDs
+```
+
+Verify the device exists:
+
+```bash
+ls -la /dev/sev-guest
+```
+
+> **If SEV-SNP is not showing:** Enable it in your BIOS/UEFI under AMD CBS > CPU Configuration > SEV-SNP. Ensure your firmware is up to date.
+
+### Intel TDX
+
+Run on each TEE node:
+
+```bash
+# Check CPU supports TDX
+dmesg | grep -i tdx
+```
+
+You should see:
+
+```
+tdx: TDX module initialized
+virt/tdx: module initialized
+```
+
+Verify the device exists:
+
+```bash
+ls -la /dev/tdx_guest  # or /dev/tdx-attest on older kernels
+```
+
+> **If TDX is not showing:** Enable it in your BIOS/UEFI under Intel Advanced Menu > TDX. Requires a TDX-capable kernel (Linux 6.2+).
+
+---
+
+## STEP 2 — Install Kata Containers
+
+Once hardware support is confirmed, install the [Kata Containers](https://katacontainers.io/) runtime. Kata runs each confidential workload inside a lightweight VM with hardware-encrypted memory. Install it on **each TEE node**.
+
+### Install Kata Packages
+
+```bash
+# Add Kata Containers repository
+sudo mkdir -p /etc/apt/keyrings
+wget -qO- https://packagecloud.io/kata-containers/stable/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kata-containers.gpg
+echo "deb [signed-by=/etc/apt/keyrings/kata-containers.gpg] https://packagecloud.io/kata-containers/stable/ubuntu/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/kata-containers.list
+
+sudo apt update
+sudo apt install -y kata-containers
+```
+
+### Configure Kata for Your TEE Type
+
+#### AMD SEV-SNP Configuration
+
+Create the Kata configuration for SNP at `/etc/kata-containers/configuration-qemu-snp.toml`:
+
+```toml
+[hypervisor.qemu]
+path = "/usr/bin/qemu-system-x86_64"
+kernel = "/usr/share/kata-containers/vmlinuz-snp.container"
+image = "/usr/share/kata-containers/kata-containers-snp.img"
+machine_type = "q35"
+firmware = "/usr/share/OVMF/OVMF_CODE.fd"
+confidential_guest = true
+sev_snp_guest = true
+
+default_memory = 256
+default_vcpus = 1
+
+[runtime]
+enable_annotations = ["io.katacontainers.*"]
+sandbox_cgroup_only = true
+```
+
+#### Intel TDX Configuration
+
+Create the Kata configuration for TDX at `/etc/kata-containers/configuration-qemu-tdx.toml`:
+
+```toml
+[hypervisor.qemu]
+path = "/usr/bin/qemu-system-x86_64"
+kernel = "/usr/share/kata-containers/vmlinuz-tdx.container"
+image = "/usr/share/kata-containers/kata-containers-tdx.img"
+machine_type = "q35"
+firmware = "/usr/share/OVMF/OVMF_CODE.fd"
+confidential_guest = true
+tdx_guest = true
+
+default_memory = 256
+default_vcpus = 1
+
+[runtime]
+enable_annotations = ["io.katacontainers.*"]
+sandbox_cgroup_only = true
+```
+
+---
+
+## STEP 3 — Configure Containerd Runtime Classes
+
+Containerd needs to know about the Kata runtime classes so it can launch confidential VMs. Add the entries below to `/etc/containerd/config.toml` on **each TEE node**. Only add the runtime classes that match your hardware.
+
+### AMD SEV-SNP
+
+```toml
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu-snp]
+  runtime_type = "io.containerd.kata-qemu-snp.v2"
+  privileged_without_host_devices = true
+  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu-snp.options]
+    ConfigPath = "/etc/kata-containers/configuration-qemu-snp.toml"
+```
+
+For SNP with GPU support, add:
+
+```toml
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu-nvidia-gpu-snp]
+  runtime_type = "io.containerd.kata-qemu-nvidia-gpu-snp.v2"
+  privileged_without_host_devices = true
+  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu-nvidia-gpu-snp.options]
+    ConfigPath = "/etc/kata-containers/configuration-qemu-nvidia-gpu-snp.toml"
+```
+
+### Intel TDX
+
+```toml
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu-tdx]
+  runtime_type = "io.containerd.kata-qemu-tdx.v2"
+  privileged_without_host_devices = true
+  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu-tdx.options]
+    ConfigPath = "/etc/kata-containers/configuration-qemu-tdx.toml"
+```
+
+For TDX with GPU support, add:
+
+```toml
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu-nvidia-gpu-tdx]
+  runtime_type = "io.containerd.kata-qemu-nvidia-gpu-tdx.v2"
+  privileged_without_host_devices = true
+  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata-qemu-nvidia-gpu-tdx.options]
+    ConfigPath = "/etc/kata-containers/configuration-qemu-nvidia-gpu-tdx.toml"
+```
+
+Restart containerd after configuration changes:
+
+```bash
+sudo systemctl restart containerd
+```
+
+---
+
+## STEP 4 — Create Kubernetes RuntimeClasses
+
+Kubernetes uses [RuntimeClass](https://kubernetes.io/docs/concepts/containers/runtime-class/) resources to map workloads to specific container runtimes. Create one for each TEE type your provider supports. Only create the ones that match your hardware, you do not need all four.
+
+### AMD SEV-SNP
+
+```bash
+cat <<EOF | kubectl apply -f -
+apiVersion: node.k8s.io/v1
+kind: RuntimeClass
+metadata:
+  name: kata-qemu-snp
+handler: kata-qemu-snp
+overhead:
+  podFixed:
+    memory: "160Mi"
+    cpu: "250m"
+EOF
+```
+
+For SNP with GPU:
+
+```bash
+cat <<EOF | kubectl apply -f -
+apiVersion: node.k8s.io/v1
+kind: RuntimeClass
+metadata:
+  name: kata-qemu-nvidia-gpu-snp
+handler: kata-qemu-nvidia-gpu-snp
+overhead:
+  podFixed:
+    memory: "160Mi"
+    cpu: "250m"
+EOF
+```
+
+### Intel TDX
+
+```bash
+cat <<EOF | kubectl apply -f -
+apiVersion: node.k8s.io/v1
+kind: RuntimeClass
+metadata:
+  name: kata-qemu-tdx
+handler: kata-qemu-tdx
+overhead:
+  podFixed:
+    memory: "160Mi"
+    cpu: "250m"
+EOF
+```
+
+For TDX with GPU:
+
+```bash
+cat <<EOF | kubectl apply -f -
+apiVersion: node.k8s.io/v1
+kind: RuntimeClass
+metadata:
+  name: kata-qemu-nvidia-gpu-tdx
+handler: kata-qemu-nvidia-gpu-tdx
+overhead:
+  podFixed:
+    memory: "160Mi"
+    cpu: "250m"
+EOF
+```
+
+### Verify RuntimeClasses
+
+```bash
+kubectl get runtimeclass
+```
+
+Expected output (depending on which TEE types you configured):
+
+```
+NAME                         HANDLER                      AGE
+kata-qemu-snp                kata-qemu-snp                1m
+kata-qemu-nvidia-gpu-snp     kata-qemu-nvidia-gpu-snp     1m
+kata-qemu-tdx                kata-qemu-tdx                1m
+kata-qemu-nvidia-gpu-tdx     kata-qemu-nvidia-gpu-tdx     1m
+```
+
+---
+
+## STEP 5 — Configure Provider Flags
+
+The Akash provider automatically injectw an attestation sidecar into every confidential workload if requested by the user. This sidecar runs inside the TEE and serves hardware-signed attestation reports to tenants. Enable it with the following flags.
+
+### Required Flags
+
+| Flag | Description | Required |
+|------|-------------|----------|
+| `--attestation-webhook-enabled` | Enables the Kubernetes mutating admission webhook. When active, the provider intercepts pod creation requests for confidential compute workloads and automatically injects the attestation sidecar container before scheduling. | Yes |
+| `--attestation-sidecar-image` | Docker image reference for the attestation sidecar (e.g. `ghcr.io/akash-network/attestation-sidecar:latest`). Required when the webhook is enabled — the provider passes this image to the webhook for injection into every confidential workload. | Yes |
+| `--attestation-webhook-port` | HTTPS port for the webhook server that handles Kubernetes API callbacks. In production, pair this with `--gateway-tls-cert` and `--gateway-tls-key` using a certificate whose SAN includes the provider's K8s service DNS name. Defaults to `9443` and auto-generates a self-signed cert if TLS files are omitted. | No |
+
+### Optional Flags
+
+| Flag | Description | Default |
+|------|-------------|---------|
+| `--attestation-expected-measurement` | Hex-encoded expected AMD SEV-SNP launch measurement. Returned as an **advisory hint only** by the provider's directory endpoint. The provider does not verify this value against hardware, tenants must independently fetch the hardware-signed SNP report from the sidecar and compare the `MEASUREMENT` field themselves. Do not treat this as a trust signal. | Empty |
+| `--attestation-expected-image-digest` | Expected digest of the Kata VM image. Like the measurement flag, this is an **untrusted advisory hint** surfaced in the directory response for tenant convenience. Tenants should verify the actual image digest through their own trusted channels. | Empty |
+| `--attestation-mock` | Run the sidecar in mock mode with synthetic (fake) attestation reports instead of real TEE hardware evidence. Also switches the webhook registration to a `host.docker.internal` URL for local clusters. **For local development only, never enable in production.** | `false` |
+
+### Example: Helm Values
+
+When deploying the provider with Helm, add these values:
+
+```yaml
+# provider.yaml
+attestation:
+  webhookEnabled: true
+  sidecarImage: "ghcr.io/akash-network/attestation-sidecar:latest"
+  webhookPort: 9443
+  # Optional advisory hints
+  # expectedMeasurement: "<hex-encoded-measurement>"
+  # expectedImageDigest: "<kata-vm-image-digest>"
+```
+
+### Example: CLI Flags
+
+```bash
+provider-services run \
+  --attestation-webhook-enabled \
+  --attestation-sidecar-image "ghcr.io/akash-network/attestation-sidecar:latest" \
+  --attestation-webhook-port 9443
+```
+
+---
+
+## STEP 6 — Configure Provider Attributes
+
+Tenants discover TEE-capable providers through on-chain attributes. Add the `tee/type` attribute to your `provider.yaml` so your provider appears in TEE-filtered searches. Set the value to the most capable TEE type your hardware supports:
+
+### AMD SEV-SNP (CPU only)
+
+```yaml
+attributes:
+  - key: tee/type
+    value: sev-snp
+```
+
+### AMD SEV-SNP + GPU
+
+```yaml
+attributes:
+  - key: tee/type
+    value: sev-snp-gpu
+```
+
+### Intel TDX (CPU only)
+
+```yaml
+attributes:
+  - key: tee/type
+    value: tdx
+```
+
+### Intel TDX + GPU
+
+```yaml
+attributes:
+  - key: tee/type
+    value: tdx-gpu
+```
+
+After updating attributes, restart your provider:
+
+```bash
+cd /root/provider
+helm upgrade akash-provider akash/provider \
+  -n akash-services \
+  -f provider.yaml \
+  --set bidpricescript="$(cat price_script.sh | openssl base64 -A)"
+```
+
+---
+
+## STEP 7 — Verify Setup
+
+### Test with a Confidential Deployment
+
+Create a test SDL file (`test-cc.yaml`):
+
+```yaml
+---
+version: "2.1"
+
+services:
+  web:
+    image: nginx
+    expose:
+      - port: 80
+        as: 80
+        to:
+          - global: true
+    params:
+      tee:
+        type: sev-snp
+
+profiles:
+  compute:
+    web:
+      resources:
+        cpu:
+          units: 0.5
+        memory:
+          size: 256Mi
+        storage:
+          size: 128Mi
+  placement:
+    akash:
+      pricing:
+        web:
+          denom: uact
+          amount: 1000
+
+deployment:
+  web:
+    akash:
+      profile: web
+      count: 1
+```
+
+Deploy and verify:
+
+```bash
+# Deploy
+provider-services tx deployment create test-cc.yaml --from <your-key>
+
+# After lease is created, check that the pod has the correct runtime class
+kubectl get pods -n <lease-namespace> -o jsonpath='{.items[0].spec.runtimeClassName}'
+# Expected: kata-qemu-snp
+
+# Check the attestation sidecar was injected
+kubectl get pods -n <lease-namespace> -o jsonpath='{.items[0].spec.containers[*].name}'
+# Expected: web akash-attestation-sidecar
+```
+
+### Request an Attestation Quote
+
+```bash
+provider-services lease-attestation \
+  --dseq <deployment-sequence> \
+  --gseq 1 \
+  --oseq 1 \
+  --provider <provider-address> \
+  --from <your-key>
+```
+
+A successful response contains a hardware-signed attestation report, confirming the workload is running in a genuine TEE.
+
+---
+
+## Troubleshooting
+
+### Pod stuck in Pending
+
+```bash
+kubectl describe pod <pod-name> -n <lease-namespace>
+```
+
+Common causes:
+- **RuntimeClass not found**: Verify the RuntimeClass exists with `kubectl get runtimeclass`
+- **No TEE-capable nodes**: Ensure nodes with TEE hardware are labeled and schedulable
+- **Kata not installed**: Check that Kata is properly installed on the target node
+
+### Attestation sidecar not injected
+
+- Verify the webhook is running: `kubectl get mutatingwebhookconfigurations`
+- Check provider logs for webhook errors
+- Ensure `--attestation-webhook-enabled` is set
+
+### Attestation quote returns error
+
+- Verify the sidecar container is running: `kubectl logs <pod> -c akash-attestation-sidecar -n <namespace>`
+- Check that TEE devices are accessible inside the Kata VM
+- For GPU variants, verify NVIDIA drivers are available inside the guest
+
+### SEV-SNP device not found
+
+- Ensure BIOS has SEV-SNP enabled
+- Update to latest firmware/microcode
+- Verify kernel supports SEV-SNP (Linux 5.19+)
+- Check `dmesg | grep -i sev` for errors
+
+### TDX device not found
+
+- Ensure BIOS has TDX enabled
+- Verify TDX kernel module is loaded: `lsmod | grep tdx`
+- TDX requires Linux 6.2+ with TDX support compiled in
+
+---
+
+## Related Topics
+
+- [Confidential Compute Overview](/docs/learn/core-concepts/confidential-compute) — Tenant-facing guide for deploying confidential workloads
+- [SDL Advanced Features](/docs/developers/deployment/akash-sdl/advanced-features) — SDL reference for TEE configuration
+- [GPU Support](/docs/providers/setup-and-installation/kubespray/gpu-support) — Enable GPU resources on your provider
+- [Provider Attributes](/docs/providers/operations/provider-attributes) — Advertise provider capabilities
+- [Provider Installation](/docs/providers/setup-and-installation/kubespray/provider-installation) - Base provider setup
diff --git a/src/styles/globals.css b/src/styles/globals.css
index c72b5e898..395d4170b 100644
--- a/src/styles/globals.css
+++ b/src/styles/globals.css
@@ -326,6 +326,36 @@ html body[data-scroll-locked] {
   word-break: break-word;
 }
 
+.prose table {
+  display: block;
+  overflow-x: auto;
+  max-width: 100%;
+}
+
+.prose td:first-child,
+.prose th:first-child {
+  white-space: nowrap;
+  word-break: normal;
+}
+
+.prose td:last-child,
+.prose th:last-child {
+  white-space: nowrap;
+  word-break: normal;
+}
+
+.prose td:first-child code,
+.prose th:first-child code {
+  white-space: nowrap;
+  word-break: normal;
+}
+
+.prose td:last-child code,
+.prose th:last-child code {
+  white-space: nowrap;
+  word-break: normal;
+}
+
 /* Inline `code` in docs: match body line height; fenced `pre > code` resets below. */
 .prose p code,
 .prose li code,