Platform Support and Launch Claims

This page lists NemoClaw’s platform support. Any documentation, demo, blog post, sales conversation, or support reply that describes a NemoClaw capability should match the entries below.

The tables on this page are generated from ci/platform-matrix.json. Update the JSON so the tables and partial views on other pages stay in sync with scripts/generate-platform-docs.py.

Status Vocabulary

Status	Meaning
Tested	Validated by CI or QA. Safe to claim and to demo.
Tested with limitations	Works on the listed setup with documented caveats. Caveats must be cited whenever this row is claimed.
Experimental	Available only after an explicit experimental opt-in, such as `NEMOCLAW_EXPERIMENTAL=1` or selecting an integration that the CLI labels experimental. Do not claim in launch-facing material without the opt-in mentioned.
Deferred	Planned but not yet validated. Roadmap-only. Do not claim as supported.
Unsupported	Explicitly out of scope. Not validated and not planned. Documented to set expectations and prevent drift.
Hermes only	Available only when onboarding the Hermes agent.

Project Status

For version highlights, refer to Release Notes.

Stage: alpha
Label: Early preview
Since: 2026-03-16
Notes: Maintainers review issues, discussions, and PRs on a best-effort basis without guaranteed response timelines.

Owners

Engineering owner: @NVIDIA/nemoclaw-maintainer (reviews through CODEOWNERS and signs off on launch-facing claim changes before they reach demos or sales material).

The engineering owner is the GitHub team auto-assigned to review changes to ci/platform-matrix.json through CODEOWNERS, and the same team signs off on launch-facing claim changes before they reach demos, blog posts, or sales material.

Review Process

A change to a status or note opens a PR that touches ci/platform-matrix.json.
CODEOWNERS auto-requests review from the engineering owner team.
If the change is launch-facing (any status promotion, demotion, or new public claim), the engineering owner team explicitly acknowledges the launch impact in the PR review before approval.
The platform-matrix-sync pre-commit hook runs python3 scripts/generate-platform-docs.py and stages the regenerated tables on every commit that touches the matrix, the generator, or any rendered page, so commits cannot land with the tables out of sync. Run python3 scripts/generate-platform-docs.py --check locally or in CI to verify the rendered tables match the JSON without regenerating.
After merge, the next NemoClaw release picks up the updated matrix automatically through the docs build.

Agents

NemoClaw supports the agent runtimes listed below. Pick the matching onboarding entry point for each agent.

Agent	Status	Default	Notes
OpenClaw	Tested	Yes	Default agent runtime. Onboard with `nemoclaw onboard` (no `--agent` flag required).
Hermes	Tested	No	First-class agent with dedicated CLI (`nemohermes`), Dockerfile, manifest, docs, and Hermes E2E coverage in `.github/workflows/e2e.yaml` (`hermes-e2e`, `hermes-*`, and Hermes rebuild/switch jobs). Onboard with `nemohermes onboard` or `nemoclaw onboard --agent hermes`. Unlocks the Hermes Provider inference route. Known structural gaps: model-provider compatibility registry is empty (backfilled after failures, see `nemoclaw-blueprint/model-specific-setup/hermes/README.md`); no Hermes-specific unit tests in `nemoclaw/src/`; macOS and WSL CI suites do not differentiate agents. Suitable for evaluation and the documented onboarding paths; production parity with OpenClaw is not yet asserted.
LangChain Deep Agents Code	Tested	No	Terminal-oriented coding agent runtime with no in-sandbox gateway or dashboard, built on the Deep Agents SDK. Its manifest is `agents/langchain-deepagents-code/manifest.yaml`, and its binary is `dcode`. Onboard with `nemo-deepagents onboard` or `nemoclaw onboard --agent langchain-deepagents-code`, and follow the quickstart. NemoClaw runs it as a managed agent runtime: unmanaged sandbox, Model Context Protocol (MCP) server, and shell overrides are rejected, and credential-bearing proxy URLs are dropped from persisted shell environment values. NVIDIA Endpoints and supported fixed hosted providers use native endpoints through sandbox-attached OpenShell providers. New Ollama, standalone vLLM, llama.cpp, hosted compatible outside the Personal tier, and qualifying host-local compatible selections use sandbox-attached providers. A fresh Personal-tier hosted compatible selection uses `inference.local` without creating a native attachment. Owned Local NVIDIA NIM, other compatible endpoints without an attachment, and retained shared local selections also use `inference.local`. Live runtime acceptance, broader launch material, and terminal-agent diagnostics are tracked at open issue #4861.

