<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
<!-- SPDX-License-Identifier: Apache-2.0 -->
Deploy NemoClaw to a Remote GPU Instance
Gotchas
- The command is deprecated.
- On Brev, set in 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.
- or exported when your remote vLLM or Hugging Face workflow needs access to gated models.
- NemoClaw installed locally if you plan to use the deprecated wrapper. 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
.
Quick Start
If your Brev instance is already up and has already been onboarded with a sandbox, start with the standard sandbox chat flow:
console
$ 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
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
command is deprecated.
Prefer provisioning the remote host separately, then running the standard NemoClaw installer and
on that host.
Create a Brev instance and run the legacy compatibility flow:
console
$ nemoclaw deploy <instance-name>
Replace
with a name for your remote instance, for example
.
The sandbox created on the remote VM uses
, or
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 (the setup wizard) to create the gateway, register providers, and launch the sandbox.
- Starts optional host auxiliary services (for example the cloudflared tunnel) when is available. Channel messaging is configured during onboarding and runs through OpenShell-managed processes, not through .
By default, the compatibility wrapper asks Brev to provision on
. Override this with
if you need a different Brev cloud provider.
If you export
or
, 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:
console
$ nemoclaw deploy <instance-name>
Monitor the Remote Sandbox
SSH to the instance and run the OpenShell TUI to monitor activity and approve network requests:
console
$ ssh <instance-name> 'cd ~/nemoclaw && set -a && . .env && set +a && openshell term'
Verify Inference
Run a test agent prompt inside the remote sandbox:
console
$ openclaw agent --agent main --local -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
. When accessing the dashboard from a remote browser
(for example through a Brev public URL or an SSH port-forward), set
to the origin the browser will use
before running setup:
console
$ export CHAT_UI_URL="https://openclaw0-<id>.brevlab.com"
$ nemoclaw deploy <instance-name>
For SSH port-forwarding, the origin is typically
(the
default), so no extra configuration is needed.
Warning:
On Brev, set
in the launchable environment configuration so it is
available when the installer builds the sandbox image. If
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
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
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:
console
$ 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
.
If your network requires a different proxy, set
and
before onboarding:
console
$ 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
.
GPU Configuration
The deploy script uses the
environment variable to select the GPU type.
The default value is
a2-highgpu-1g:nvidia-tesla-a100:1
.
Set this variable before running
to use a different GPU configuration:
console
$ 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 the nemoclaw-user-manage-sandboxes
skill) to connect Telegram, Discord, or Slack through OpenShell-managed channel messaging
nemoclaw-user-monitor-sandbox
— Monitor Sandbox Activity (use the nemoclaw-user-monitor-sandbox
skill) for sandbox monitoring tools
- — Commands (use the skill) for the full command reference