NOISSUE - Update SEO

.github/workflows/cd.yaml

@@ -23,20 +23,31 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v4
-
-      - uses: oven-sh/setup-bun@v2
         with:
-          bun-version: latest
+          fetch-depth: 0
+
+      - uses: pnpm/action-setup@v4
 
       - name: Install dependencies
-        run: bun install
+        run: pnpm install --frozen-lockfile
 
       - name: Setup Pages
         id: setup_pages
         uses: actions/configure-pages@v5
 
+      - name: Create IndexNow key file
+        env:
+          INDEXNOW_KEY: ${{ secrets.INDEXNOW_KEY }}
+        run: |
+          if [ -z "$INDEXNOW_KEY" ]; then
+            echo "INDEXNOW_KEY is not set; skipping key file generation."
+            exit 0
+          fi
+
+          printf '%s' "$INDEXNOW_KEY" > "public/${INDEXNOW_KEY}.txt"
+
       - name: Build with Next.js
-        run: bun run build
+        run: pnpm run build
         env:
           PAGES_BASE_PATH: ${{ steps.setup_pages.outputs.base_path }}
 
@@ -58,3 +69,19 @@ jobs:
       - name: Deploy to GitHub Pages
         id: deployment
         uses: actions/deploy-pages@v4
+
+  indexnow:
+    runs-on: ubuntu-latest
+    needs: deploy
+    if: github.ref == 'refs/heads/main'
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - uses: pnpm/action-setup@v4
+
+      - name: Submit URLs to IndexNow
+        run: node scripts/indexnow.mjs
+        env:
+          INDEXNOW_KEY: ${{ secrets.INDEXNOW_KEY }}

.github/workflows/ci.yaml

@@ -18,19 +18,19 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v4
-
-      - uses: oven-sh/setup-bun@v2
         with:
-          bun-version: latest
+          fetch-depth: 0
+
+      - uses: pnpm/action-setup@v4
 
       - name: Install Dependencies
-        run: bun install
+        run: pnpm install --frozen-lockfile
 
       - name: Check asset optimisation
-        run: bun run check:assets
+        run: pnpm run check:assets
 
       - name: Run Lint
-        run: bun run lint
+        run: pnpm run lint
 
       - name: Run Build
-        run: bun run build
+        run: pnpm run build

.npmrc

@@ -0,0 +1 @@
+shamefully-hoist=true

README.md