Platforms

The table below lists every platform tracked by NemoClaw, including deferred entries that are on the roadmap but not yet validated. The CI column reports whether the platform has a dedicated GitHub Actions job. A “Tested with limitations” row that is not in CI carries a stronger caveat than one that is. For install requirements and the shorter setup-oriented platform view, refer to Prerequisites.

OS	Container runtime	Status	PRD priority	CI	Notes
DGX OS (Spark)	Docker	Tested	P1	Yes	Use the standard installer and `nemohermes onboard`. DGX Spark Express keeps automatic managed-vLLM serving-profile selection as option 1 and offers the fixed single-host catalog profile as option 2. The automatic two-DGX Spark managed-vLLM profile is Experimental, and physical two-node end-to-end validation is pending. For the profile requirements and controls, see Set Up vLLM on Two DGX Sparks. For the validated single-DGX Spark walkthrough with local inference, see the NVIDIA Spark playbook.
DGX OS (Station)	Docker	Tested with limitations	P1	No	The PRD marks this platform as P1. Physical validation on one DGX Station GB300 covers generic Ubuntu 24.04 ARM64, stock DGX OS `7.5.0`, the April 2026 NVIDIA Colossus BaseOS profile, and the June 2026 NVIDIA AI Developer Tools profile. A physical no-OTA DGX OS `7.6.0` host provided the release and hardware profile used for its stable workstation-family classifier and passed read-only eligibility and runtime-command preflight. Full Station Express end-to-end qualification for the accepted no-OTA DGX OS `7.6.x` profile is pending. The profile remains subject to the same physical GB300, driver, ECC, Docker, CDI, and container GPU validation. Clean-host end-to-end validation passed on generic Ubuntu and Colossus BaseOS; stock DGX OS and AI Developer Tools completed Station Express validation. The DGX OS `7.5.0` run used released OpenShell `0.0.85`, local Nemotron Ultra serving, sandbox `cuInit(0)`, and a Hermes write/read file-tool task. A dual-Station configuration has not been validated, and dedicated CI coverage is not available. Direct-GPU policies expose only the exact read-only BDF directory for each discovered display-class PCI device with NVIDIA vendor ID (`0x10de`) and GB300 device ID (`0x31c2` or `0x31c3`) plus required existing topology and module paths; they do not expose `/sys`, the PCI parent subtree, or sysfs write access. During physical validation, reads of `/sys/fs/cgroup/cgroup.controllers` and `/sys/class/net/lo/address` remained denied. For canonical hardware qualification, image requirements, preparation, repair limits, reboot handoff, and the explicit temporary metadata override, see Prepare DGX Station to Install NemoClaw.
Linux	Docker	Tested	P0	Yes	Primary tested path. Ubuntu 24.04 has host-level onboarding validation. A digest-pinned Ubuntu 26.04 userspace lane builds the CLI and runs preflight, installer, and platform contracts on eligible main pushes; Docker-host, AppArmor, Landlock, and live onboarding validation on 26.04 remain pending. Other distros (Ubuntu 22.04, Fedora, Rocky, Alma, NixOS, Arch) may work but are not validated.
macOS (Apple Silicon)	Colima, Docker Desktop	Tested with limitations	P0	Yes	Start the container runtime (Colima or Docker Desktop) before installing; NemoClaw verifies the pinned official OpenShell formula and grants formula-scoped trust only around each Homebrew install, inspection, start, or stop operation, requires a legacy or changed formula to be repaired by rerunning the pinned installer, uses the standalone gateway only when Homebrew is absent or both the staged formula and installed keg are absent, requires Homebrew Colima users to install both Colima and the Docker CLI (`brew install colima docker`) before `docker info` can work, and recommends Xcode Command Line Tools (`xcode-select --install`) for Node native modules.
N1x Linux	Docker	Deferred	Unset	No	The accepted Deferred N1x Express preview selects one-host managed vLLM with `nvidia/Qwen3.6-35B-A3B-NVFP4`. It does not activate DGX Spark cluster discovery, the fixed catalog path, managed llama.cpp, or NVIDIA NIM. Host identity requires native Linux `arm64` and NVIDIA vendor ID `10de` on a display-class PCI device. The legacy path requires a regular `/etc/fastos-release` file of 1 through 4,096 bytes, owned by UID and GID 0, not linked or group- or world-writable, with exactly one `NAME="N1x FASTOS"` line. If the marker is absent, a display device recognized by the N1x PCI policy provides an inferred identity. The policy distinguishes documented N1x variants from QA-observed prototypes. Invalid, linked, or unreadable markers do not enable inference. QA confirmation at PR #12768 commit `caf6f19` reported that Deferred Express was offered and onboarding completed on one Concept ISO 1.0.2 host with prototype PCI device `2e2a`. Generic DMI values are supplemental and FastOS version is not pinned. Physical CUDA and CDI checks passed on one N1x host, but full NemoClaw Express E2E validation and dedicated CI coverage are pending. `host.platform.supported` remains absent. After identity qualifies, accepting Express can waive only the pending-validation finding. Declining or disabling Express can apply the same waiver when no provider is preselected or the explicit provider is recognized and is not Local NVIDIA NIM. An invalid or Local NVIDIA NIM provider remains blocked. Existing provider requirements still apply, and this waiver does not promote N1x. Do not claim N1x as supported until validation passes and this row is promoted.
NVIDIA RTX (consumer and Pro workstation GPUs)	Docker	Deferred	P1	No	The PRD marks this platform as P1. Covers RTX consumer cards and RTX Pro workstation cards on Linux hosts that meet the generic-Linux-GPU requirements (NVIDIA Container Toolkit + CDI present). The provider menu emits managed vLLM behind `NEMOCLAW_EXPERIMENTAL=1` or `NEMOCLAW_PROVIDER=install-vllm` for this host class today; the end-to-end onboard path on this hardware is not yet validated in CI.
Windows WSL2	Docker Desktop (WSL backend), Qualified rootless Podman	Tested with limitations	P1	No	Windows Express acceptance or the required non-interactive third-party software acceptance is the explicit opt-in to this Experimental surface. Windows Express and non-interactive onboarding automatically select managed llama.cpp when no provider is requested or recorded and `NEMOCLAW_MODEL` is unset. With `NEMOCLAW_LLAMACPP_RECIPE` unset, onboarding selects Qwen 3.6; a compatible explicit recipe selects that managed recipe. Selection requires Linux ARM64 WSL, the active local-default Docker authority, at least 48,000 MiB of Docker and GPU memory, driver version `580.65.06` or later, NVIDIA integration, and a passing Docker Desktop GPU-passthrough proof. N1x qualification requires the bounded CUDA proof to validate one GPU whose normalized identity is `NVIDIA RTX Spark N1X`, `NVIDIA RTX Spark N1X (5120-core Blackwell RTX GPU)`, or `NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU)`; the Windows chassis model does not participate in N1x selection. Station GB300 qualification instead requires a bounded Windows product observation and a reconciled proof that verifies every reported GPU and includes an `NVIDIA GB300` device. Managed llama.cpp additionally requires exactly one proved GB300 GPU UUID. Ordinary interactive onboarding can select another listed provider. Other Windows WSL Express installs use WSL-local Ollama, which can use Docker Desktop or the qualified rootless Podman provider. On Windows WSL N1x and Station GB300, the selected provider runs the same bounded CUDA workload and capacity query before the Ollama installed-model ranking can select qwen3.6:35b when at least 30,000 MiB is available. Generic multi-GPU and Podman Station hosts remain compute-constrained. Windows-host Ollama remains Docker Desktop-only. Dedicated N1x and Station GB300 WSL CI and physical end-to-end validation are pending.

