From 795869152dfba2a4cc5b227f44eecb9b0cd5a104 Mon Sep 17 00:00:00 2001
From: LandonTClipp <11232769+LandonTClipp@users.noreply.github.com>
Date: Tue, 3 Mar 2026 17:13:41 -0600
Subject: [PATCH] docs: Move to mkdocs-material, port Helm to docs site

This supersedes https://github.com/kata-containers/kata-containers/pull/12622.
I replaced Zensical with mkdocs-materialx. Materialx is a fork of mkdocs-material
created after mkdocs-material was put into maintenance mode. We'll use this
platform until Zensical is more feature complete.

Added a few of the existing docs into the site to make a more user-friendly flow.

Signed-off-by: LandonTClipp <11232769+LandonTClipp@users.noreply.github.com>
---
 .cspell.yaml                                  |   1 +
 .github/workflows/docs.yaml                   |  43 +-
 Makefile                                      |   8 +-
 docs/.nav.yml                                 |  18 +
 docs/Dockerfile                               |  11 +
 docs/assets/{ => images}/favicon.svg          |   0
 docs/helm-configuration.md                    | 264 +++++++++
 docs/hypervisors.md                           |  91 +--
 docs/index.md                                 |  94 +++
 docs/installation.md                          |  64 +++
 docs/prerequisites.md                         | 116 ++++
 docs/requirements.txt                         |   9 +
 docs/runtime-configuration.md                 |  56 ++
 .../NVIDIA-GPU-passthrough-and-Kata-QEMU.md   |   1 +
 mkdocs.yaml                                   |  91 +++
 .../kata-deploy/helm-chart/README.md          | 540 +-----------------
 zensical.toml                                 | 318 -----------
 17 files changed, 787 insertions(+), 938 deletions(-)
 create mode 100644 docs/.nav.yml
 create mode 100644 docs/Dockerfile
 rename docs/assets/{ => images}/favicon.svg (100%)
 create mode 100644 docs/helm-configuration.md
 create mode 100644 docs/index.md
 create mode 100644 docs/installation.md
 create mode 100644 docs/prerequisites.md
 create mode 100644 docs/requirements.txt
 create mode 100644 docs/runtime-configuration.md
 create mode 100644 mkdocs.yaml
 delete mode 100644 zensical.toml

diff --git a/.cspell.yaml b/.cspell.yaml
index 9d355e3b53..06f45a9389 100644
--- a/.cspell.yaml
+++ b/.cspell.yaml
@@ -32,5 +32,6 @@ ignoreRegExpList:
 ignorePaths:
   - "**/vendor/**"  # vendor files aren't owned by us
   - "**/src/runtime/virtcontainers/pkg/cloud-hypervisor/client/**"  # Generated files
+  - "**/requirements.txt"
 
 useGitignore: true
diff --git a/.github/workflows/docs.yaml b/.github/workflows/docs.yaml
index 29543e5692..73bb6e9771 100644
--- a/.github/workflows/docs.yaml
+++ b/.github/workflows/docs.yaml
@@ -4,17 +4,18 @@ on:
     branches:
       - main
 permissions: {}
+concurrency:
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
+  cancel-in-progress: true
+
 jobs:
-  deploy-docs:
-    name: deploy-docs
+  build:
+    runs-on: ubuntu-24.04
+    name: Build docs
     permissions:
       contents: read
       pages: write
       id-token: write
-    environment:
-      name: github-pages
-      url: ${{ steps.deployment.outputs.page_url }}
-    runs-on: ubuntu-latest
     steps:
       - uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5.0.0
       - uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5.0.1
@@ -23,10 +24,30 @@ jobs:
       - uses: actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065 # v5.6.0
         with:
           python-version: 3.x
-      - run: pip install zensical
-      - run: zensical build --clean
+
+      - run: pip install -r docs/requirements.txt
+      - run: python3 -m mkdocs build --config-file ./mkdocs.yaml --site-dir site/
+        id: build
+
       - uses: actions/upload-pages-artifact@7b1f4a764d45c48632c6b24a0339c27f5614fb0b # v4.0.0
-        with:
-          path: site
-      - uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4.0.5
         id: deployment
+        with:
+          path: site/
+          name: github-pages
+
+  deploy:
+    needs: build
+    runs-on: ubuntu-24.04
+    name: Deploy docs
+    permissions:
+      pages: write
+      id-token: write
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    steps:
+      - name: Deploy to GitHub Pages
+        uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4.0.5
+        id: deployment
+        with:
+          artifact_name: github-pages
diff --git a/Makefile b/Makefile
index e53763cedc..03e4cb1167 100644
--- a/Makefile
+++ b/Makefile
@@ -49,8 +49,11 @@ docs-url-alive-check:
 build-and-publish-kata-debug:
 	bash tools/packaging/kata-debug/kata-debug-build-and-upload-payload.sh ${KATA_DEBUG_REGISTRY} ${KATA_DEBUG_TAG}
 
-docs-serve:
-	docker run --rm -p 8000:8000 -v ./docs:/docs:ro -v ${PWD}/zensical.toml:/zensical.toml:ro zensical/zensical serve --config-file /zensical.toml -a 0.0.0.0:8000
+docs-build:
+	docker build -t kata-docs:latest -f ./docs/Dockerfile ./docs
+
+docs-serve: docs-build
+	docker run --rm -p 8000:8000 -v ${PWD}:/docs:ro kata-docs:latest serve --config-file /docs/mkdocs.yaml -a 0.0.0.0:8000
 
 .PHONY: \
 	all \
@@ -59,4 +62,5 @@ docs-serve:
 	default \
 	static-checks \
 	docs-url-alive-check \
+	docs-build \
 	docs-serve