@@ -15,20 +15,21 @@ Propeller Website is a documentation website built with [Next.js](https://nextjs
 
 ### Prerequisites
 
-- [Bun](https://bun.com/) (recommended) or Node.js
+- [Node.js](https://nodejs.org/) v20+
+- [pnpm](https://pnpm.io/) v9+
 
 ### Installation
 
 ```bash
-bun install
+pnpm install
 ```
 
 ### Development
 
 Run the development server:
 
 ```bash
-bun run dev
+pnpm run dev
 ```
 
 Open <http://localhost:3000> with your browser to see the result.
@@ -38,24 +39,24 @@ Open <http://localhost:3000> with your browser to see the result.
 Build the static site:
 
 ```bash
-bun run build
+pnpm run build
 ```
 
 The output will be generated in the `out` directory.
 
 ### Preview Production Build
 
 ```bash
-bun run start
+pnpm run start
 ```
 
 ### Linting
 
 ```bash
-bun run lint
-bun run lint:fix  # Auto-fix issues
+pnpm run lint
+pnpm run lint:fix  # Auto-fix issues
 ```
 
 ## Deployment
 
-The site is configured for static export and can be deployed to GitHub Pages (via [`.github/workflows/cd.yml`](.github/workflows/cd.yml)) or any other static hosting provider.
+The site is configured for static export and can be deployed to GitHub Pages (via [`.github/workflows/cd.yaml`](.github/workflows/cd.yaml)) or any other static hosting provider.

biome.json

@@ -36,6 +36,18 @@
       "react": "recommended"
     }
   },
+  "overrides": [
+    {
+      "includes": ["src/app/(home)/page.tsx", "src/app/docs/**/page.tsx"],
+      "linter": {
+        "rules": {
+          "security": {
+            "noDangerouslySetInnerHtml": "off"
+          }
+        }
+      }
+    }
+  ],
   "assist": {
     "actions": {
       "source": {

content/docs/api/index.mdx

@@ -1,6 +1,6 @@
 ---
 title: API Reference
-description: API Reference for Propeller
+description: "REST API reference for the Propeller WebAssembly orchestrator. Manage tasks, jobs, proplets, DAG workflows, and federated learning experiments via the Manager REST API."
 ---
 
 The Propeller Manager exposes a REST API for managing distributed workloads. Download the [Postman collection](../postman_collection.json) to explore the API interactively.

content/docs/architecture.mdx

@@ -1,6 +1,6 @@
 ---
 title: System Architecture
-description: Overview of the Propeller distributed computing platform architecture and its components
+description: "Explore Propeller's Cloud-Edge architecture: Manager, Proplet and Proxy. Learn how Wasm workloads are orchestrated across distributed nodes via MQTT."
 ---
 
 ## Overview

content/docs/coco-k8s-setup.mdx

@@ -1,6 +1,6 @@
 ---
 title: K8s single node setup for CoCo
-description: How to setup a single node k8s cluster using kubeadm and containerd on a Linux machine for testing and developing with confidentail containers.
+description: "Set up a single-node Kubernetes cluster with kubeadm and containerd for testing Propeller's Confidential Container (CoCo) workloads. Uses kubeadm on a single Linux machine as both control-plane and worker."
 ---
 
 This tutorial sets up a **single machine** as both **control-plane + worker**, using **kubeadm** (the standard Kubernetes bootstrapping tool) and **containerd** (recommended runtime). It’s the closest thing to a “real” DIY cluster you’ll run on one box.

content/docs/developer-guide.mdx

@@ -1,6 +1,6 @@
 ---
 title: Developer's Guide
-description: Guide for building and contributing to Propeller
+description: "Contribute to Propeller by Abstract Machines. Covers forking the Go/Rust codebase, building all components, running tests, and submitting pull requests to the open-source repo."
 ---
 
 ## Getting Propeller

content/docs/embedded-proplet.mdx

@@ -1,6 +1,6 @@
 ---
 title: Embedded Proplet
-description: WebAssembly runtime for microcontroller-based edge devices using Zephyr RTOS and WAMR
+description: "Run WebAssembly on microcontrollers with Propeller's Embedded Proplet. Executes Wasm workloads on ESP32-S3 and Zephyr RTOS devices using WAMR — with as little as 128 KB RAM."
 ---
 
 The Embedded Proplet brings WebAssembly execution to microcontrollers like the ESP32-S3. It is a C firmware application running on Zephyr RTOS that connects to a Propeller [Manager](/docs/manager) over MQTT and executes WebAssembly tasks using the WebAssembly Micro Runtime (WAMR). When the Manager sends a task, the Embedded Proplet decodes the WASM module, runs it locally on the device, and reports results back — enabling computation at the true edge with as little as 128 KB RAM.

content/docs/getting-started.mdx

@@ -1,6 +1,6 @@
 ---
 title: Getting Started
-description: Installation and setup guide for Propeller WebAssembly orchestrator
+description: "Install and deploy Propeller, the open-source WebAssembly orchestrator. Step-by-step setup for Go, Rust, Docker, and Wasmtime — from clone to first Wasm workload deployment."
 ---
 
 Before proceeding, install the following prerequisites:

content/docs/hal.mdx

@@ -1,6 +1,6 @@
 ---
 title: HAL
-description: Build and run Ubuntu CVMs with proplet pre-installed via QEMU.
+description: "Build and run Ubuntu Confidential VMs with Propeller's Proplet pre-installed via QEMU. Automates full Propeller service setup inside a cloud-init VM on first boot."
 ---
 
 The Hardware Abstraction Layer (HAL) provides a single script — [hal/ubuntu/qemu.sh](https://github.com/absmach/propeller/blob/main/hal/ubuntu/qemu.sh) — that builds an Ubuntu Noble cloud image and boots it as a QEMU virtual machine. On first boot, cloud-init compiles and installs all Propeller services inside the VM automatically.

content/docs/index.mdx

@@ -1,6 +1,6 @@
 ---
-title: Propeller
-description: Orchestrate and manage WebAssembly workloads across the cloud, edge, and IoT devices.
+title: Propeller by Abstract Machines
+description: "Propeller by Abstract Machines — open-source WebAssembly orchestrator for Cloud-Edge computing. Manage Wasm workloads across cloud servers, edge nodes, and microcontrollers."
 ---
 
 [**Propeller**](https://propeller.absmach.eu) is a cutting-edge orchestrator for **WebAssembly (Wasm)** workloads across the **Cloud-Edge continuum**. It enables seamless deployment of Wasm applications from powerful cloud servers to constrained microcontrollers, combining flexibility, security, and performance.

content/docs/manager.mdx

@@ -1,6 +1,6 @@
 ---
 title: Manager
-description: Central service for task management and proplet coordination in Propeller
+description: "Propeller's Manager is the Go-based orchestration engine that schedules Wasm tasks, coordinates distributed proplets, and manages workload lifecycle across Cloud-Edge nodes."
 ---
 
 The Manager is Propeller's central orchestration service. It coordinates the complete lifecycle of WebAssembly workloads across distributed proplets—from task creation and scheduling through execution tracking and result collection.

content/docs/meta.json

@@ -21,6 +21,8 @@
     "api",
     "developer-guide.mdx",
     "zephyr.mdx",
-    "coco-k8s-setup.mdx"
+    "coco-k8s-setup.mdx",
+    "vs-kubeedge.mdx",
+    "changelog.mdx"
   ]
 }

content/docs/monitoring.mdx

@@ -1,6 +1,6 @@
 ---
 title: Monitoring
-description: Real-time monitoring and metrics collection for WebAssembly tasks
+description: "Monitor CPU, memory, disk I/O, and thread metrics for WebAssembly tasks on Propeller proplets. OS-level data collected via MQTT and aggregated through the Manager REST API."
 ---
 
 ## Overview

content/docs/proplet.mdx

@@ -1,6 +1,6 @@
 ---
 title: Proplet
-description: WebAssembly execution runtime for edge devices in the Propeller system
+description: "Propeller's Proplet is the Rust-based edge runtime. It receives Wasm tasks from the Manager via MQTT, executes them inside a sandboxed Wasmtime runtime, and publishes results."
 ---
 
 The Proplet is Propeller's edge execution runtime. It receives task commands from the Manager over MQTT, fetches WebAssembly binaries, executes them using an embedded or external Wasmtime runtime, and publishes results back over MQTT.

content/docs/proxy.mdx

@@ -1,6 +1,6 @@
 ---
 title: Proxy Service
-description: Service for fetching and distributing WebAssembly modules from OCI registries
+description: "Propeller's Proxy fetches Wasm modules from OCI registries and distributes them to edge proplets over MQTT — centralising registry access without exposing credentials to devices."
 ---
 
 When you want to run WebAssembly modules stored in a container registry like Docker Hub, the Proxy handles everything between the registry and your edge devices. Instead of embedding binaries in your task definitions or manually uploading files, you simply reference an image URL, and the Proxy fetches, chunks, and delivers the module to whichever Proplet needs it.

content/docs/task-scheduling.mdx

@@ -1,6 +1,6 @@
 ---
 title: Task Scheduling & Workflows
-description: Configure task dependencies, DAG-based workflows, jobs, and scheduling in Propeller
+description: "Schedule WebAssembly tasks across edge nodes with Propeller. Configure DAG-based dependencies, parallel and sequential jobs, and fail-fast workflows for distributed Wasm execution."
 ---
 
 ## Overview

content/docs/tee.mdx

@@ -1,6 +1,6 @@
 ---
 title: Encrypted workloads
-description: Run WebAssembly workloads inside hardware-protected environments.
+description: "Run WebAssembly workloads inside hardware-protected Trusted Execution Environments. Supports Intel TDX, AMD SEV-SNP, and Intel SGX for confidential Cloud-Edge computing with Propeller."
 ---
 
 A [Trusted Execution Environment](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) is a secure area inside a processor that protects code and data from unauthorized access. TEEs use hardware-based isolation to ensure that even cloud providers or system administrators cannot read your workload's data while it runs.

content/docs/vs-kubeedge.mdx

@@ -0,0 +1,58 @@
+---
+title: Propeller vs KubeEdge
+description: "Propeller vs KubeEdge: a technical comparison of WebAssembly orchestration vs Kubernetes-based edge computing. Runtime model, device support, protocols, and use-case fit."
+---
+
+Propeller and KubeEdge both address edge compute orchestration, but they solve different problems with different trade-offs. This page compares them on the dimensions that matter most for infrastructure decisions.
+
+## Quick Comparison
+
+| | **Propeller** | **KubeEdge** |
+|---|---|---|
+| **Workload runtime** | WebAssembly (Wasmtime, WAMR) | Containers (containerd, Docker) |
+| **Control plane** | Propeller Manager (Go REST API) | Kubernetes API server + EdgeCore |
+| **Minimum device RAM** | 128 KB (Zephyr RTOS) | ~256 MB (Linux required) |
+| **OS requirement** | Linux, Zephyr RTOS | Linux only |
+| **Cold-start** | < 1 ms (Wasm) | ~180–250 ms (container) |
+| **Communication protocol** | MQTT, CoAP, WebSocket | WebSocket (EdgeHub) |
+| **Sandbox model** | Wasm linear memory isolation | Linux namespace + cgroup |
+| **Kubernetes dependency** | None | Required |
+| **License** | Apache 2.0 | Apache 2.0 |
+| **Governance** | Abstract Machines (EU-funded) | CNCF Incubating |
+
+## Runtime Model
+
+**KubeEdge** extends Kubernetes to edge nodes. Each edge node runs `EdgeCore`, a lightweight Kubernetes node agent that manages container lifecycle via containerd or Docker. Workloads are standard OCI container images. This means any existing Kubernetes workload can be moved to the edge without rewriting, but the minimum viable edge device must run a full Linux environment with containerd installed — typically 256 MB RAM minimum in practice.
+
+**Propeller** uses WebAssembly as the workload format. Wasm binaries are architecture-neutral: the same `.wasm` file runs on x86_64, ARM64, and the Xtensa LX7 core of an ESP32-S3 microcontroller. This single-binary portability is not possible with OCI containers, which are architecture-specific. The trade-off is that applications must be compiled to Wasm — existing container workloads cannot be moved to Propeller without recompilation.
+
+## Device Reach
+
+KubeEdge's architecture stops at the Linux boundary. Any device that cannot run a Linux kernel with containerd is outside its scope.
+
+Propeller extends below Linux to bare-metal microcontrollers. The Embedded Proplet firmware runs on Zephyr RTOS devices using WAMR's interpreter or AOT mode, enabling Wasm workload deployment to devices with 128 KB of RAM — the class of hardware used in industrial sensors, actuators, and environmental monitors that make up the majority of IoT endpoint count.
+
+## Security Model
+
+KubeEdge inherits the Kubernetes security model: namespaces, RBAC, network policies, and optional Pod Security Admission. Container isolation is enforced by Linux namespaces and cgroups. A kernel vulnerability can potentially escape the sandbox.
+
+Propeller's sandbox is the WebAssembly execution model itself. Wasm modules operate in a linear memory region with no access to host memory or syscalls beyond the explicit WASI imports granted at instantiation. This makes the sandbox boundary a language-level guarantee rather than a kernel-level enforcement, which is particularly relevant for Trusted Execution Environment (TEE) deployments.
+
+## When to Choose Each
+
+**Choose KubeEdge if:**
+- You have existing Kubernetes workloads to move to the edge
+- Your edge devices run Linux with at least 512 MB RAM
+- Your team has existing Kubernetes operational expertise
+- Container-based packaging is a hard requirement
+
+**Choose Propeller if:**
+- You need to deploy to microcontrollers (< 1 MB RAM)
+- Cold-start latency below 5 ms is a requirement
+- You need a single binary to run across x86, ARM, and embedded targets
+- You require hardware-level sandbox guarantees (TEE support)
+- You are starting fresh without an existing Kubernetes investment
+
+## Summary
+
+KubeEdge is the right choice when Kubernetes compatibility and container ecosystem reuse are the primary goals and edge devices are Linux-capable. Propeller is the right choice when the workload needs to reach below the Linux boundary, when cold-start performance matters at the millisecond scale, or when WebAssembly's portability and sandbox guarantees are architectural requirements. The two tools are complementary: Propeller can run alongside a Kubernetes cluster, handling the sub-Linux tier while KubeEdge handles the Linux edge tier.

content/docs/wasi-nn.mdx

@@ -1,6 +1,6 @@
 ---
 title: WASI-NN
-description: Run machine learning inference in WebAssembly using WASI-NN with Propeller
+description: "Run ML inference inside WebAssembly with Propeller's WASI-NN support. Execute neural network models at the edge using Wasmtime's WASI-NN implementation — no GPU required."
 ---
 
 **WASI-NN** (WebAssembly System Interface for Neural Networks) is a standard API that enables WebAssembly modules to perform machine learning inference. Propeller supports WASI-NN through Wasmtime's built-in implementation, allowing you to run ML models directly within your Wasm workloads.

content/docs/zephyr.mdx

@@ -1,6 +1,6 @@
 ---
 title: Deploying WAMR on Zephyr
-description: Step-by-step guide for deploying WebAssembly on Zephyr RTOS for ESP32
+description: "Step-by-step guide to deploying WebAssembly on Zephyr RTOS for the ESP32. Configure WAMR, build the Embedded Proplet firmware, and run Wasm workloads on constrained IoT hardware."
 ---
 
 ## **1. Set Up Zephyr Development Environment**

package.json

@@ -22,7 +22,7 @@
     "embla-carousel-react": "^8.6.0",
     "fumadocs-core": "16.6.8",
     "fumadocs-mdx": "14.2.9",
-    "fumadocs-openapi": "^10.3.14",
+    "fumadocs-openapi": "10.3.14",
     "fumadocs-ui": "16.6.8",
     "lucide-react": "^0.576.0",
     "motion": "^12.34.3",
@@ -48,5 +48,6 @@
     "tailwindcss": "^4.2.1",
     "tw-animate-css": "^1.4.0",
     "typescript": "^5.9.3"
-  }
+  },
+  "packageManager": "[email protected]"
 }