Inference Providers

NemoClaw routes inference through the OpenShell gateway. Each row below is a provider the onboarding wizard can configure end-to-end.

Provider	Status	Endpoint type	Notes
NVIDIA Endpoints	Tested	OpenAI-compatible	Hosted models on integrate.api.nvidia.com
OpenRouter	Tested	OpenAI-compatible	First-class onboarding route for OpenClaw, Hermes, and LangChain Deep Agents Code. NemoClaw attaches the native OpenRouter provider to the selected sandbox; host-side validation and agent requests send the required OpenRouter attribution headers.
OpenAI	Tested	Native OpenAI-compatible	Uses OpenAI model IDs
Other OpenAI-compatible endpoint	Tested with limitations	Custom OpenAI-compatible	Custom base-URL adapter for servers that implement OpenAI-compatible `/v1/chat/completions` or `/v1/responses`. Behavior on OpenAI-compatible proxies, gateways, and self-hosted implementations may vary; this row claims the adapter, not the universe of compatible endpoints.
Anthropic	Tested	Native Anthropic	Uses anthropic-messages
Other Anthropic-compatible endpoint	Tested with limitations	Custom Anthropic-compatible	Adapter path validated with AWS Bedrock (`src/lib/onboard/bedrock-runtime.ts`). Behavior on other Anthropic-compatible proxies and gateways may vary; this row claims the adapter, not the universe of compatible endpoints.
Google Gemini	Tested	OpenAI-compatible	Uses Google’s OpenAI-compatible endpoint
Hermes Provider	Hermes only	OpenAI-compatible route	Available when onboarding Hermes Agent through `nemohermes`
Local Ollama	Tested with limitations	Local Ollama API	Available when Ollama is installed or running on the host. Validated default models: `qwen3.6:35b` (high VRAM), `nemotron-3-nano:30b` (medium VRAM), `qwen3.5:9b` (low VRAM fallback).
Local llama.cpp (already running)	Experimental	Local OpenAI-compatible	Attaches only to an authenticated operator-managed server on loopback port `8081` that passes cooperative native llama.cpp fingerprinting. NemoClaw does not own its server, model, or lifecycle.
Local llama.cpp (managed)	Experimental	Local OpenAI-compatible	Uses repository-owned YAML recipes and exact GGUF verification. The selected runtime-provider boundary owns lifecycle; all currently qualified profiles require Docker. Qualified DGX Spark hosts offer NVIDIA Nemotron 3 Nano 30B-A3B. Qualifying Windows WSL N1x and Station GB300 hosts automatically use managed llama.cpp during Windows Express or non-interactive onboarding when no provider is requested or recorded and `NEMOCLAW_MODEL` is unset. An unset recipe selects Qwen 3.6 35B-A3B; a compatible explicit recipe selects that managed recipe. The WSL profiles remain pending physical agent qualification.
Local NVIDIA NIM	Experimental	Local OpenAI-compatible	Requires `NEMOCLAW_EXPERIMENTAL=1` and a NIM-capable NVIDIA GPU. Host must have the NVIDIA Container Toolkit installed and a healthy CDI spec. Onboarding evaluates the canonical `host.gpu.nvidia_available`, `host.gpu.container_toolkit_available`, and `host.gpu.cdi_healthy` readiness capabilities before gateway, image, or sandbox lifecycle effects. NIM images pull from `nvcr.io` and require NGC registry login. NemoClaw gates this path behind the experimental flag. Onboarding filters the validated image list by usable memory. In non-interactive mode, onboarding selects the first compatible model unless the operator sets `NEMOCLAW_MODEL`. Model selection uses detected free GPU memory. If free memory is unavailable, NemoClaw uses total GPU memory. On DGX Spark, NemoClaw caps usable memory at 50 percent of total memory to match NIM’s reported unified-memory limit. The Nemotron 3 Super catalog minimum includes NIM’s reported runtime allocation. Local NVIDIA NIM is unavailable on N1x. NemoClaw omits the provider from onboarding and rejects `NEMOCLAW_PROVIDER=nim-local` on N1x. Select another standard provider or use the Deferred managed-vLLM preview on N1x. On Linux arm64 DGX Spark and DGX Station hosts, onboarding warns that some NIM images may not publish a `linux/arm64` manifest; the warning is advisory, and the selected image pull can still fail when the registry has no matching platform manifest. Managed vLLM has host-specific default models and is not gated on the same boxes. Catalogued Local NIM images in `bin/lib/nim-images.json` include `nvidia/nemotron-3-super-120b-a12b`, `nvidia/nemotron-3-nano-30b-a3b`, and `nvidia/llama-3.3-nemotron-super-49b-v1`.
Local vLLM (already running)	Tested with limitations	Local OpenAI-compatible	On a qualified N1x host, this route requires explicit standard-onboarding intent and remains unvalidated. On other hosts, no explicit intent is required. It appears in the onboarding menu when NemoClaw detects a server on `localhost:${NEMOCLAW_VLLM_PORT:-8000}`. The model is whatever the existing server serves.
Local vLLM (managed install/start)	Tested with limitations	Local OpenAI-compatible	Managed install/start requires Docker on `PATH`; attaching an already-running local vLLM server is a separate path. Appears by default on DGX Spark and qualifying DGX Station GB300 hosts. A labeled Deferred preview appears on hosts that match the N1x identity requirements; N1x remains Deferred until a physical NemoClaw Express E2E test passes. DGX Station is Tested with limitations across qualified profiles on one physical DGX Station GB300. Full Station Express end-to-end qualification for the accepted no-OTA DGX OS `7.6.x` profile is pending. Dual-Station configurations are not yet validated, and dedicated CI coverage is not available. For canonical Station qualification and host preparation, see the Additional Setup page for OpenClaw, Hermes, or Deep Agents. Generic Linux NVIDIA GPU hosts require `NEMOCLAW_EXPERIMENTAL=1` or `NEMOCLAW_PROVIDER=install-vllm`, NVIDIA Container Toolkit, and CDI. NemoClaw pins runtime images to immutable digests. New single-Station Express installs default to the experimental `nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4`; a qualified trusted pair selects distributed Ultra, and `--station-deepseek` selects `deepseek-ai/DeepSeek-V4-Flash`. Direct managed-vLLM defaults are `nvidia/Qwen3.6-35B-A3B-NVFP4` on DGX Spark and the Deferred N1x preview, `nvidia/NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-NVFP4` on DGX Station, and `nvidia/NVIDIA-Nemotron-3-Nano-4B-FP8` on generic Linux NVIDIA GPU hosts. The pinned `nvcr.io/nvidia/vllm` images are public, so Docker pulls them without NGC registry login.

