
nemoclaw-user-deploy-remote
Explains how to run NemoClaw on a remote GPU instance, including the deprecated Brev compatibility path and the preferred installer plus onboard flow. Use when deploying NemoClaw to a remote VM, onboarding a Brev instance, or migrating away from the legacy nemoclaw deploy wrapper. Trigger keywords - deploy nemoclaw remote gpu, nemoclaw brev cloud deployment, nemoclaw plugins, openclaw plugins, install openclaw plugin, nemoclaw onboard from dockerfile, nemoclaw brev web ui, nemoclaw getting started, brev quickstart, nvidia nemotron agent, nemoclaw sandbox hardening, container security, docker capabilities, process limits.
- Installs
- 811
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/nvidia/skills --skill nemoclaw-user-deploy-remote- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads nemoclaw-user-deploy-remote automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Deploy NemoClaw to a Remote GPU Instance
Gotchas
- The
nemoclaw deploycommand is deprecated. - On Brev, set
CHAT_UI_URLin the launchable environment configuration so it is available when the installer builds the sandbox image.
Prerequisites
- The Brev CLI installed and authenticated.
- A provider credential for the inference backend you want to use during onboarding.
HF_TOKENorHUGGING_FACE_HUB_TOKENexported when your remote vLLM or Hugging Face workflow needs access to gated models.- NemoClaw installed locally if you plan to use the deprecated
nemoclaw deploywrapper. Otherwise, install NemoClaw directly on the remote host after provisioning it.
Run NemoClaw on a remote GPU instance through Brev.
The preferred path is to provision the VM, run the standard NemoClaw installer on that host, and then run nemoclaw onboard.
Quick Start
If your Brev instance is already up and has already been onboarded with a sandbox, start with the standard sandbox chat flow:
$ nemoclaw my-assistant connect
$ openclaw tui
This gets you into the sandbox shell first and opens the OpenClaw chat UI right away.
If the VM is fresh, run the standard installer on that host and then run nemoclaw onboard before trying nemoclaw my-assistant connect.
If you are connecting from your local machine and still need to provision the remote VM, you can still use nemoclaw deploy <instance-name> as the legacy compatibility path described below.
Deploy the Instance
Warning:
The nemoclaw deploy command is deprecated.
Prefer provisioning the remote host separately, then running the standard NemoClaw installer and nemoclaw onboard on that host.
Create a Brev instance and run the legacy compatibility flow:
$ nemoclaw deploy <instance-name>
Replace <instance-name> with a name for your remote instance, for example my-gpu-box.
The sandbox created on the remote VM uses NEMOCLAW_SANDBOX_NAME, or my-assistant when the variable is unset.
Sandbox names must be lowercase, start with a letter, contain only letters, numbers, and internal hyphens, and end with a letter or number.
The deploy wrapper validates the sandbox name before it provisions the Brev instance, opens SSH, or starts the remote installer.
The legacy compatibility flow performs the following steps on the VM:
- Installs Docker and the NVIDIA Container Toolkit if a GPU is present.
- Installs the OpenShell CLI.
- Runs
nemoclaw onboard(the setup wizard) to create the gateway, register providers, and launch the sandbox. - Starts optional host auxiliary services (for example the cloudflared tunnel) when
cloudflaredis available. Channel messaging is configured during onboarding and runs through OpenShell-managed processes, not throughnemoclaw tunnel start.
By default, the compatibility wrapper asks Brev to provision on gcp. Override this with NEMOCLAW_BREV_PROVIDER if you need a different Brev cloud provider.
If you export HF_TOKEN or HUGGING_FACE_HUB_TOKEN, the wrapper forwards those values to the VM so remote setup can pull gated Hugging Face model repositories.
Connect to the Remote Sandbox
After deployment finishes, the deploy command opens an interactive shell inside the remote sandbox. To reconnect after closing the session, run the command again:
$ nemoclaw deploy <instance-name>
Monitor the Remote Sandbox
SSH to the instance and run the OpenShell TUI to monitor activity and approve network requests:
$ ssh <instance-name> 'cd ~/nemoclaw && set -a && . .env && set +a && openshell term'
Verify Inference
Run a test agent prompt inside the remote sandbox:
$ openclaw agent --agent main -m "Hello from the remote sandbox" --session-id test
Remote Dashboard Access
The NemoClaw dashboard validates the browser origin against an allowlist baked
into the sandbox image at build time. By default the allowlist only contains
http://127.0.0.1:18789. When accessing the dashboard from a remote browser
(for example through a Brev public URL or an SSH port-forward), set
CHAT_UI_URL to the origin the browser will use before running setup:
$ export CHAT_UI_URL="https://openclaw0-<id>.brevlab.com"
$ nemoclaw deploy <instance-name>
For SSH port-forwarding, the origin is typically http://127.0.0.1:18789 (the
default), so no extra configuration is needed.
Warning:
On Brev, set CHAT_UI_URL in the launchable environment configuration so it is
available when the installer builds the sandbox image. If CHAT_UI_URL is not
set on a headless host, the compatibility wrapper prints a warning.
NEMOCLAW_DISABLE_DEVICE_AUTH is also evaluated at image build time.
When CHAT_UI_URL points at a non-loopback origin, NemoClaw disables OpenClaw device pairing in the generated sandbox configuration because browser-only remote users cannot complete terminal-based pairing.
Any device that can reach the configured dashboard origin can connect without pairing, so avoid exposing that origin on internet-reachable or shared-network deployments.
First-Run Readiness Budget
On a remote GPU host, the first nemoclaw onboard typically does the slowest work of the lifecycle: the sandbox image is built locally and uploaded into the OpenShell gateway, which can stream hundreds of MiB over the VM's link before the readiness wait even starts.
The post-create readiness wait defaults to 180 seconds (NEMOCLAW_SANDBOX_READY_TIMEOUT), which is sized for warm-cache, workstation-class onboarding and can be exceeded on:
- DGX Station first runs with large quantised models (70B+ parameter footprints, NVFP4 weights).
- Cloud VMs where the local image-build cache is cold and the upload runs over the public network.
- Hosts onboarding the Brave Web Search preset on the first run (the egress policy stack adds boot work).
Raise the budget before re-running onboard:
$ export NEMOCLAW_SANDBOX_READY_TIMEOUT=600
$ nemoclaw onboard
If onboard ends with Sandbox '<name>' was created but did not become ready within 180s, onboard deletes the partially-created sandbox first, so the next attempt with the raised budget starts from a clean state.
For the inference-probe budget that runs earlier in onboarding, see NEMOCLAW_LOCAL_INFERENCE_TIMEOUT (use the nemoclaw-user-configure-inference skill).
Proxy Configuration
NemoClaw routes sandbox traffic through a gateway proxy that defaults to 10.200.0.1:3128.
If your network requires a different proxy, set NEMOCLAW_PROXY_HOST and NEMOCLAW_PROXY_PORT before onboarding:
$ export NEMOCLAW_PROXY_HOST=proxy.example.com
$ export NEMOCLAW_PROXY_PORT=8080
$ nemoclaw onboard
These values are baked into the sandbox image at build time.
They are also forwarded into the runtime container during sandbox creation, so /tmp/nemoclaw-proxy-env.sh uses the same host and port that the image build used.
Only alphanumeric characters, dots, hyphens, and colons are accepted for the host.
The port must be numeric (0-65535).
Changing the proxy after onboarding requires re-running nemoclaw onboard.
GPU Configuration
The deploy script uses the NEMOCLAW_GPU environment variable to select the GPU type.
The default value is a2-highgpu-1g:nvidia-tesla-a100:1.
Set this variable before running nemoclaw deploy to use a different GPU configuration:
$ export NEMOCLAW_GPU="a2-highgpu-1g:nvidia-tesla-a100:2"
$ nemoclaw deploy <instance-name>
References
- Load references/install-openclaw-plugins.md when users ask how to install, build, or configure OpenClaw plugins under NemoClaw. Explains the difference between OpenClaw plugins and agent skills, and shows the current Dockerfile-based workflow for baking a plugin into a NemoClaw sandbox.
- Load references/brev-web-ui.md when a user wants to try NemoClaw without installing the CLI, or asks how to get started on Brev. Guides users through deploying NemoClaw with the Brev web UI.
- Load references/sandbox-hardening.md when reviewing sandbox image security controls, auditing capability drops, or looking up the runtime resource limits. Includes the sandbox container image hardening reference, covering Docker capabilities and process limits.
Related Skills
nemoclaw-user-manage-sandboxes— Set Up Messaging Channels (use thenemoclaw-user-manage-sandboxesskill) to connect Telegram, Discord, or Slack through OpenShell-managed channel messagingnemoclaw-user-monitor-sandbox— Monitor Sandbox Activity (use thenemoclaw-user-monitor-sandboxskill) for sandbox monitoring toolsnemoclaw-user-reference— Commands (use thenemoclaw-user-referenceskill) for the fulldeploycommand reference
FAQ
What does the nemoclaw-user-deploy-remote skill do?
Explains how to run NemoClaw on a remote GPU instance, including the deprecated Brev compatibility path and the preferred installer plus onboard flow. Use when deploying NemoClaw to a remote VM, onboarding a Brev instance, or migrating away from the legacy nemoclaw deploy wrapper. Trigger keywords - deploy nemoclaw remote gpu, nemoclaw brev cloud deployment, nemoclaw plugins, openclaw plugins, install openclaw plugin, nemoclaw onboard from dockerfile, nemoclaw brev web ui, nemoclaw getting started, brev quickstart, nvidia nemotron agent, nemoclaw sandbox hardening, container security, docker capabilities, process limits.
How do I install nemoclaw-user-deploy-remote?
Run npx skills add https://github.com/nvidia/skills --skill nemoclaw-user-deploy-remote in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/nemoclaw-user-deploy-remote/ (personal) or .claude/skills/nemoclaw-user-deploy-remote/ (project).
Which AI agents can use nemoclaw-user-deploy-remote?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is nemoclaw-user-deploy-remote safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains nemoclaw-user-deploy-remote?
It is published by nvidia in nvidia/skills, and it is an official skill from the maker of the technology it covers. It has 811 recorded installs.
More from nvidia/skills
rag-blueprint
nvidia/skills
NVIDIA RAG Blueprint — deploy, configure, troubleshoot, and manage. Handles any RAG action: deploy, install, start, enable, disable, toggle, change, configure, troubleshoot, debug, fix, shutdown, stop, or tear down any RAG feature or service (Agentic RAG, VLM, guardrails, query rewriting, models, search, ingestion, observability, summarization, reasoning, and more).
accelerated-computing-cudf
nvidia/skills
Official NVIDIA-authored guidance for NVIDIA cuDF GPU DataFrames, pandas acceleration, dask-cuDF, ETL, joins, groupby, CSV/Parquet I/O, nullable semantics, and multi-GPU DataFrame workloads.
aiq-research
nvidia/skills
Use when asked to run deep research or AI-Q research through a reachable NVIDIA AI-Q Blueprint backend.
cuopt-developer
nvidia/skills
Modify, build, test, debug, and contribute to NVIDIA cuOpt (C++/CUDA, Python, server, CI). Use for solver internals, PRs, DCO, and code conventions.
aiq-deploy
nvidia/skills
Use when asked to install, deploy, run, validate, troubleshoot, or stop NVIDIA AI-Q Blueprint infrastructure.
cuopt-install
nvidia/skills
Install cuOpt for Python, C, or server via pip, conda, or Docker; verify the install. For building cuOpt from source, see cuopt-developer.
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.