Nemoclaw User Deploy Remote

<!-- 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 nemoclaw deploy command is deprecated.
• On Brev, set CHAT_UI_URL 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.
• HF_TOKEN or HUGGING_FACE_HUB_TOKEN exported when your remote vLLM or Hugging Face workflow needs access to gated models.
• NemoClaw installed locally if you plan to use the deprecated nemoclaw deploy 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 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:

1. Installs Docker and the NVIDIA Container Toolkit if a GPU is present. 2. Installs the OpenShell CLI. 3. Runs nemoclaw onboard (the setup wizard) to create the gateway, register providers, and launch the sandbox. 4. Starts optional host auxiliary services (for example the cloudflared tunnel) when cloudflared is available. Channel messaging is configured during onboarding and runs through OpenShell-managed processes, not through nemoclaw 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](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](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](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
• nemoclaw-user-reference — Commands (use the nemoclaw-user-reference skill) for the full deploy command reference

<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. --> <!-- SPDX-License-Identifier: Apache-2.0 -->

Launch NemoClaw with the Brev Web UI

Use the Brev web UI to launch a hosted NemoClaw sandbox from your browser. This flow provisions a remote VM, configures inference, starts OpenClaw inside an OpenShell sandbox, and opens the OpenClaw dashboard.

Note:

Use this guide when you want to try NemoClaw without installing the CLI or using a local GPU. If you want to manage the remote host from a terminal, see Deploy to a Remote GPU Instance.

What This Flow Creates

The Brev web flow creates the following resources:

• A Brev-managed Linux VM.
• Docker and the OpenShell runtime on that VM.
• A NemoClaw sandbox running OpenClaw.
• Inference routing for the provider you select during setup.
• A browser-accessible OpenClaw dashboard.

Prerequisites

• An NVIDIA Brev account at brev.nvidia.com.
• An NVIDIA API key from build.nvidia.com if you use the default NVIDIA Cloud provider.

You do not need to install local software for this flow.

Get Your NVIDIA API Key

If you already have an NVIDIA API key skip this section. Otherwise, follow these steps to generate a new key:

1. Go to build.nvidia.com. 2. Sign in or create an account. 3. Click your profile icon in the top right. 4. Select API Keys. 5. Click Generate API Key. 6. Copy the key. It starts with nvapi-.

Keep this key ready for the next step.

Launch NemoClaw from Brev

Use the NemoClaw Brev launchable to launch a NemoClaw sandbox from your browser.

1. Open the NemoClaw Brev launchable and sign in if prompted. 2. Review the instance type, cloud provider, and estimated hourly cost on the NemoClaw setup page. 3. Click Deploy NemoClaw.

The right-side deployment panel shows progress while Brev deploys the CPU instance and prepares VM mode. Keep this page open until the deployment completes. When the panel shows the NemoClaw button, click it to open the agent setup page.

Configure Your Agent

The setup page walks you through three stages: Configure, Setup, and Launch.

Configure

The Configure stage opens the Connect to AI screen. Use the NVIDIA Cloud provider shown on this screen.

1. Leave NVIDIA Cloud selected. 2. Paste your nvapi- API key. 3. Click Create Agent.

Note:

The Show Other Providers dropdown appears below the NVIDIA Cloud card and can be easy to miss. Click it to expand the provider list. The expanded list includes OpenAI, Anthropic, and Google Gemini. For these providers, get the API key from the provider's own console before you create the agent.

Setup

NemoClaw configures the remote host and sandbox automatically. This stage usually takes about 5 minutes.

During setup, NemoClaw installs the runtime, prepares the sandboxed agent environment, and configures inference routing for the provider you selected.

Launch

When setup finishes, Brev shows the following confirmation:

AGENT CREATED SUCCESSFULLY
Your agent is running in a secure sandbox and ready to use.

Agent: agent
Model: nemotron-3-super-120b
Provider: NVIDIA Cloud

Click Chat With Agent to open the OpenClaw dashboard.

Note:

The dashboard might initially show a Pairing required warning. This means the gateway is still completing pairing in the background. Wait for about a few minutes for pairing to finish automatically. Refresh the dashboard to see if the warning is resolved and the connection is established. If pairing does not finish, go to the Overview page in the OpenClaw UI, find the Gateway Access panel, and click Connect.

Start a Chat

Use the dashboard chat box to send your first message:

Hello! What can you do for me? What skills do you have available?

The agent reads its workspace files and introduces itself. The starter workspace includes example skills such as:

• Weather gets current weather and forecasts.
• Healthcheck runs security audit and hardening checks.
• Skill-Creator creates new custom skills.

Personalize Agent Memory

The agent starts with an empty USER.md file. Ask the agent to add details that help it personalize future responses.

In the chat, type the following:

Please update my USER.md file with the following:
Name: [your name]
Timezone: [your timezone, such as "America/New_York"]
Notes: [what you are working on]

The agent writes this information to its workspace so it can use it across sessions on the same sandbox.

Stop Your Instance When Done

Brev continues billing while the instance runs. Stop the instance when you finish experimenting.

1. Go back to brev.nvidia.com. 2. Click GPUs in the nav bar. 3. Find your NemoClaw instance. 4. Click Stop.

Check the Brev UI for the current hourly price before leaving the instance running.

Next Steps

After your agent is running, explore these related tasks:

• Set Up Messaging Channels (use the nemoclaw-user-manage-sandboxes skill) to learn how to connect Telegram, Slack, or Discord.
• Switch Inference Providers (use the nemoclaw-user-configure-inference skill) to learn how to change the model provider after setup.
• Monitor Sandbox Activity (use the nemoclaw-user-monitor-sandbox skill) to learn how to inspect sandbox health and logs.
• Deploy to a Remote GPU Instance to learn how to deploy NemoClaw to a remote GPU instance using the CLI.
• Troubleshooting (use the nemoclaw-user-reference skill) to learn how to fix common setup and runtime issues.

<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. --> <!-- SPDX-License-Identifier: Apache-2.0 -->

Install OpenClaw Plugins

OpenClaw plugins extend the OpenClaw runtime with hooks, services, tools, or provider integrations. They are different from NemoClaw-managed agent skills:

• Plugins are code packages loaded by OpenClaw.
• Skills are SKILL.md directories that teach an agent how to perform a task.
• Policy presets are network-egress rules that control what sandboxed code can reach.

Today, the supported NemoClaw path for OpenClaw plugins is to bake the plugin into a custom sandbox image and onboard from that Dockerfile.

Prepare a Build Directory

Put the Dockerfile and everything it needs to COPY in one directory. nemoclaw onboard --from <Dockerfile> uses the Dockerfile's parent directory as the Docker build context.

my-plugin-sandbox/
├── Dockerfile
└── my-plugin/
    ├── package.json
    └── src/

Example Dockerfile

Use the custom image to copy the plugin into the OpenClaw extensions directory and let OpenClaw refresh its config before NemoClaw starts the sandbox.

ARG SANDBOX_BASE=ghcr.io/nvidia/nemoclaw/sandbox-base:latest
FROM ${SANDBOX_BASE}

COPY my-plugin/ /opt/my-plugin/
WORKDIR /opt/my-plugin
RUN npm ci --no-audit --no-fund && npm run build

RUN mkdir -p /sandbox/.openclaw/extensions \
 && cp -a /opt/my-plugin /sandbox/.openclaw/extensions/my-plugin \
 && openclaw doctor --fix

WORKDIR /opt/nemoclaw

If the plugin needs configuration in openclaw.json, apply it after openclaw doctor --fix so the base config exists first.

Create the Sandbox

Point nemoclaw onboard --from at the Dockerfile in the build directory.

$ nemoclaw onboard --from ./my-plugin-sandbox/Dockerfile

If you need a second sandbox alongside an existing one, use a dedicated build directory and rerun onboarding with the sandbox name and ports you intend to use.

Network Access

Plugins still run inside the sandbox policy boundary. If a plugin needs network egress, add or update a policy preset for the required hostnames and binaries before rebuilding the sandbox.

For example, see Network Policies (use the nemoclaw-user-reference skill) for policy concepts and Customize Network Policy (use the nemoclaw-user-manage-policy skill) for custom preset workflows.

Common Mistakes

These are the most common places where plugin installation gets mixed up with other NemoClaw extension paths.

• Do not use nemoclaw <sandbox> skill install for OpenClaw plugins. That

command only installs SKILL.md agent skills.

• Do not put a Dockerfile in a broad directory such as /tmp unless you intend

to send that whole directory as the Docker build context.

• Keep plugin dependencies in the build stage or plugin directory; avoid copying

unrelated host files into the sandbox image.

Next Steps

• Review Sandbox Hardening before adding plugin code to a

shared or long-lived sandbox.

• Review Network Policies (use the nemoclaw-user-reference skill) to plan plugin

egress rules.

• Follow Customize Network Policy (use the nemoclaw-user-manage-policy skill)

if the plugin needs a custom preset.

<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. --> <!-- SPDX-License-Identifier: Apache-2.0 -->

Sandbox Image Hardening

The NemoClaw sandbox image applies several security measures to reduce attack surface and limit the blast radius of untrusted workloads.

Removed Unnecessary Tools

Build toolchains (gcc, g++, make) and network probes (netcat) are explicitly purged from the runtime image. These tools are not needed at runtime and would unnecessarily widen the attack surface.

The runtime image keeps a small set of operational utilities for normal sandbox workflows, including vi, jq, and dos2unix. Use these for lightweight inspection and file cleanup inside the sandbox, but make durable image or policy changes in the NemoClaw source tree and rebuild the sandbox.

If you need a compiler during build, use the existing multi-stage build (the builder stage has full Node.js tooling) and copy only artifacts into the runtime stage.

Process Limits

The container ENTRYPOINT sets ulimit -u 512 to cap the number of processes a sandbox user can spawn. This mitigates fork-bomb attacks. The startup script (nemoclaw-start.sh) applies the same limit.

Adjust the value via the --ulimit nproc=512:512 flag if launching with docker run directly.

Dropping Linux Capabilities

The NemoClaw entrypoint drops dangerous capabilities from the process bounding set before it starts agent services. It removes CAP_SYS_ADMIN, CAP_SYS_PTRACE, CAP_NET_RAW, CAP_DAC_OVERRIDE, CAP_SYS_CHROOT, CAP_FSETID, CAP_SETFCAP, CAP_MKNOD, CAP_AUDIT_WRITE, and CAP_NET_BIND_SERVICE. When setpriv is available, the entrypoint also removes the remaining privilege-separation capabilities during the switch from root to the sandbox and gateway users.

For defense-in-depth, also drop all Linux capabilities at the container runtime when you launch the image directly:

$ docker run --rm \
    --cap-drop=ALL \
    --ulimit nproc=512:512 \
    nemoclaw-sandbox

Docker Compose Example

services:
  nemoclaw-sandbox:
    image: nemoclaw-sandbox:latest
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    ulimits:
      nproc:
        soft: 512
        hard: 512
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp:size=64m

Note: The Dockerfile itself cannot enforce --cap-drop. That is a

runtime concern controlled by the container orchestrator. Always configure

capability dropping in your docker run flags, Compose file, or Kubernetes

securityContext.

Filesystem Layout

The sandbox Landlock policy declares which paths are writable. The agent's home directory (/sandbox) is writable by default:

This writable default is intentional. Seeing the sandbox user create files under /sandbox or /sandbox/.openclaw in a fresh sandbox does not mean Landlock failed. Landlock still enforces the fixed read-only system paths below.

System paths remain read-only to prevent agents from:

• Replacing system binaries with trojanized versions
• Modifying DNS resolution or TLS trust stores
• Tampering with libraries or shell configuration outside /sandbox

The image build pre-creates locked shell init files .bashrc and .profile without proxy entries. Runtime proxy configuration is sourced from system-wide shell hooks that read /tmp/nemoclaw-proxy-env.sh.

Landlock Kernel Requirements

Landlock LSM requires Linux kernel 5.13 or later with CONFIG_SECURITY_LANDLOCK=y. The NemoClaw sandbox policy uses compatibility: best_effort, which means Landlock enforcement is silently skipped on kernels that do not support it.

On such kernels, protection falls back to DAC (file ownership and permissions) only. Files outside the writable paths would be inaccessible to the agent regardless of DAC permissions.

Operators should verify Landlock availability:

$ ls /sys/kernel/security/landlock

For production deployments, kernel 5.13+ with Landlock enabled is strongly recommended. The test/e2e/e2e-cloud-experimental/checks/04-landlock-readonly.sh script validates enforcement at runtime.

References

• #804: Filesystem layout and Landlock policy
• #807: gcc in sandbox image
• #808: netcat in sandbox image
• #809: No process limit
• #797: Drop Linux capabilities

Description: <br>

Explains how to run NemoClaw on a remote GPU instance, including the deprecated Brev compatibility path and the preferred installer plus onboard flow. <br>

This skill is ready for commercial/non-commercial use. <br>

Owner

NVIDIA <br>

License/Terms of Use: <br>

Apache 2.0 <br>

Use Case: <br>

Developers and engineers deploying NemoClaw to remote GPU instances using Brev or other cloud VMs for always-on AI assistant workloads. <br>

Deployment Geography for Use: <br>

Global <br>

Known Risks and Mitigations: <br>

Risk: Review before execution as proposals could introduce incorrect or misleading guidance into skills. <br> Mitigation: Review and scan skill before deployment. <br>

Reference(s): <br>

• Install OpenClaw Plugins <br>
• Launch NemoClaw with the Brev Web UI <br>
• Sandbox Hardening <br>

Skill Output: <br>

Output Type(s): [Shell commands, Configuration instructions] <br> Output Format: [Markdown with inline bash code blocks] <br> Output Parameters: [1D] <br> Other Properties Related to Output: [None] <br>

Evaluation Metrics Used: <br>

Reported benchmark dimensions: <br>

• Security: Checks whether skill-assisted execution avoids unsafe behavior such as secret leakage, destructive commands, or unauthorized access. <br>
• Correctness: Checks whether the agent follows the expected workflow and produces the correct final output. <br>
• Discoverability: Checks whether the agent loads the skill when relevant and avoids using it when irrelevant. <br>
• Effectiveness: Checks whether the agent performs measurably better with the skill than without it. <br>
• Efficiency: Checks whether the agent uses fewer tokens and avoids redundant work. <br>

Skill Version(s): <br>

0.1.0 (source: package.json) <br>

Ethical Considerations: <br>

NVIDIA believes Trustworthy AI is a shared responsibility and we have established policies and practices to enable development for a wide array of AI applications. When downloaded or used in accordance with our terms of service, developers should work with their internal team to ensure this skill meets requirements for the relevant industry and use case and addresses unforeseen product misuse. <br>

(For Release on NVIDIA Platforms Only) <br> Please report quality, risk, security vulnerabilities or NVIDIA AI Concerns here. <br>