Messaging Integrations

NemoClaw configures messaging channels during onboarding. The OpenShell gateway runs each channel as a supervised process; NemoClaw supplies onboarding, credential delivery, and policy presets for the sandbox egress rules.

Channel	Status	Notes
Slack	Tested	Configured through an OpenShell-managed channel during onboarding. Sandbox egress allowed by the `slack` policy preset.
Discord	Tested	Configured through an OpenShell-managed channel during onboarding. Sandbox egress allowed by the `discord` policy preset.
Telegram	Tested	Configured through an OpenShell-managed channel during onboarding.
WeChat	Tested with limitations	Channel hook available. Verify regional account access before relying on this path.
WhatsApp	Tested with limitations	Supported by both OpenClaw and Hermes through the channel manifest `supportedAgents` declaration in `src/lib/messaging/channels/whatsapp/manifest.ts`. Pairing happens in the sandbox through WhatsApp Web by scanning a QR code at first run; the Hermes flow exposes this as `hermes whatsapp` and persists session credentials under `~/.hermes/platforms/whatsapp/session` (`agents/hermes/manifest.yaml:69-71`). Sandbox egress goes through the `whatsapp` policy preset, which carries the WebSocket / Noise / h1-ALPN caveats documented in `src/lib/messaging/channels/whatsapp/policy/openclaw.yaml` and `src/lib/messaging/channels/whatsapp/policy/hermes.yaml`. No Meta Business API integration today; that path is out of scope for this matrix.
Microsoft Teams	Experimental	Supported by both OpenClaw and Hermes through the manifest-first messaging channel contract. Requires Bot Framework app credentials, a tenant ID, and a public HTTPS endpoint that reaches the sandbox webhook path `/api/messages`. Sandbox egress goes through the `teams` policy preset, and only one active Teams sandbox can use a given local `MSTEAMS_PORT` forward.
Google Chat	Experimental	Available for OpenClaw and Hermes through the channel manifest contract. The onboarding picker labels Google Chat experimental, and NemoClaw enables it only after you explicitly select or add it. Both agents require a Google service-account credential. OpenClaw receives events through a public HTTPS endpoint restricted to the `/googlechat` webhook path. Hermes instead pulls events from a configured Google Cloud Pub/Sub subscription over REST and exposes no webhook. OpenShell keeps the service-account private key outside the sandbox and supplies short-lived credentials at approved Google Chat and Pub/Sub egress boundaries.