diff --git a/docs/.nav.yml b/docs/.nav.yml
new file mode 100644
index 0000000000..324a9f0c12
--- /dev/null
+++ b/docs/.nav.yml
@@ -0,0 +1,18 @@
+# https://lukasgeiter.github.io/mkdocs-awesome-nav/
+nav:
+  - Home: index.md
+  - Getting Started:
+    - prerequisites.md
+    - installation.md
+    - Configuration:
+        - helm-configuration.md
+        - runtime-configuration.md
+  - Platform Support:
+    - hypervisors.md
+  - Guides:
+    - Use Cases:
+      - NVIDIA GPU Passthrough: use-cases/NVIDIA-GPU-passthrough-and-Kata-QEMU.md
+      - NVIDIA vGPU: use-cases/NVIDIA-GPU-passthrough-and-Kata.md
+      - Intel Discrete GPU: use-cases/Intel-Discrete-GPU-passthrough-and-Kata.md
+  - Misc:
+    - Architecture: design/architecture/
diff --git a/docs/Dockerfile b/docs/Dockerfile
new file mode 100644
index 0000000000..03d7235a2f
--- /dev/null
+++ b/docs/Dockerfile
@@ -0,0 +1,11 @@
+# Copyright 2026 Kata Contributors
+#
+# SPDX-License-Identifier: Apache-2.0
+#
+FROM python:3.12-slim
+
+WORKDIR /
+COPY ./requirements.txt requirements.txt
+RUN pip install --no-cache-dir -r requirements.txt
+
+ENTRYPOINT ["python3", "-m", "mkdocs"]
diff --git a/docs/assets/favicon.svg b/docs/assets/images/favicon.svg
similarity index 100%
rename from docs/assets/favicon.svg
rename to docs/assets/images/favicon.svg
diff --git a/docs/helm-configuration.md b/docs/helm-configuration.md
new file mode 100644
index 0000000000..2b55f36321
--- /dev/null
+++ b/docs/helm-configuration.md
@@ -0,0 +1,264 @@
+# Helm Configuration
+
+## Parameters
+
+The helm chart provides a comprehensive set of configuration options. You may view the parameters and their descriptions by going to the [GitHub source](https://github.com/kata-containers/kata-containers/blob/main/tools/packaging/kata-deploy/helm-chart/kata-deploy/values.yaml) or by using helm:
+
+```sh
+# List available kata-deploy chart versions:
+#   helm search repo kata-deploy-charts/kata-deploy --versions
+#
+# Then replace X.Y.Z below with the desired chart version:
+helm show values --version X.Y.Z oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy
+```
+
+### shims
+
+Kata ships with a number of pre-built artifacts and runtimes. You may selectively enable or disable specific shims. For example:
+
+```yaml title="values.yaml"
+shims:
+  disableAll: true
+  qemu:
+    enabled: true
+  qemu-nvidia-gpu:
+    enabled: true
+  qemu-nvidia-gpu-snp:
+    enabled: false
+
+```
+
+Shims can also have configuration options specific to them:
+
+```yaml
+  qemu-nvidia-gpu:
+    enabled: ~
+    supportedArches:
+      - amd64
+      - arm64
+    allowedHypervisorAnnotations: []
+    containerd:
+      snapshotter: ""
+    runtimeClass:
+      # This label is automatically added by gpu-operator. Override it
+      # if you want to use a different label.
+      # Uncomment once GPU Operator v26.3 is out
+      # nodeSelector:
+        # nvidia.com/cc.ready.state: "false"
+```
+
+It's best to reference the default `values.yaml` file above for more details.
+
+### Custom Runtimes
+
+Kata allows you to create custom runtime configurations. This is done by overlaying one of the pre-existing runtime configs with user-provided configs. For example, we can use the `qemu-nvidia-gpu` as a base config and overlay our own parameters to it:
+
+```yaml
+customRuntimes:
+  enabled: false
+  runtimes:
+    my-gpu-runtime:
+      baseConfig: "qemu-nvidia-gpu"  # Required: existing config to use as base
+      dropIn: |                      # Optional: overrides via config.d mechanism
+        [hypervisor.qemu]
+        default_memory = 1024
+        default_vcpus = 4
+      runtimeClass: |
+        kind: RuntimeClass
+        apiVersion: node.k8s.io/v1
+        metadata:
+          name: kata-my-gpu-runtime
+          labels:
+            app.kubernetes.io/managed-by: kata-deploy
+        handler: kata-my-gpu-runtime
+        overhead:
+          podFixed:
+            memory: "640Mi"
+            cpu: "500m"
+        scheduling:
+          nodeSelector:
+            katacontainers.io/kata-runtime: "true"
+      # Optional: CRI-specific configuration
+      containerd:
+        snapshotter: "nydus"  # Configure containerd snapshotter (nydus, erofs, etc.)
+      crio:
+        pullType: "guest-pull"  # Configure CRI-O runtime_pull_image = true
+```
+
+Again, view the default [`values.yaml`](#parameters) file for more details.
+
+## Examples
+
+We provide a few examples that you can pass to helm via the `-f`/`--values` flag.
+
+### [`try-kata-tee.values.yaml`](https://github.com/kata-containers/kata-containers/blob/main/tools/packaging/kata-deploy/helm-chart/kata-deploy/try-kata-tee.values.yaml)
+
+This file enables only the TEE (Trusted Execution Environment) shims for confidential computing:
+
+```sh
+helm install kata-deploy oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy \
+  --version VERSION \
+  -f try-kata-tee.values.yaml
+```
+
+Includes:
+
+- `qemu-snp` - AMD SEV-SNP (amd64)
+- `qemu-tdx` - Intel TDX (amd64)
+- `qemu-se` - IBM Secure Execution for Linux (SEL) (s390x)
+- `qemu-se-runtime-rs` - IBM Secure Execution for Linux (SEL) Rust runtime (s390x)
+- `qemu-cca` - Arm Confidential Compute Architecture (arm64)
+- `qemu-coco-dev` - Confidential Containers development (amd64, s390x)
+- `qemu-coco-dev-runtime-rs` - Confidential Containers development Rust runtime (amd64, s390x)
+
+### [`try-kata-nvidia-gpu.values.yaml`](https://github.com/kata-containers/kata-containers/blob/main/tools/packaging/kata-deploy/helm-chart/kata-deploy/try-kata-nvidia-gpu.values.yaml)
+
+This file enables only the NVIDIA GPU-enabled shims:
+
+```sh
+helm install kata-deploy oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy \
+  --version VERSION \
+  -f try-kata-nvidia-gpu.values.yaml
+```
+
+Includes:
+
+- `qemu-nvidia-gpu` - Standard NVIDIA GPU support (amd64, arm64)
+- `qemu-nvidia-gpu-snp` - NVIDIA GPU with AMD SEV-SNP (amd64)
+- `qemu-nvidia-gpu-tdx` - NVIDIA GPU with Intel TDX (amd64)
+
+### `nodeSelector`
+
+We can deploy Kata only to specific nodes using `nodeSelector`
+
+```sh
+# First, label the nodes where you want kata-containers to be installed
+$ kubectl label nodes worker-node-1 kata-containers=enabled
+$ kubectl label nodes worker-node-2 kata-containers=enabled
+
+# Then install the chart with `nodeSelector`
+$ helm install kata-deploy \
+  --set nodeSelector.kata-containers="enabled" \
+  "${CHART}" --version  "${VERSION}"
+```
+
+You can also use a values file:
+
+```yaml title="values.yaml"
+nodeSelector:
+  kata-containers: "enabled"
+  node-type: "worker"
+```
+
+```sh
+$ helm install kata-deploy -f values.yaml "${CHART}" --version "${VERSION}"
+```
+
+### Multiple Kata installations on the Same Node
+
+For debugging, testing and other use-case it is possible to deploy multiple
+versions of Kata on the very same node. All the needed artifacts are getting the
+`multiInstallSuffix` appended to distinguish each installation. **BEWARE** that one
+needs at least **containerd-2.0** since this version has drop-in conf support
+which is a prerequisite for the `multiInstallSuffix` to work properly.
+
+```sh
+$ helm install kata-deploy-cicd       \
+  -n kata-deploy-cicd                 \
+  --set env.multiInstallSuffix=cicd   \
+  --set env.debug=true                \
+  "${CHART}" --version  "${VERSION}"
+```
+
+Note: `runtimeClasses` are automatically created by Helm (via
+      `runtimeClasses.enabled=true`, which is the default).
+
+Now verify the installation by examining the `runtimeClasses`:
+
+```sh
+$ kubectl get runtimeClasses
+NAME                            HANDLER                         AGE
+kata-clh-cicd                   kata-clh-cicd                   77s
+kata-cloud-hypervisor-cicd      kata-cloud-hypervisor-cicd      77s
+kata-dragonball-cicd            kata-dragonball-cicd            77s
+kata-fc-cicd                    kata-fc-cicd                    77s
+kata-qemu-cicd                  kata-qemu-cicd                  77s
+kata-qemu-coco-dev-cicd         kata-qemu-coco-dev-cicd         77s
+kata-qemu-nvidia-gpu-cicd       kata-qemu-nvidia-gpu-cicd       77s
+kata-qemu-nvidia-gpu-snp-cicd   kata-qemu-nvidia-gpu-snp-cicd   77s
+kata-qemu-nvidia-gpu-tdx-cicd   kata-qemu-nvidia-gpu-tdx-cicd   76s
+kata-qemu-runtime-rs-cicd       kata-qemu-runtime-rs-cicd       77s
+kata-qemu-se-runtime-rs-cicd    kata-qemu-se-runtime-rs-cicd    77s
+kata-qemu-snp-cicd              kata-qemu-snp-cicd              77s
+kata-qemu-tdx-cicd              kata-qemu-tdx-cicd              77s
+kata-stratovirt-cicd            kata-stratovirt-cicd            77s
+```
+
+## RuntimeClass Node Selectors for TEE Shims
+
+**Manual configuration:** Any `nodeSelector` you set under `shims.<shim>.runtimeClass.nodeSelector`
+is **always applied** to that shim's RuntimeClass, whether or not NFD is present. Use this when
+you want to pin TEE workloads to specific nodes (e.g. without NFD, or with custom labels).
+
+**Auto-inject when NFD is present:** If you do *not* set a `runtimeClass.nodeSelector` for a
+TEE shim, the chart can **automatically inject** NFD-based labels when NFD is detected in the
+cluster (deployed by this chart with `node-feature-discovery.enabled=true` or found externally):
+
+- AMD SEV-SNP shims: `amd.feature.node.kubernetes.io/snp: "true"`
+- Intel TDX shims: `intel.feature.node.kubernetes.io/tdx: "true"`
+- IBM Secure Execution for Linux (SEL) shims (s390x): `feature.node.kubernetes.io/cpu-security.se.enabled: "true"`
+
+The chart uses Helm's `lookup` function to detect NFD (by looking for the
+`node-feature-discovery-worker` DaemonSet). Auto-inject only runs when NFD is detected and
+no manual `runtimeClass.nodeSelector` is set for that shim.
+
+**Note**: NFD detection requires cluster access. During `helm template` (dry-run without a
+cluster), external NFD is not seen, so auto-injected labels are not added. Manual
+`runtimeClass.nodeSelector` values are still applied in all cases.
+
+## Customizing Configuration with Drop-in Files
+
+When kata-deploy installs Kata Containers, the base configuration files should not
+be modified directly. Instead, use drop-in configuration files to customize
+settings. This approach ensures your customizations survive kata-deploy upgrades.
+
+### How Drop-in Files Work
+
+The Kata runtime reads the base configuration file and then applies any `.toml`
+files found in the `config.d/` directory alongside it. Files are processed in
+alphabetical order, with later files overriding earlier settings.
+
+### Creating Custom Drop-in Files
+
+To add custom settings, create a `.toml` file in the appropriate `config.d/`
+directory. Use a numeric prefix to control the order of application.
+
+**Reserved prefixes** (used by kata-deploy):
+
+- `10-*`: Core kata-deploy settings
+- `20-*`: Debug settings
+- `30-*`: Kernel parameters
+
+**Recommended prefixes for custom settings**: `50-89`
+
+### Drop-In Config Examples
+
+#### Adding Custom Kernel Parameters
+
+```bash
+# SSH into the node or use kubectl exec
+sudo mkdir -p /opt/kata/share/defaults/kata-containers/runtimes/qemu/config.d/
+sudo cat > /opt/kata/share/defaults/kata-containers/runtimes/qemu/config.d/50-custom.toml << 'EOF'
+[hypervisor.qemu]
+kernel_params = "my_param=value"
+EOF
+```
+
+#### Changing Default Memory Size
+
+```bash
+sudo cat > /opt/kata/share/defaults/kata-containers/runtimes/qemu/config.d/50-memory.toml << 'EOF'
+[hypervisor.qemu]
+default_memory = 4096
+EOF
+```
diff --git a/docs/hypervisors.md b/docs/hypervisors.md
index c0bb88367b..a319a3f40d 100644
--- a/docs/hypervisors.md
+++ b/docs/hypervisors.md
@@ -16,83 +16,38 @@ which hypervisors you may wish to investigate further.
 
 ## Types
 
-| Hypervisor | Written in | Architectures | Type |
-|-|-|-|-|
-|[Cloud Hypervisor] | rust | `aarch64`, `x86_64` | Type 2 ([KVM]) |
-|[Firecracker] | rust | `aarch64`, `x86_64` | Type 2 ([KVM]) |
-|[QEMU] | C | all | Type 2 ([KVM]) | `configuration-qemu.toml` |
-|[`Dragonball`] | rust | `aarch64`, `x86_64` | Type 2 ([KVM]) |
-|[StratoVirt] | rust | `aarch64`, `x86_64` | Type 2 ([KVM]) |
+| Hypervisor | Written in | Architectures | GPU Support | Intel TDX | AMD SEV-SNP |
+|-|-|-|-|-|-|
+|[Cloud Hypervisor](#cloud-hypervisor) | rust | `aarch64`, `x86_64` | :x: | :x: | :x: |
+|[Firecracker](#firecracker) | rust | `aarch64`, `x86_64` | :x: | :x: | :x: |
+|[QEMU](#qemu) | C | all | :white_check_mark: | :white_check_mark: | :white_check_mark: |
+|[Dragonball](#dragonball) | rust | `aarch64`, `x86_64` | :x: | :x: | :x: |
+|StratoVirt | rust | `aarch64`, `x86_64` | :x: | :x: | :x: |
 
-## Determine currently configured hypervisor
+Each Kata runtime is configured for a specific hypervisor through the runtime's configuration file. For example:
 
-```bash
-$ kata-runtime kata-env | awk -v RS= '/\[Hypervisor\]/' | grep Path
+```toml title="/opt/kata/share/defaults/kata-containers/configuration.toml"
+[hypervisor.qemu]
+path = "/opt/kata/bin/qemu-system-x86_64"
 ```
 
-## Choose a Hypervisor
+```toml title="/opt/kata/share/defaults/kata-containers/configuration-clh.toml"
+[hypervisor.clh]
+path = "/opt/kata/bin/cloud-hypervisor"
+```
 
-The table below provides a brief summary of some of the differences between
-the hypervisors:
+## Cloud Hypervisor
 
-| Hypervisor | Summary | Features | Limitations | Container Creation speed | Memory density | Use cases | Comment |
-|-|-|-|-|-|-|-|-|
-|[Cloud Hypervisor] | Low latency, small memory footprint, small attack surface | Minimal | | excellent | excellent | High performance modern cloud workloads | |
-|[Firecracker] | Very slimline | Extremely minimal | Doesn't support all device types | excellent | excellent | Serverless / FaaS | |
-|[QEMU] | Lots of features | Lots | | good | good | Good option for most users | |
-|[`Dragonball`] | Built-in VMM,  low CPU and memory overhead| Minimal | | excellent | excellent | Optimized for most container workloads | `out-of-the-box` Kata Containers experience |
-|[StratoVirt] | Unified architecture supporting three scenarios: VM, container, and serverless | Extremely minimal(`MicroVM`) to Lots(`StandardVM`) | | excellent | excellent | Common container workloads | `StandardVM` type of StratoVirt for Kata is under development |
+[Cloud Hypervisor](https://www.cloudhypervisor.org/) is a more modern hypervisor written in Rust.
 
-For further details, see the [Virtualization in Kata Containers](design/virtualization.md) document and the official documentation for each hypervisor.
+## Firecracker
 
-## Hypervisor configuration files
+[Firecracker](https://firecracker-microvm.github.io/) is a minimal and lightweight hypervisor created for the AWS Lambda product.
 
-Since each hypervisor offers different features and options, Kata Containers
-provides a separate
-[configuration file](../src/runtime/README.md#configuration)
-for each. The configuration files contain comments explaining which options
-are available, their default values and how each setting can be used.
+## QEMU
 
-| Hypervisor | Golang runtime config file | golang runtime short name | golang runtime default | rust runtime config file | rust runtime short name | rust runtime default |
-|-|-|-|-|-|-|-|
-| [Cloud Hypervisor] | [`configuration-clh.toml`](../src/runtime/config/configuration-clh.toml.in) | `clh` | | [`configuration-cloud-hypervisor.toml`](../src/runtime-rs/config/configuration-cloud-hypervisor.toml.in) | `cloud-hypervisor` | |
-| [Firecracker] | [`configuration-fc.toml`](../src/runtime/config/configuration-fc.toml.in) | `fc` | | | | |
-| [QEMU] | [`configuration-qemu.toml`](../src/runtime/config/configuration-qemu.toml.in) | `qemu` | yes | [`configuration-qemu.toml`](../src/runtime-rs/config/configuration-qemu-runtime-rs.toml.in) | `qemu` | |
-| [`Dragonball`] | | | | [`configuration-dragonball.toml`](../src/runtime-rs/config/configuration-dragonball.toml.in) | `dragonball` | yes |
-| [StratoVirt] | [`configuration-stratovirt.toml`](../src/runtime/config/configuration-stratovirt.toml.in) | `stratovirt` | | | | |
+QEMU is the best supported hypervisor for NVIDIA-based GPUs and for confidential computing use-cases (such as Intel TDX and AMD SEV-SNP). Runtimes that use this are normally named `kata-qemu-nvidia-gpu-*`. The Kata project focuses primarily on QEMU runtimes for GPU support.
 
-> **Notes:**
->
-> - The short names specified are used by the [`kata-manager`](../utils/README.md) tool.
-> - As shown by the default columns, each runtime type has its own default hypervisor.
-> - The [golang runtime](../src/runtime) is the current default runtime.
-> - The [rust runtime](../src/runtime-rs), also known as `runtime-rs`,
->   is the newer runtime written in the rust language.
-> - See the [Configuration](../README.md#configuration) for further details.
-> - The configuration file links in the table link to the "source"
->   versions: these are not usable configuration files as they contain
->   variables that need to be expanded:
->   - The links are provided for reference only.
->   - The final (installed) versions, where all variables have been
->     expanded, are built from these source configuration files.
-> - The pristine configuration files are usually installed in the
->   `/opt/kata/share/defaults/kata-containers/` or
->   `/usr/share/defaults/kata-containers/` directories.
-> - Some hypervisors may have the same name for both golang and rust
->   runtimes, but the file contents may differ.
-> - If there is no configuration file listed for the golang or
->   rust runtimes, this either means the hypervisor cannot be run with
->   a particular runtime, or that a driver has not yet been made
->   available for that runtime.
+## Dragonball
 
-## Switch configured hypervisor
-
-To switch the configured hypervisor, you only need to run a single command.
-See [the `kata-manager` documentation](../utils/README.md#choose-a-hypervisor) for further details.
-
-[Cloud Hypervisor]: https://github.com/cloud-hypervisor/cloud-hypervisor
-[Firecracker]: https://github.com/firecracker-microvm/firecracker
-[KVM]: https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
-[QEMU]: http://www.qemu.org
-[`Dragonball`]: https://github.com/kata-containers/kata-containers/blob/main/src/dragonball
-[StratoVirt]: https://gitee.com/openeuler/stratovirt
+Dragonball is a special hypervisor created by the Ant Group that runs in the same process as the Rust-based containerd shim.
diff --git a/docs/index.md b/docs/index.md
new file mode 100644
index 0000000000..ce6b6880f5
--- /dev/null
+++ b/docs/index.md
@@ -0,0 +1,94 @@
+# Kata Containers
+
+Kata Containers is an open source community working to build a secure container runtime with lightweight virtual machines (VM's) that feel and perform like standard Linux containers, but provide stronger workload isolation using hardware virtualization technology as a second layer of defense.
+
+## How it Works
+
+Kata implements the [Open Containers Runtime Specification](https://github.com/opencontainers/runtime-spec). More specifically, it implements a containerd shim that implements the expected interface for managing container lifecycles. The default containerd runtime of `runc` spawns a container like this:
+
+```mermaid
+flowchart TD
+    subgraph Host
+        containerd
+        runc
+        process[Container Process]
+        containerd --> runc --> process
+    end
+```
+
+When containerd receives a request to spawn a container, it will pull the container image down and then call out to the runc shim (usually located at `/usr/local/bin/containerd-shim-runc-v2`). runc will then create various process isolation resources like Linux namespaces (networking, PIDs, mounts etc), seccomp filters, Linux capability reductions, and then spawn the process inside of those resources. This process runs in the host kernel.
+
+Kata spawns containers like this:
+
+```mermaid
+flowchart TD
+    subgraph Host
+        containerdOuter[containerd]
+        kata
+
+        containerdOuter --> kata
+        kata --> kataAgent
+
+        subgraph VM
+            kataAgent[Kata Agent]
+            process[Container Process]
+            kataAgent --> process
+        end
+    end
+```
+
+The container process spawned inside of the VM allows us to isolate the guest kernel from the host system. This is the fundamental principle of how Kata achieves its isolation boundaries.
+
+## Example
+
+When Kata is installed in a system, a number of artifacts are laid down. containerd's config will be modified as such:
+
+```toml title="/etc/containerd/config.toml"
+imports = ["/opt/kata/containerd/config.d/kata-deploy.toml"]
+```
+
+This file will contain configuration for various flavors of Kata runtimes. We can see the vanilla CPU runtime config here:
+
+```toml title="/opt/kata/containerd/config.d/kata-deploy.toml"
+[plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata-qemu]
+runtime_type = "io.containerd.kata-qemu.v2"
+runtime_path = "/opt/kata/bin/containerd-shim-kata-v2"
+privileged_without_host_devices = true
+pod_annotations = ["io.katacontainers.*"]
+
+[plugins."io.containerd.cri.v1.runtime".containerd.runtimes.kata-qemu.options]
+ConfigPath = "/opt/kata/share/defaults/kata-containers/configuration-qemu.toml"
+```
+
+Because containerd's CRI is aware of the Kata runtimes, we can spawn Kubernetes pods:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: test
+spec:
+  runtimeClassName: kata-qemu
+  containers:
+    - name: test
+      image: "quay.io/libpod/ubuntu:latest"
+      command: ["/bin/bash", "-c"]
+      args: ["echo hello"]
+```
+
+We can also spawn a Kata container by submitting a request to containerd like so:
+
+<div class="annotate" markdown>
+
+```sh
+$ ctr image pull quay.io/libpod/ubuntu:latest
+$ ctr run --runtime "io.containerd.kata.v2" --runtime-config-path /opt/kata/share/defaults/kata-containers/configuration-qemu.toml --rm -t "quay.io/libpod/ubuntu:latest" foo sh
+# echo hello
+hello
+```
+
+</div>
+
+!!! tip
+
+    `ctr` is not aware of the CRI config in `/etc/containerd/config.toml`. This is why you must specify the `--runtime-config-path`. Additionally, the `--runtime` value is converted into a specific binary name which containerd then searches for in its `PATH`. See the [containerd docs](https://github.com/containerd/containerd/blob/release/2.2/core/runtime/v2/README.md#usage) for more details.
diff --git a/docs/installation.md b/docs/installation.md
new file mode 100644
index 0000000000..f3d21a3118
--- /dev/null
+++ b/docs/installation.md
@@ -0,0 +1,64 @@
+# Installation
+
+## Helm Chart
+
+[helm](https://helm.sh/docs/intro/install/) can be used to install templated kubernetes manifests.
+
+### Prerequisites
+
+- **Kubernetes ≥ v1.22** – v1.22 is the first release where the CRI v1 API
+  became the default and `RuntimeClass` left alpha.  The chart depends on those
+  stable interfaces; earlier clusters need `feature‑gates` or CRI shims that are
+  out of scope.
+
+- **Kata Release 3.12** - v3.12.0 introduced publishing the helm-chart on the
+  release page for easier consumption, since v3.8.0 we shipped the helm-chart
+  via source code in the kata-containers `GitHub` repository.
+
+- CRI‑compatible runtime (containerd or CRI‑O). If one wants to use the
+  `multiInstallSuffix` feature one needs at least **containerd-2.0** which
+  supports drop-in config files
+
+- Nodes must allow loading kernel modules and installing Kata artifacts (the
+  chart runs privileged containers to do so)
+
+### `helm install`
+
+```sh
+# Install directly from the official ghcr.io OCI registry
+# update the VERSION X.YY.Z to your needs or just use the latest
+
+export VERSION=$(curl -sSL https://api.github.com/repos/kata-containers/kata-containers/releases/latest | jq .tag_name | tr -d '"')
+export CHART="oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy"
+
+$ helm install kata-deploy "${CHART}" --version "${VERSION}"
+
+# See everything you can configure
+$ helm show values "${CHART}" --version "${VERSION}"
+```
+
+This installs the `kata-deploy` DaemonSet and the default Kata `RuntimeClass`
+resources on your cluster.
+
+To see what versions of the chart are available:
+
+```sh
+$ helm show chart oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy
+```
+
+### `helm uninstall`
+
+```sh
+$ helm uninstall kata-deploy -n kube-system
+```
+
+During uninstall, Helm will report that some resources were kept due to the
+resource policy (`ServiceAccount`, `ClusterRole`, `ClusterRoleBinding`). This
+is **normal**. A post-delete hook Job runs after uninstall and removes those
+resources so no cluster-wide `RBAC` is left behind.
+
+## Pre-Built Release
+
+Kata can also be installed using the pre-built releases: https://github.com/kata-containers/kata-containers/releases
+
+This method does not have any facilities for artifact lifecycle management.
diff --git a/docs/prerequisites.md b/docs/prerequisites.md
new file mode 100644
index 0000000000..aeab115c80
--- /dev/null
+++ b/docs/prerequisites.md
@@ -0,0 +1,116 @@
+# Prerequisites
+
+## Kubernetes
+
+If using Kubernetes, at least version `v1.22` is recommended. This is the first release that the CRI v1 API and the `RuntimeClass` left alpha.
+
+## containerd
+
+Kata requires a [CRI](https://kubernetes.io/docs/concepts/containers/cri/)-compatible container runtime. containerd is commonly used for Kata. We recommend installing containerd using your platform's package distribution mechanism. We recommend at least the latest version of containerd v2.1.x.[^1]
+
+
+### Debian/Ubuntu
+
+To install on Debian-based systems:
+
+```sh
+$ apt update
+$ apt install containerd
+$ systemctl status containerd
+● containerd.service - containerd container runtime
+     Loaded: loaded (/etc/systemd/system/containerd.service; enabled; preset: enabled)
+    Drop-In: /etc/systemd/system/containerd.service.d
+             └─http-proxy.conf
+     Active: active (running) since Wed 2026-02-25 22:58:13 UTC; 5 days ago
+       Docs: https://containerd.io
+   Main PID: 3767885 (containerd)
+      Tasks: 540
+     Memory: 70.7G (peak: 70.8G)
+        CPU: 4h 9min 26.153s
+     CGroup: /runtime.slice/containerd.service
+             ├─  12694 /usr/local/bin/container
+```
+
+### Fedora/RedHat
+
+To install on Fedora-based systems:
+
+```
+$ yum install containerd
+```
+
+??? help
+
+    Documentation assistance is requested for more specific instructions on Fedora systems.
+
+### Pre-Built Releases
+
+Many Linux distributions will not package the latest versions of containerd. If you find that your distribution provides very old versions of containerd, it's recommended to upgrade with the [pre-built releases](https://github.com/containerd/containerd/releases).
+
+#### Executable
+
+Download the latest release of containerd:
+
+```sh
+$ wget https://github.com/containerd/containerd/releases/download/v${VERSION}/containerd-${VERSION}-linux-${PLATFORM}.tar.gz
+
+# Extract to the current directory
+$ tar -xf ./containerd*.tar.gz
+
+# Extract to root if you want it installed to its final location.
+$ tar -C / -xf ./*.tar.gz
+```
+
+### Containerd Config
+
+Containerd requires a config file at `/etc/containerd/config.toml`. This needs to be populated with a simple default config:
+
+```sh
+$ /usr/local/bin/containerd config default > /etc/containerd/config.toml
+```
+
+### Systemd Unit File
+
+Install the systemd unit file:
+
+```sh
+$ wget -O /etc/systemd/system/containerd.service https://raw.githubusercontent.com/containerd/containerd/main/containerd.service
+```
+
+!!! info
+
+    - You must modify the `ExecStart` line to the location of the installed containerd executable.
+    - containerd's `PATH` variable must allow it to find `containerd-shim-kata-v2`. You can do this by either creating a symlink from `/usr/local/bin/containerd-shim-kata-v2` to `/opt/kata/bin/containerd-shim-kata-v2` or by modifying containerd's `PATH` variable to search in `/opt/kata/bin/`. See the Environment= command in systemd.exec(5) for further details.
+
+
+Reload systemd and start containerd:
+
+```sh
+$ systemctl daemon-reload
+$ systemctl enable --now containerd
+$ systemctl start containerd
+$ systemctl status containerd
+```
+
+More details can be found on the [containerd installation docs](https://github.com/containerd/containerd/blob/main/docs/getting-started.md).
+
+### Enable CRI
+
+If you're using Kubernetes, you must enable the containerd Container Runtime Interface (CRI) plugin:
+
+```sh
+$ ctr plugins ls | grep cri
+io.containerd.cri.v1                      images                   -              ok
+io.containerd.cri.v1                      runtime                  linux/amd64    ok
+io.containerd.grpc.v1                     cri                      -              ok
+```
+
+If these are not enabled, you'll need to remove it from the `disabled_plugins` section of the containerd config.
+
+
+[^1]: Kata makes use of containerd's drop-in config merging in `/etc/containerd/config.d/` which is only available starting from containerd v2. containerd v1 may work, but some Kata features will not work as expected.
+
+
+## runc
+
+The default `runc` runtime needs to be installed for non-kata containers. More details can be found at the [containerd docs](https://github.com/containerd/containerd/blob/979c80d8a5d7fc7be34102a1ada53ae5a0ff09e8/docs/RUNC.md).
diff --git a/docs/requirements.txt b/docs/requirements.txt
new file mode 100644
index 0000000000..99789469a4
--- /dev/null
+++ b/docs/requirements.txt
@@ -0,0 +1,9 @@
+mkdocs-materialx==10.0.9
+mkdocs-glightbox==0.4.0
+mkdocs-macros-plugin==1.5.0
+mkdocs-awesome-nav==3.3.0
+mkdocs-open-in-new-tab==1.0.8
+mkdocs-redirects==1.2.2
+CairoSVG==2.9.0
+pillow==12.1.1
+click==8.2.1
diff --git a/docs/runtime-configuration.md b/docs/runtime-configuration.md
new file mode 100644
index 0000000000..c19f877c8b
--- /dev/null
+++ b/docs/runtime-configuration.md
@@ -0,0 +1,56 @@
+# Runtime Configuration
+
+The containerd shims (both the Rust and Go implementations) take configuration files to control their behavior. These files are in `/opt/kata/share/defaults/kata-containers/`. An example excerpt:
+
+```toml title="/opt/kata/share/defaults/kata-containers/configuration.toml"
+[hypervisor.qemu]
+path = "/opt/kata/bin/qemu-system-x86_64"
+kernel = "/opt/kata/share/kata-containers/vmlinux.container"
+image = "/opt/kata/share/kata-containers/kata-containers.img"
+machine_type = "q35"
+
+# rootfs filesystem type:
+#   - ext4 (default)
+#   - xfs
+#   - erofs
+rootfs_type = "ext4"
+
+# Enable running QEMU VMM as a non-root user.
+# By default QEMU VMM run as root. When this is set to true, QEMU VMM process runs as
+# a non-root random user. See documentation for the limitations of this mode.
+rootless = false
+
+# List of valid annotation names for the hypervisor
+# Each member of the list is a regular expression, which is the base name
+# of the annotation, e.g. "path" for io.katacontainers.config.hypervisor.path"
+enable_annotations = ["enable_iommu", "virtio_fs_extra_args", "kernel_params"]
+```
+
+These files should never be modified directly. If you wish to create a modified version of these files, you may create your own [custom runtime](helm-configuration.md#custom-runtimes). For example, to modify the image path, we provide these values to helm:
+
+```yaml title="values.yaml"
+customRuntimes:
+  enabled: true
+  runtimes:
+    my-gpu-runtime:
+      baseConfig: "qemu-nvidia-gpu"
+      dropIn: |
+        [hypervisor.qemu]
+        image = "/path/to/custom-image.img"
+      runtimeClass: |
+        kind: RuntimeClass
+        apiVersion: node.k8s.io/v1
+        metadata:
+          name: kata-my-gpu-runtime
+          labels:
+            app.kubernetes.io/managed-by: kata-deploy
+        handler: kata-my-gpu-runtime
+        overhead:
+          podFixed:
+            memory: "640Mi"
+            cpu: "500m"
+        scheduling:
+          nodeSelector:
+            katacontainers.io/kata-runtime: "true"
+```
+
diff --git a/docs/use-cases/NVIDIA-GPU-passthrough-and-Kata-QEMU.md b/docs/use-cases/NVIDIA-GPU-passthrough-and-Kata-QEMU.md
index ad98e66222..bfc7cd8252 100644
--- a/docs/use-cases/NVIDIA-GPU-passthrough-and-Kata-QEMU.md
+++ b/docs/use-cases/NVIDIA-GPU-passthrough-and-Kata-QEMU.md
@@ -1,6 +1,7 @@
 # Enabling NVIDIA GPU workloads using GPU passthrough with Kata Containers
 
 This page provides:
+
 1. A description of the components involved when running GPU workloads with
    Kata Containers using the NVIDIA TEE and non-TEE GPU runtime classes.
 1. An explanation of the orchestration flow on a Kubernetes node for this
diff --git a/mkdocs.yaml b/mkdocs.yaml
new file mode 100644
index 0000000000..fc79fd57ce
--- /dev/null
+++ b/mkdocs.yaml
@@ -0,0 +1,91 @@
+site_name: "Kata Containers Docs"
+site_description: "Developer and user documentation for the Kata Containers project."
+site_author: "Kata Containers Community"
+
+repo_url: "https://github.com/kata-containers/kata-containers"
+site_url: "https://kata-containers.github.io/kata-containers"
+edit_uri: "edit/main/docs/"
+repo_name: kata-containers
+
+theme:
+    name: materialx
+    favicon: "assets/images/favicon.svg"
+    logo: "assets/images/favicon.svg"
+    topbar_style: glass
+    palette:
+      - media: "(prefers-color-scheme)"
+        toggle:
+            icon: material/brightness-auto
+            name: Switch to light mode
+      - media: "(prefers-color-scheme: light)"
+        scheme: default
+        primary: blue
+        accent: light blue
+        toggle:
+            icon: material/weather-sunny
+            name: Switch to dark mode
+      - media: "(prefers-color-scheme: dark)"
+        scheme: slate
+        primary: cyan
+        accent: cyan
+        toggle:
+            icon: material/brightness-4
+            name: Switch to system preference
+    features:
+        - content.action.edit
+        - content.action.view
+        - content.code.annotate
+        - content.code.copy
+        - content.code.select
+        - content.footnote.tooltips
+        - content.tabs.link
+        - content.tooltips
+        - navigation.expand
+        - navigation.indexes
+        - navigation.path
+        - navigation.sections
+        - navigation.tabs
+        - navigation.tracking
+        - navigation.top
+        - navigation.instant
+        - navigation.instant.prefetch
+        - navigation.instant.progress
+        - toc.follow
+markdown_extensions:
+    - abbr
+    - admonition
+    - attr_list
+    - def_list
+    - footnotes
+    - md_in_html
+    - pymdownx.arithmatex:
+        generic: true
+    - pymdownx.emoji:
+        emoji_index: !!python/name:material.extensions.emoji.twemoji
+        emoji_generator: !!python/name:material.extensions.emoji.to_svg
+    - pymdownx.details
+    - pymdownx.highlight:
+        anchor_linenums: true
+        line_spans: __span
+        pygments_lang_class: true
+        auto_title: true
+    - pymdownx.keys
+    - pymdownx.magiclink
+    - pymdownx.superfences:
+        custom_fences:
+            - name: mermaid
+              class: mermaid
+              format: !!python/name:pymdownx.superfences.fence_code_format
+    - pymdownx.inlinehilite
+    - pymdownx.tabbed:
+        alternate_style: true
+    - pymdownx.tilde
+    - pymdownx.caret
+    - pymdownx.mark
+    - toc:
+        permalink: true
+
+plugins:
+    - search
+    - awesome-nav
+
diff --git a/tools/packaging/kata-deploy/helm-chart/README.md b/tools/packaging/kata-deploy/helm-chart/README.md
index 7c04e4ed2b..a348e5b0b6 100644
--- a/tools/packaging/kata-deploy/helm-chart/README.md
+++ b/tools/packaging/kata-deploy/helm-chart/README.md
@@ -1,541 +1,3 @@
 # Kata Containers Deploy – Helm Chart
 
-A Helm chart that installs the kata-deploy DaemonSet and its helper assets,
-enabling Kata Containers runtimes on your Kubernetes, K3s, RKE2, or K0s cluster.
-
-## TL;DR
-
-```sh
-# Install directly from the official ghcr.io OCI regitry
-# update the VERSION X.YY.Z to your needs or just use the latest
-
-export VERSION=$(curl -sSL https://api.github.com/repos/kata-containers/kata-containers/releases/latest | jq .tag_name | tr -d '"')
-export CHART="oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy"
-
-$ helm install kata-deploy "${CHART}" --version "${VERSION}"
-
-# See everything you can configure
-$ helm show values "${CHART}" --version "${VERSION}"
-```
-
-## Prerequisites
-
-- **Kubernetes ≥ v1.22** – v1.22 is the first release where the CRI v1 API
-  became the default and `RuntimeClass` left alpha.  The chart depends on those
-  stable interfaces; earlier clusters need `feature‑gates` or CRI shims that are
-  out of scope.
-
-- **Kata Release 3.12** - v3.12.0 introduced publishing the helm-chart on the
-  release page for easier consumption, since v3.8.0 we shipped the helm-chart
-  via source code in the kata-containers `Github` repository.
-
-- CRI‑compatible runtime (containerd or CRI‑O). If one wants to use the
-  `multiInstallSuffix` feature one needs at least **containerd-2.0** which
-  supports drop-in config files
-
-- Nodes must allow loading kernel modules and installing Kata artifacts (the
-  chart runs privileged containers to do so)
-
-## Installing Helm
-
-If Helm is not yet on your workstation or CI runner, install Helm v3 (v3.9 or
-newer recommended):
-
-```sh
-# Quick one‑liner (Linux/macOS)
-$ curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
-
-# Or via your package manager
-$ sudo apt-get install helm        # Debian/Ubuntu
-$ brew install helm                # Homebrew on macOS / Linuxbrew
-```
-
-Verify the installation:
-
-```sh
-$ helm version
-```
-
-## Installing the Chart
-
-Before attempting installing the chart one may first consult the table below
-[Configuration Reference](#configuration-reference) for all the default values.
-Some default values may not fit all use-cases so update as needed. A prime example
-may be the `k8sDistribution` which per default is set to `k8s`.
-
-To see which chart versions are available either use the CLI
-
-```sh
-$ helm show chart oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy
-```
-
-or visit
-[kata-deploy-charts](https://github.com/orgs/kata-containers/packages/container/package/kata-deploy-charts%2Fkata-deploy)
-
-If one wants to wait until the Helm chart has deployed every object in the chart
-one can use `--wait --timeout 10m --atomic`. If the timeout expires or anything
-fails, Helm rolls the release back to its previous state.
-
-```sh
-$ helm install kata-deploy \        # release name
-  --namespace kube-system \         # recommended namespace
-  --wait --timeout 10m --atomic \
-  "${CHART}" --version  "${VERSION}"
-```
-
-If one does not want to wait for the object via Helm or one wants rather use
-`kubectl` use Helm like this:
-
-```sh
-$ helm install kata-deploy \                         # release name
-  --namespace kube-system \                          # recommended namespace
-  "${CHART}" --version  "${VERSION}"
-```
-
-## Updating Settings
-
-Forgot to enable an option? Re‑use the values already on the cluster and only
-mutate what you need:
-
-```sh
-# List existing releases
-$ helm ls -A
-
-# Upgrade in‑place, keeping everything else the same
-$ helm upgrade kata-deploy -n kube-system \
-  --reuse-values \
-  --set env.defaultShim=qemu-runtime-rs \
-  "${CHART}" --version  "${VERSION}"
-```
-
-## Uninstalling
-
-```sh
-$ helm uninstall kata-deploy -n kube-system
-```
-
-During uninstall, Helm will report that some resources were kept due to the
-resource policy (`ServiceAccount`, `ClusterRole`, `ClusterRoleBinding`). This
-is **normal**. A post-delete hook Job runs after uninstall and removes those
-resources so no cluster-wide `RBAC` is left behind.
-
-## Configuration Reference
-
-All values can be overridden with --set key=value or a custom `-f myvalues.yaml`.
-
-| Key | Description | Default |
-|-----|-------------|---------|
-| `imagePullPolicy` | Set the DaemonSet pull policy | `Always` |
-| `imagePullSecrets` | Enable pulling from a private registry via pull secret | `""` |
-| `image.reference` | Fully qualified image reference (for digest pinning use the full image e.g. `…@sha256:...`; tag is ignored) | `quay.io/kata-containers/kata-deploy` |
-| `image.tag` | Tag of the image reference (defaults to chart `AppVersion` when empty) | `""` |
-| `kubectlImage.reference` | Fully qualified `kubectl` image reference (for digest pinning use the full image e.g. `…@sha256:...` and leave `kubectlImage.tag` empty) | `quay.io/kata-containers/kubectl` |
-| `kubectlImage.tag` | Tag of the `kubectl` image reference | `latest` |
-| `k8sDistribution` | Set the k8s distribution to use: `k8s`, `k0s`, `k3s`, `rke2`, `microk8s` | `k8s` |
-| `nodeSelector` | Node labels for pod assignment. Allows restricting deployment to specific nodes | `{}` |
-| `runtimeClasses.enabled` | Enable Helm-managed `runtimeClass` creation (recommended) | `true` |
-| `runtimeClasses.createDefault` | Create a default `runtimeClass` alias for the default shim | `false` |
-| `runtimeClasses.defaultName` | Name for the default `runtimeClass` | `kata` |
-| `env.debug` | Enable debugging in the `configuration.toml` | `false` |
-| `env.shims` | List of shims to deploy | `clh cloud-hypervisor dragonball fc qemu qemu-coco-dev qemu-coco-dev-runtime-rs qemu-runtime-rs qemu-se-runtime-rs qemu-snp qemu-tdx stratovirt qemu-nvidia-gpu qemu-nvidia-gpu-snp qemu-nvidia-gpu-tdx qemu-cca` |
-| `env.shims_x86_64` | List of shims to deploy for x86_64 (if set, overrides `shims`) | `""` |
-| `env.shims_aarch64` | List of shims to deploy for aarch64 (if set, overrides `shims`) | `""` |
-| `env.shims_s390x` | List of shims to deploy for s390x (if set, overrides `shims`) | `""` |
-| `env.shims_ppc64le` | List of shims to deploy for ppc64le (if set, overrides `shims`) | `""` |
-| `env.defaultShim` | The default shim to use if none specified | `qemu` |
-| `env.defaultShim_x86_64` | The default shim to use if none specified for x86_64 (if set, overrides `defaultShim`) | `""` |
-| `env.defaultShim_aarch64` | The default shim to use if none specified for aarch64 (if set, overrides `defaultShim`) | `""` |
-| `env.defaultShim_s390x` | The default shim to use if none specified for s390x (if set, overrides `defaultShim`) | `""` |
-| `env.defaultShim_ppc64le` | The default shim to use if none specified for ppc64le (if set, overrides `defaultShim`) | `""` |
-| `env.createRuntimeClasses` | **DEPRECATED** - Use `runtimeClasses.enabled` instead. Script-based `runtimeClass` creation | `false` |
-| `env.createDefaultRuntimeClass` | **DEPRECATED** - Use `runtimeClasses.createDefault` instead | `false` |
-| `env.allowedHypervisorAnnotations` | Enable the provided annotations to be enabled when launching a Container or Pod, per default the annotations are disabled | `""` |
-| `env.snapshotterHandlerMapping` | Provide the snapshotter handler for each shim | `""` |
-| `env.snapshotterHandlerMapping_x86_64` | Provide the snapshotter handler for each shim for x86_64 (if set, overrides `snapshotterHandlerMapping`) | `""` |
-| `env.snapshotterHandlerMapping_aarch64` | Provide the snapshotter handler for each shim for aarch64 (if set, overrides `snapshotterHandlerMapping`) | `""` |
-| `env.snapshotterHandlerMapping_s390x` | Provide the snapshotter handler for each shim for s390x (if set, overrides `snapshotterHandlerMapping`) | `""` |
-| `env.snapshotterHandlerMapping_ppc64le` | Provide the snapshotter handler for each shim for ppc64le (if set, overrides `snapshotterHandlerMapping`) | `""` |
-| `evn.agentHttpsProxy` | HTTPS_PROXY=... | `""` |
-| `env.agentHttpProxy` |  specifies a list of addresses that should bypass a configured proxy server | `""` |
-| `env.pullTypeMapping` | Type of container image pulling, examples are guest-pull or default | `""` |
-| `env.pullTypeMapping_x86_64` | Type of container image pulling for x86_64 (if set, overrides `pullTypeMapping`) | `""` |
-| `env.pullTypeMapping_aarch64` | Type of container image pulling for aarch64 (if set, overrides `pullTypeMapping`) | `""` |
-| `env.pullTypeMapping_s390x` | Type of container image pulling for s390x (if set, overrides `pullTypeMapping`) | `""` |
-| `env.pullTypeMapping_ppc64le` | Type of container image pulling for ppc64le (if set, overrides `pullTypeMapping`) | `""` |
-| `env.installationPrefix` | Prefix where to install the Kata artifacts | `/opt/kata` |
-| `env.hostOS` | Provide host-OS setting, e.g. `cbl-mariner` to do additional configurations | `""` |
-| `env.multiInstallSuffix` | Enable multiple Kata installation on the same node with suffix e.g. `/opt/kata-PR12232` | `""` |
-| `env._experimentalSetupSnapshotter` | Deploys (`nydus`) and/or sets up (`erofs`, `nydus`) the snapshotter(s) specified as the value (supports multiple snapshotters, separated by commas; e.g., `nydus,erofs`) | `""` |
-| `env._experimentalForceGuestPull` | Enables `experimental_force_guest_pull` for the shim(s) specified as the value (supports multiple shims, separated by commas; e.g., `qemu-tdx,qemu-snp`) | `""` |
-| `env._experimentalForceGuestPull_x86_64` | Enables `experimental_force_guest_pull` for the shim(s) specified as the value for x86_64 (if set, overrides `_experimentalForceGuestPull`) | `""` |
-| `env._experimentalForceGuestPull_aarch64` | Enables `experimental_force_guest_pull` for the shim(s) specified as the value for aarch64 (if set, overrides `_experimentalForceGuestPull`) | `""` |
-| `env._experimentalForceGuestPull_s390x` | Enables `experimental_force_guest_pull` for the shim(s) specified as the value for s390x (if set, overrides `_experimentalForceGuestPull`) | `""` |
-| `env._experimentalForceGuestPull_ppc64le` | Enables `experimental_force_guest_pull` for the shim(s) specified as the value for ppc64le (if set, overrides `_experimentalForceGuestPull`) | `""` |
-
-## Structured Configuration
-
-**NEW**: Starting with Kata Containers v3.23.0, a new structured configuration format is available for configuring shims. This provides better type safety, clearer organization, and per-shim configuration options.
-
-### Migration from Legacy Format
-
-The legacy `env.*` configuration format is **deprecated** and will be removed in 2 releases. Users are encouraged to migrate to the new structured format.
-
-**Deprecated fields** (will be removed in 2 releases):
-- `env.shims`, `env.shims_x86_64`, `env.shims_aarch64`, `env.shims_s390x`, `env.shims_ppc64le`
-- `env.defaultShim`, `env.defaultShim_x86_64`, `env.defaultShim_aarch64`, `env.defaultShim_s390x`, `env.defaultShim_ppc64le`
-- `env.allowedHypervisorAnnotations`
-- `env.snapshotterHandlerMapping`, `env.snapshotterHandlerMapping_x86_64`, etc.
-- `env.pullTypeMapping`, `env.pullTypeMapping_x86_64`, etc.
-- `env.agentHttpsProxy`, `env.agentNoProxy`
-- `env._experimentalSetupSnapshotter`
-- `env._experimentalForceGuestPull`, `env._experimentalForceGuestPull_x86_64`, etc.
-- `env.debug`
-
-### New Structured Format
-
-The new format uses a `shims` section where each shim can be configured individually:
-
-```yaml
-# Enable debug mode globally
-debug: false
-
-# Configure snapshotter setup
-snapshotter:
-  setup: []  # ["nydus", "erofs"] or []
-
-# Configure shims
-shims:
-  # Disable all shims at once (useful when enabling only specific shims or custom runtimes)
-  disableAll: false
-
-  qemu:
-    enabled: true
-    supportedArches:
-      - amd64
-      - arm64
-      - s390x
-      - ppc64le
-    allowedHypervisorAnnotations: []
-    containerd:
-      snapshotter: ""
-  qemu-snp:
-    enabled: true
-    supportedArches:
-      - amd64
-    allowedHypervisorAnnotations: []
-    containerd:
-      snapshotter: nydus
-      forceGuestPull: false
-    crio:
-      guestPull: true
-    agent:
-      httpsProxy: ""
-      noProxy: ""
-    # Optional: set runtimeClass.nodeSelector to pin TEE to specific nodes (always applied). If unset, NFD TEE labels are auto-injected when NFD is detected.
-
-# Default shim per architecture
-defaultShim:
-  amd64: qemu
-  arm64: qemu
-  s390x: qemu
-  ppc64le: qemu
-```
-
-### Key Benefits
-
-1. **Per-shim configuration**: Each shim can have its own settings for snapshotter, guest pull, agent proxy, etc.
-2. **Architecture-aware**: Shims declare which architectures they support
-3. **Type safety**: Structured format reduces configuration errors
-4. **Easy to use**: All shims are enabled by default in `values.yaml`, so you can use the chart directly without modification
-5. **Disable all at once**: Use `shims.disableAll: true` to disable all standard shims, useful when enabling only specific shims or using custom runtimes only
-
-### Example: Enable `qemu` shim with new format
-
-```yaml
-shims:
-  qemu:
-    enabled: true
-    supportedArches:
-      - amd64
-      - arm64
-
-defaultShim:
-  amd64: qemu
-  arm64: qemu
-```
-
-### Backward Compatibility
-
-The chart maintains full backward compatibility with the legacy `env.*` format. If legacy values are set, they take precedence over the new structured format. This allows for gradual migration.
-
-### Default Configuration
-
-The default `values.yaml` file has **all shims enabled by default**, making it easy to use the chart directly without modification:
-
-```sh
-helm install kata-deploy oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy \
-  --version VERSION
-```
-
-This includes all available Kata Containers shims:
-- Standard shims: `qemu`, `qemu-runtime-rs`, `clh`, `cloud-hypervisor`, `dragonball`, `fc`
-- TEE shims: `qemu-snp`, `qemu-snp-runtime-rs`, `qemu-tdx`, `qemu-tdx-runtime-rs`, `qemu-se`, `qemu-se-runtime-rs`, `qemu-cca`, `qemu-coco-dev`, `qemu-coco-dev-runtime-rs`
-- NVIDIA GPU shims: `qemu-nvidia-gpu`, `qemu-nvidia-gpu-snp`, `qemu-nvidia-gpu-tdx`
-- Remote shims: `remote` (for `peer-pods`/`cloud-api-adaptor`, disabled by default)
-
-To enable only specific shims, you can override the configuration:
-
-```yaml
-# Custom values file - enable only qemu shim
-shims:
-  qemu:
-    enabled: true
-  clh:
-    enabled: false
-  cloud-hypervisor:
-    enabled: false
-  # ... disable other shims as needed
-```
-
-### Example Values Files
-
-For convenience, we also provide example values files that demonstrate specific use cases:
-
-#### `try-kata-tee.values.yaml` - Trusted Execution Environment Shims
-
-This file enables only the TEE (Trusted Execution Environment) shims for confidential computing:
-
-```sh
-helm install kata-deploy oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy \
-  --version VERSION \
-  -f try-kata-tee.values.yaml
-```
-
-Includes:
-- `qemu-snp` - AMD SEV-SNP (amd64)
-- `qemu-tdx` - Intel TDX (amd64)
-- `qemu-se` - IBM Secure Execution for Linux (SEL) (s390x)
-- `qemu-se-runtime-rs` - IBM Secure Execution for Linux (SEL) Rust runtime (s390x)
-- `qemu-cca` - Arm Confidential Compute Architecture (arm64)
-- `qemu-coco-dev` - Confidential Containers development (amd64, s390x)
-- `qemu-coco-dev-runtime-rs` - Confidential Containers development Rust runtime (amd64, s390x)
-
-#### `try-kata-nvidia-gpu.values.yaml` - NVIDIA GPU Shims
-
-This file enables only the NVIDIA GPU-enabled shims:
-
-```sh
-helm install kata-deploy oci://ghcr.io/kata-containers/kata-deploy-charts/kata-deploy \
-  --version VERSION \
-  -f try-kata-nvidia-gpu.values.yaml
-```
-
-Includes:
-- `qemu-nvidia-gpu` - Standard NVIDIA GPU support (amd64, arm64)
-- `qemu-nvidia-gpu-snp` - NVIDIA GPU with AMD SEV-SNP (amd64)
-- `qemu-nvidia-gpu-tdx` - NVIDIA GPU with Intel TDX (amd64)
-
-**Note**: These example files are located in the chart directory. When installing from the OCI registry, you'll need to download them separately or clone the repository to access them.
-
-### RuntimeClass Node Selectors for TEE Shims
-
-**Manual configuration:** Any `nodeSelector` you set under `shims.<shim>.runtimeClass.nodeSelector`
-is **always applied** to that shim's RuntimeClass, whether or not NFD is present. Use this when
-you want to pin TEE workloads to specific nodes (e.g. without NFD, or with custom labels).
-
-**Auto-inject when NFD is present:** If you do *not* set a `runtimeClass.nodeSelector` for a
-TEE shim, the chart can **automatically inject** NFD-based labels when NFD is detected in the
-cluster (deployed by this chart with `node-feature-discovery.enabled=true` or found externally):
-- AMD SEV-SNP shims: `amd.feature.node.kubernetes.io/snp: "true"`
-- Intel TDX shims: `intel.feature.node.kubernetes.io/tdx: "true"`
-- IBM Secure Execution for Linux (SEL) shims (s390x): `feature.node.kubernetes.io/cpu-security.se.enabled: "true"`
-
-The chart uses Helm's `lookup` function to detect NFD (by looking for the
-`node-feature-discovery-worker` DaemonSet). Auto-inject only runs when NFD is detected and
-no manual `runtimeClass.nodeSelector` is set for that shim.
-
-**Note**: NFD detection requires cluster access. During `helm template` (dry-run without a
-cluster), external NFD is not seen, so auto-injected labels are not added. Manual
-`runtimeClass.nodeSelector` values are still applied in all cases.
-
-## `RuntimeClass` Management
-
-**NEW**: Starting with Kata Containers v3.23.0, `runtimeClasses` are managed by
-         Helm by default, providing better lifecycle management and integration.
-
-### Features:
-- **Automatic Creation**: `runtimeClasses` are automatically created for all configured shims
-- **Lifecycle Management**: Helm manages creation, updates, and deletion of `runtimeClasses`
-
-### Configuration:
-```yaml
-runtimeClasses:
-  enabled: true                  # Enable Helm-managed `runtimeClasses` (default)
-  createDefault: false           # Create a default "kata" `runtimeClass`
-  defaultName: "kata"            # Name for the default `runtimeClass`
-```
-
-When `runtimeClasses.enabled: true` (default), the Helm chart creates
-`runtimeClass` resources for all enabled shims (either from the new structured
-`shims` configuration or from the legacy `env.shims` format).
-
-The kata-deploy script will no longer create `runtimeClasses`
-(`env.createRuntimeClasses` defaults to `"false"`).
-
-## Example: only `qemu` shim and debug enabled
-
-Use `shims.disableAll=true` to disable all shims at once, then enable only the ones you need:
-
-```sh
-# Using --set flags (disable all, then enable qemu)
-$ helm install kata-deploy \
-  --set shims.disableAll=true \
-  --set shims.qemu.enabled=true \
-  --set debug=true \
-  "${CHART}" --version  "${VERSION}"
-```
-
-Or use a custom values file:
-
-```yaml
-# custom-values.yaml
-debug: true
-shims:
-  disableAll: true
-  qemu:
-    enabled: true
-```
-
-```sh
-$ helm install kata-deploy \
-  -f custom-values.yaml \
-  "${CHART}" --version  "${VERSION}"
-```
-
-## Example: Deploy only to specific nodes using `nodeSelector`
-
-```sh
-# First, label the nodes where you want kata-containers to be installed
-$ kubectl label nodes worker-node-1 kata-containers=enabled
-$ kubectl label nodes worker-node-2 kata-containers=enabled
-
-# Then install the chart with `nodeSelector`
-$ helm install kata-deploy \
-  --set nodeSelector.kata-containers="enabled" \
-  "${CHART}" --version  "${VERSION}"
-```
-
-You can also use a values file:
-
-```yaml
-# values.yaml
-nodeSelector:
-  kata-containers: "enabled"
-  node-type: "worker"
-```
-
-```sh
-$ helm install kata-deploy -f values.yaml "${CHART}" --version "${VERSION}"
-```
-
-## Example: Multiple Kata installations on the same node
-
-For debugging, testing and other use-case it is possible to deploy multiple
-versions of Kata on the very same node. All the needed artifacts are getting the
-`mulitInstallSuffix` appended to distinguish each installation. **BEWARE** that one
-needs at least **containerd-2.0** since this version has drop-in conf support
-which is a prerequisite for the `mulitInstallSuffix` to work properly.
-
-```sh
-$ helm install kata-deploy-cicd       \
-  -n kata-deploy-cicd                 \
-  --set env.multiInstallSuffix=cicd   \
-  --set env.debug=true                \
-  "${CHART}" --version  "${VERSION}"
-```
-
-Note: `runtimeClasses` are automatically created by Helm (via
-      `runtimeClasses.enabled=true`, which is the default).
-
-Now verify the installation by examining the `runtimeClasses`:
-
-```sh
-$ kubectl get runtimeClasses
-NAME                            HANDLER                         AGE
-kata-clh-cicd                   kata-clh-cicd                   77s
-kata-cloud-hypervisor-cicd      kata-cloud-hypervisor-cicd      77s
-kata-dragonball-cicd            kata-dragonball-cicd            77s
-kata-fc-cicd                    kata-fc-cicd                    77s
-kata-qemu-cicd                  kata-qemu-cicd                  77s
-kata-qemu-coco-dev-cicd         kata-qemu-coco-dev-cicd         77s
-kata-qemu-nvidia-gpu-cicd       kata-qemu-nvidia-gpu-cicd       77s
-kata-qemu-nvidia-gpu-snp-cicd   kata-qemu-nvidia-gpu-snp-cicd   77s
-kata-qemu-nvidia-gpu-tdx-cicd   kata-qemu-nvidia-gpu-tdx-cicd   76s
-kata-qemu-runtime-rs-cicd       kata-qemu-runtime-rs-cicd       77s
-kata-qemu-se-runtime-rs-cicd    kata-qemu-se-runtime-rs-cicd    77s
-kata-qemu-snp-cicd              kata-qemu-snp-cicd              77s
-kata-qemu-tdx-cicd              kata-qemu-tdx-cicd              77s
-kata-stratovirt-cicd            kata-stratovirt-cicd            77s
-```
-
-## Customizing Configuration with Drop-in Files
-
-When kata-deploy installs Kata Containers, the base configuration files should not
-be modified directly. Instead, use drop-in configuration files to customize
-settings. This approach ensures your customizations survive kata-deploy upgrades.
-
-### How Drop-in Files Work
-
-The Kata runtime reads the base configuration file and then applies any `.toml`
-files found in the `config.d/` directory alongside it. Files are processed in
-alphabetical order, with later files overriding earlier settings.
-
-### Creating Custom Drop-in Files
-
-To add custom settings, create a `.toml` file in the appropriate `config.d/`
-directory. Use a numeric prefix to control the order of application.
-
-**Reserved prefixes** (used by kata-deploy):
-- `10-*`: Core kata-deploy settings
-- `20-*`: Debug settings
-- `30-*`: Kernel parameters
-
-**Recommended prefixes for custom settings**: `50-89`
-
-### Example: Adding Custom Kernel Parameters
-
-```bash
-# SSH into the node or use kubectl exec
-sudo mkdir -p /opt/kata/share/defaults/kata-containers/runtimes/qemu/config.d/
-sudo cat > /opt/kata/share/defaults/kata-containers/runtimes/qemu/config.d/50-custom.toml << 'EOF'
-[hypervisor.qemu]
-kernel_params = "my_param=value"
-EOF
-```
-
-### Example: Changing Default Memory Size
-
-```bash
-sudo cat > /opt/kata/share/defaults/kata-containers/runtimes/qemu/config.d/50-memory.toml << 'EOF'
-[hypervisor.qemu]
-default_memory = 4096
-EOF
-```
-
-### Custom Runtimes
-
-For more complex customizations, you can define custom runtimes in your Helm
-values. Custom runtimes create isolated configuration directories with their
-own drop-in files:
-
-```yaml
-customRuntimes:
-  enabled: true
-  runtimes:
-    - handler: kata-custom
-      baseConfig: qemu
-      dropInFile: /path/to/your/config.toml
-```
-
-This creates a new Runtime Class `kata-custom` that extends the `qemu`
-configuration with your custom settings.
+The documentation for the helm chart can be found at https://kata-containers.github.io/kata-containers/installation/#helm-chart.
diff --git a/zensical.toml b/zensical.toml
deleted file mode 100644
index f4e8074c11..0000000000
--- a/zensical.toml
+++ /dev/null
@@ -1,318 +0,0 @@
-[project]
-
-# The site_name is shown in the page header and the browser window title
-#
-# Read more: https://zensical.org/docs/setup/basics/#site_name
-site_name = "Kata Containers Docs"
-
-# The site_description is included in the HTML head and should contain a
-# meaningful description of the site content for use by search engines.
-#
-# Read more: https://zensical.org/docs/setup/basics/#site_description
-site_description = "Developer and user documentation for the Kata Containers project."
-
-# The site_author attribute. This is used in the HTML head element.
-#
-# Read more: https://zensical.org/docs/setup/basics/#site_author
-site_author = "Kata Containers Community"
-
-repo_url = "https://github.com/kata-containers/kata-containers"
-
-# The site_url is the canonical URL for your site. When building online
-# documentation you should set this.
-# Read more: https://zensical.org/docs/setup/basics/#site_url
-site_url = "https://kata-containers.github.io/kata-containers"
-
-edit_uri = "edit/main/docs/"
-
-# The copyright notice appears in the page footer and can contain an HTML
-# fragment.
-#
-# Read more: https://zensical.org/docs/setup/basics/#copyright
-copyright = """
-Copyright &copy; 2026 Kata Containers
-"""
-
-# Zensical supports both implicit navigation and explicitly defined navigation.
-# If you decide not to define a navigation here then Zensical will simply
-# derive the navigation structure from the directory structure of your
-# "docs_dir". The definition below demonstrates how a navigation structure
-# can be defined using TOML syntax.
-#
-# Read more: https://zensical.org/docs/setup/navigation/
-# nav = [
-#   { "Get started" = "index.md" },
-#   { "Markdown in 5min" = "markdown.md" },
-# ]
-
-# With the "extra_css" option you can add your own CSS styling to customize
-# your Zensical project according to your needs. You can add any number of
-# CSS files.
-#
-# The path provided should be relative to the "docs_dir".
-#
-# Read more: https://zensical.org/docs/customization/#additional-css
-#
-#extra_css = ["stylesheets/extra.css"]
-
-# With the `extra_javascript` option you can add your own JavaScript to your
-# project to customize the behavior according to your needs.
-#
-# The path provided should be relative to the "docs_dir".
-#
-# Read more: https://zensical.org/docs/customization/#additional-javascript
-#extra_javascript = ["javascripts/extra.js"]
-
-# ----------------------------------------------------------------------------
-# Section for configuring theme options
-# ----------------------------------------------------------------------------
-[project.theme]
-
-# change this to "classic" to use the traditional Material for MkDocs look.
-#variant = "classic"
-
-# Zensical allows you to override specific blocks, partials, or whole
-# templates as well as to define your own templates. To do this, uncomment
-# the custom_dir setting below and set it to a directory in which you
-# keep your template overrides.
-#
-# Read more:
-# - https://zensical.org/docs/customization/#extending-the-theme
-#
-#custom_dir = "overrides"
-
-# With the "favicon" option you can set your own image to use as the icon
-# browsers will use in the browser title bar or tab bar. The path provided
-# must be relative to the "docs_dir".
-#
-# Read more:
-# - https://zensical.org/docs/setup/logo-and-icons/#favicon
-# - https://developer.mozilla.org/en-US/docs/Glossary/Favicon
-#
-favicon = "assets/favicon.svg"
-logo = "assets/favicon.svg"
-
-# Zensical supports more than 60 different languages. This means that the
-# labels and tooltips that Zensical's templates produce are translated.
-# The "language" option allows you to set the language used. This language
-# is also indicated in the HTML head element to help with accessibility
-# and guide search engines and translation tools.
-#
-# The default language is "en" (English). It is possible to create
-# sites with multiple languages and configure a language selector. See
-# the documentation for details.
-#
-# Read more:
-# - https://zensical.org/docs/setup/language/
-#
-language = "en"
-
-# Zensical provides a number of feature toggles that change the behavior
-# of the documentation site.
-features = [
-    # Zensical includes an announcement bar. This feature allows users to
-    # dismiss it then they have read the announcement.
-    # https://zensical.org/docs/setup/header/#announcement-bar
-    "announce.dismiss",
-
-    # If you have a repository configured and turn feature this on, Zensical
-    # will generate an edit button for the page. This works for common
-    # repository hosting services.
-    # https://zensical.org/docs/setup/repository/#code-actions
-    "content.action.edit",
-
-    # If you have a repository configured and turn feature this on, Zensical
-    # will generate a button that allows the user to view the Markdown
-    # code for the current page.
-    # https://zensical.org/docs/setup/repository/#code-actions
-    "content.action.view",
-
-    # Code annotations allow you to add an icon with a tooltip to your
-    # code blocks to provide explanations at crucial points.
-    # https://zensical.org/docs/authoring/code-blocks/#code-annotations
-    "content.code.annotate",
-
-    # This feature turns on a button in code blocks that allow users to
-    # copy the content to their clipboard without first selecting it.
-    # https://zensical.org/docs/authoring/code-blocks/#code-copy-button
-    "content.code.copy",
-
-    # Code blocks can include a button to allow for the selection of line
-    # ranges by the user.
-    # https://zensical.org/docs/authoring/code-blocks/#code-selection-button
-    "content.code.select",
-
-    # Zensical can render footnotes as inline tooltips, so the user can read
-    # the footnote without leaving the context of the document.
-    # https://zensical.org/docs/authoring/footnotes/#footnote-tooltips
-    "content.footnote.tooltips",
-
-    # If you have many content tabs that have the same titles (e.g., "Python",
-    # "JavaScript", "Cobol"), this feature causes all of them to switch to
-    # at the same time when the user chooses their language in one.
-    # https://zensical.org/docs/authoring/content-tabs/#linked-content-tabs
-    "content.tabs.link",
-
-    # TODO: not sure I understand this one? Is there a demo of this in the docs?
-    # https://zensical.org/docs/authoring/tooltips/#improved-tooltips
-    "content.tooltips",
-
-    # With this feature enabled, Zensical will automatically hide parts
-    # of the header when the user scrolls past a certain point.
-    # https://zensical.org/docs/setup/header/#automatic-hiding
-    # "header.autohide",
-
-    # Turn on this feature to expand all collapsible sections in the
-    # navigation sidebar by default.
-    # https://zensical.org/docs/setup/navigation/#navigation-expansion
-    # "navigation.expand",
-
-    # This feature turns on navigation elements in the footer that allow the
-    # user to navigate to a next or previous page.
-    # https://zensical.org/docs/setup/footer/#navigation
-    "navigation.footer",
-
-    # When section index pages are enabled, documents can be directly attached
-    # to sections, which is particularly useful for providing overview pages.
-    # https://zensical.org/docs/setup/navigation/#section-index-pages
-    "navigation.indexes",
-
-    # When instant navigation is enabled, clicks on all internal links will be
-    # intercepted and dispatched via XHR without fully reloading the page.
-    # https://zensical.org/docs/setup/navigation/#instant-navigation
-    "navigation.instant",
-
-    # With instant prefetching, your site will start to fetch a page once the
-    # user hovers over a link. This will reduce the perceived loading time
-    # for the user.
-    # https://zensical.org/docs/setup/navigation/#instant-prefetching
-    "navigation.instant.prefetch",
-
-    # In order to provide a better user experience on slow connections when
-    # using instant navigation, a progress indicator can be enabled.
-    # https://zensical.org/docs/setup/navigation/#progress-indicator
-    #"navigation.instant.progress",
-
-    # When navigation paths are activated, a breadcrumb navigation is rendered
-    # above the title of each page
-    # https://zensical.org/docs/setup/navigation/#navigation-path
-    "navigation.path",
-
-    # When pruning is enabled, only the visible navigation items are included
-    # in the rendered HTML, reducing the size of the built site by 33% or more.
-    # https://zensical.org/docs/setup/navigation/#navigation-pruning
-    #"navigation.prune",
-
-    # When sections are enabled, top-level sections are rendered as groups in
-    # the sidebar for viewports above 1220px, but remain as-is on mobile.
-    # https://zensical.org/docs/setup/navigation/#navigation-sections
-    "navigation.sections",
-
-    # When tabs are enabled, top-level sections are rendered in a menu layer
-    # below the header for viewports above 1220px, but remain as-is on mobile.
-    # https://zensical.org/docs/setup/navigation/#navigation-tabs
-    #"navigation.tabs",
-
-    # When sticky tabs are enabled, navigation tabs will lock below the header
-    # and always remain visible when scrolling down.
-    # https://zensical.org/docs/setup/navigation/#sticky-navigation-tabs
-    #"navigation.tabs.sticky",
-
-    # A back-to-top button can be shown when the user, after scrolling down,
-    # starts to scroll up again.
-    # https://zensical.org/docs/setup/navigation/#back-to-top-button
-    "navigation.top",
-
-    # When anchor tracking is enabled, the URL in the address bar is
-    # automatically updated with the active anchor as highlighted in the table
-    # of contents.
-    # https://zensical.org/docs/setup/navigation/#anchor-tracking
-    "navigation.tracking",
-
-    # When search highlighting is enabled and a user clicks on a search result,
-    # Zensical will highlight all occurrences after following the link.
-    # https://zensical.org/docs/setup/search/#search-highlighting
-    "search.highlight",
-
-    # When anchor following for the table of contents is enabled, the sidebar
-    # is automatically scrolled so that the active anchor is always visible.
-    # https://zensical.org/docs/setup/navigation/#anchor-following
-    "toc.follow",
-
-    # When navigation integration for the table of contents is enabled, it is
-    # always rendered as part of the navigation sidebar on the left.
-    # https://zensical.org/docs/setup/navigation/#navigation-integration
-    #"toc.integrate",
-]
-
-# ----------------------------------------------------------------------------
-# In the "palette" subsection you can configure options for the color scheme.
-# You can configure different color # schemes, e.g., to turn on dark mode,
-# that the user can switch between. Each color scheme can be further
-# customized.
-#
-# Read more:
-# - https://zensical.org/docs/setup/colors/
-# ----------------------------------------------------------------------------
-[[project.theme.palette]]
-scheme = "slate"
-toggle.icon = "lucide/moon"
-toggle.name = "Switch to light mode"
-primary = "indigo"
-accent = "orange"
-
-[[project.theme.palette]]
-scheme = "default"
-toggle.icon = "lucide/sun"
-toggle.name = "Switch to dark mode"
-primary = "indigo"
-accent = "orange"
-
-# ----------------------------------------------------------------------------
-# In the "font" subsection you can configure the fonts used. By default, fonts
-# are loaded from Google Fonts, giving you a wide range of choices from a set
-# of suitably licensed fonts. There are options for a normal text font and for
-# a monospaced font used in code blocks.
-# ----------------------------------------------------------------------------
-#[project.theme.font]
-#text = "Inter"
-#code = "Jetbrains Mono"
-
-# ----------------------------------------------------------------------------
-# You can configure your own logo to be shown in the header using the "logo"
-# option in the "icons" subsection. The logo can be a path to a file in your
-# "docs_dir" or it can be a path to an icon.
-#
-# Likewise, you can customize the logo used for the repository section of the
-# header. Zensical derives the default logo for this from the repository URL.
-# See below...
-#
-# There are other icons you can customize. See the documentation for details.
-#
-# Read more:
-# - https://zensical.org/docs/setup/logo-and-icons
-# - https://zensical.org/docs/authoring/icons-emojis/#search
-# ----------------------------------------------------------------------------
-[project.theme.icon]
-#logo = "./images/logo.png"
-#repo = "lucide/smile"
-
-# ----------------------------------------------------------------------------
-# The "extra" section contains miscellaneous settings.
-# ----------------------------------------------------------------------------
-#[[project.extra.social]]
-#icon = "fontawesome/brands/github"
-#link = "https://github.com/user/repo"
-
-
-[project.markdown_extensions.toc]
-permalink =  true
-
-[project.markdown_extensions.admonition]
-[project.markdown_extensions.pymdownx.highlight]
-anchor_linenums = true
-line_spans = "__span"
-pygments_lang_class = true
-[project.markdown_extensions.pymdownx.inlinehilite]
-[project.markdown_extensions.pymdownx.snippets]
-[project.markdown_extensions.pymdownx.superfences]