Capabilities

Each row below is a launch-facing capability claim that NemoClaw makes in docs, blog posts, or demos. Use the status to decide whether the claim is safe to repeat verbatim or needs a caveat.

Capability	Status	Notes
Guided onboarding	Tested	Single-command interactive wizard (`nemohermes onboard`) that walks the user through inference provider selection, credential setup, and sandbox creation or update. It opens the agent dashboard when the selected runtime provides one. Non-interactive mode is supported with `--non-interactive` and `NEMOCLAW_*` environment variables for CI and scripted installs.
Sandboxed execution	Tested with limitations	Landlock, seccomp, network namespace isolation, no-new-privileges, privilege dropping, and process limits (nproc 512 at `scripts/lib/sandbox-rlimits.sh:8`) are tested and on by default. OpenShell owns capability enforcement for managed entrypoints, exec processes, and connect shells; those paths do not call NemoClaw capability handling. Direct container runtimes that explicitly override the image user to root retain the existing compatibility drop and required `setpriv` transition. Direct container launches must configure capabilities at the container runtime.
Managed inference	Tested	Provider-routed model calls through OpenShell, transparent to the agent. NVIDIA Endpoints, supported fixed hosted providers, and new hosted compatible selections outside the Personal tier use sandbox-attached providers. Qualified new local Ollama, standalone vLLM, llama.cpp, and host-local compatible selections also use attached providers where the agent supports them. New OpenClaw Model Router selections use attached providers at the managed host endpoint. A fresh Personal-tier hosted compatible selection, owned Local NVIDIA NIM, compatible endpoints without an attachment, other Model Router selections, and retained shared selections use `inference.local`. Pi native routing remains gated by its activation status; Hermes live qualification for its new local lifecycle remains pending. Bedrock uses a host-local adapter for AWS credentials. Provider credentials remain outside the sandbox. Supports every entry in the Providers table.
Declarative network policy	Tested	YAML-defined egress with policy presets. Presets include `slack`, `discord`, `telegram`, `weather`, `openclaw-pricing`, `huggingface`, `npm`, `pypi`, `brew`, and others. Hot-reloadable at runtime with `nemohermes <name> policy add`.
State persistence and rebuild transfer	Tested	OpenShell preserves the native agent home during routine lifecycle operations. Before destructive replacement, NemoClaw archives and integrity-checks the complete native home/workspace, then restores it into the replacement sandbox.
Agent skills	Tested	Packaged agent skills are discoverable by Cursor, Claude Code, and other coding assistants under `.agents/skills/`. Skills also install into the sandbox with `nemohermes <name> skill install`.
Managed MCP servers	Tested	OpenClaw, Hermes, and LangChain Deep Agents Code support authenticated HTTPS Streamable HTTP MCP server lifecycle through `nemohermes <name> mcp`. NemoClaw stores only credential names and ownership metadata, while OpenShell keeps raw credential values outside the sandbox and replaces credential placeholders at approved egress boundaries.
System readiness reporting	Tested	`nemohermes host probe` reports host and gateway observations, capabilities, qualifications, findings, evidence, and CLI provenance without changing host, Docker, gateway, provider, policy, credential, or sandbox state. The human-readable and JSON formats use the same schema-versioned report and deterministic exit codes.
Deep Agents trace export	Tested with limitations	LangChain Deep Agents Code can opt into bounded-content OpenTelemetry Protocol (OTLP) over HTTP trace export to an operator-managed host collector. The sandbox receives no remote-backend credential, the local receiver has no authentication, trace content can contain sensitive application data, and delivery failures do not stop agent work.
State migration	Tested	The complete native agent home/workspace migrates across rebuilds. OpenShell-owned credentials remain outside that tree and are not copied into it.
Blueprint versioning	Tested	Versioned, digest-verified, and reproducible blueprint lifecycle. Drives `nemohermes <name> rebuild` and the migration safeguards above.
Web search backend	Tested with limitations	Onboarding supports Brave and Tavily for OpenClaw and Tavily for Hermes. Provider selection, agent configuration, and credential attachment are build-time inputs, so changing the provider recreates the sandbox. OpenShell replaces resolver placeholders at egress, including JSON request-body rewriting for Hermes Tavily. Users supply the backend credential; NemoClaw does not bundle a key.

Deployment Paths

Use the following table to choose how to bring up NemoClaw on a host. Pick the row that matches the target environment.

Path	Status	Notes
Local CLI onboard	Tested	Run `nemohermes onboard` on a tested platform with Docker available locally. Primary path.
Native rootless Podman on Linux	Tested with limitations	Set `NEMOCLAW_GATEWAY_RUNTIME=podman` before standard onboarding. The provider requires a qualified current-user Podman socket, rootless service, cgroups v2, bridge networking and DNS, `lsof` on `PATH` for gateway listener verification, NVIDIA CDI for GPU use, and exact managed-image receipts or digest-pinned OpenClaw and Hermes images supplied through `--from-image`. NemoClaw does not install `lsof`; install it through the host’s package-management policy before retrying onboarding. Full native E2E qualification currently runs on Linux amd64; the managed-image contract accepts `linux/amd64` and `linux/arm64` receipts. The WSL Arm64 Ollama capacity proof is covered by provider-contract and onboarding tests; physical end-to-end validation remains pending. Managed local vLLM install/start remains Docker-backed and is unavailable without Docker. Custom `--from` Dockerfiles and read-only host mounts are not qualified.
Headless Linux server	Tested with limitations	Provision a tested Linux host, connect over SSH, run the standard installer and `nemohermes onboard`, and keep dashboards bound to loopback behind SSH port forwarding. Automatic recovery after a host reboot is not guaranteed; follow the documented manual recovery flow.

Out of Scope and Not Supported

The items below come up in conversations but are explicitly out of scope. They are listed here so launch material, sales conversations, and support triage have a clear “we do not claim to do this” reference.

Item	Status	Why
Other container runtimes	Unsupported	Native rootless Podman has the limited explicit support described in Deployment Paths. Containerd, CRI-O, and other runtime providers are not selectable for standard onboarding.
Intel Mac (macOS x86_64)	Unsupported	The supported OpenShell Homebrew gateway service path is Apple Silicon only, and OpenShell does not publish macOS x86_64 standalone gateway assets. The top-level installer rejects Intel Mac hosts before release-ref resolution or downloads (`install.sh:108`), and the OpenShell installer retains a downstream asset guard (`scripts/install-openshell.sh:687`). See issue #954 (closed).
Non-Ubuntu/Debian Linux distros	Unsupported	Installer assumes `apt-get`. Fedora/Rocky/Alma/Arch/NixOS are not validated and the installer’s package-manager probes do not cover them. See open issue #899 (Fedora hang).
Native Kubernetes or OpenShift deployments	Unsupported	NemoClaw runs the sandbox as a Docker container, not a Kubernetes pod. The default Docker-driver topology does not embed k3s. Operator-managed K8s/OpenShift deployments are out of scope; see issue #407 (community OpenShift through agent-sandbox CRD).
Air-gapped / offline installs	Unsupported	Onboard assumes network reachability for package fetches, container pulls, and provider validation. See open issues #4872 and #2218 (production-deployment epic covering air-gapped support, China network guidance, multi-host topology).
Other Windows-on-ARM GPU paths	Unsupported	Windows-on-ARM CPU paths run under WSL2 ‘tested with limitations’. The qualifying Windows WSL N1x and Station GB300 paths remain pending dedicated CI and physical end-to-end validation. Station GB300 qualification requires the bounded Windows product observation and a reconciled provider proof that includes an NVIDIA GB300 device. A matching provider proof alone does not qualify a generic host for automatic large-model selection. Unqualified providers, mismatched rows, implausible names, or failed bounded CUDA proof remain rejected. See closed issue #4565 and #12073.
Non-NVIDIA GPUs (AMD/ROCm, Intel Arc, Apple Metal)	Unsupported	GPU-backed local vLLM and NIM onboarding requires the canonical `host.gpu.nvidia_available`, `host.gpu.container_toolkit_available`, and `host.gpu.cdi_healthy` readiness capabilities. NemoClaw does not install non-NVIDIA accelerator drivers.
Other LangChain, AutoGen, CrewAI, or non-listed agent harnesses	Unsupported	LangChain Deep Agents Code is the only integrated LangChain-family agent runtime (refer to the Agents section above; status `Tested`). Other LangChain agent runtimes, AutoGen, CrewAI, and any agent runtime not listed in the Agents table are not integrated. Bringing more agent runtimes is tracked as a research epic (refer to open issue #4861) but is not on the current roadmap.
Multi-user host sharing	Unsupported	Sandboxes are scoped to a single host user. NemoClaw treats multi-user hosts as a risk and warns at onboard; see `docs/security/openclaw-controls.mdx` Multi-user detection.
Hosted SaaS / managed NemoClaw	Unsupported	There is no managed offering. Supported deployment paths are local CLI onboarding and headless Linux server onboarding.
Native provider integrations not in the Providers table	Unsupported	Vertex AI, Azure OpenAI, SageMaker, Together.ai, Replicate, and HuggingFace Inference Endpoints are not first-class onboarding entries. AWS Bedrock works through the `compatible-anthropic-endpoint` adapter (`src/lib/onboard/bedrock-runtime.ts`).
Production SLA or guaranteed response times	Unsupported	NemoClaw is an early-preview alpha project. Maintainers respond on a best-effort basis. No SLA is offered.

Using This Matrix

Docs and READMEs that reference any row above should link to this page instead of restating status. Partial tables, such as the prerequisites page, generate from the same JSON and stay in sync with scripts/generate-platform-docs.py.
Demos and launch material should cite the status verbatim. A “Tested with limitations” row is not a “Tested” row.
Customer support can use the matrix to triage incoming reports. A failure on a Tested row is a bug. A failure on a Deferred row is an unsupported configuration request. A failure on an Unsupported row is a feature request that needs separate triage.
Roadmap changes land in the JSON first, then propagate to this page on the next generator run.

Updating the Matrix

Edit ci/platform-matrix.json.
Run python3 scripts/generate-platform-docs.py to regenerate this page and the partial tables on prerequisites and provider selection.
Open a PR. The engineering owner team is auto-assigned through CODEOWNERS and explicitly acknowledges launch impact in the PR review for any launch-facing claim change.
The platform-matrix-sync pre-commit hook regenerates and stages the rendered tables before the commit lands; run python3 scripts/generate-platform-docs.py --check to verify drift without regenerating.