NemoClaw User Deploy Remote

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.

Step 1: 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.

Step 2: 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 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 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.

Step 3: 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>

Step 4: Monitor the Remote Sandbox

SSH to the instance and run the OpenShell TUI to monitor activity and approve network requests:

$ ssh <instance-name> 'cd /home/ubuntu/nemoclaw && set -a && . .env && set +a && openshell term'

Step 5: Verify Inference

Run a test agent prompt inside the remote sandbox:

$ openclaw agent --agent main --local -m "Hello from the remote sandbox" --session-id test

Step 6: 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. If you disable device auth for a remote deployment, any device that can reach the dashboard origin can connect without pairing. Avoid this on internet-reachable or shared-network deployments.

Step 7: 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. 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.

Step 8: 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>

Telegram, Discord, and Slack reach your agent through OpenShell-managed processes and gateway constructs. NemoClaw configures those channels during nemoclaw onboard. Tokens are registered with OpenShell providers, channel configuration is baked into the sandbox image, and runtime delivery stays under OpenShell control.

nemoclaw start does not start Telegram (or other chat bridges). It only starts optional host services such as the cloudflared tunnel when that binary is present. For details, refer to Commands (see the nemoclaw-user-reference skill).

Step 9: Create a Telegram Bot

Open Telegram and send /newbot to @BotFather. Follow the prompts to create a bot and copy the bot token.

Step 10: Provide the Bot Token and Optional Allowlist

Onboarding reads Telegram credentials from either host environment variables or the NemoClaw credential store (getCredential / saveCredential in the onboard flow). You do not have to export variables if you enter the token when the wizard asks.

Option A: Environment variables (CI, scripts, or before you start the wizard)

$ export TELEGRAM_BOT_TOKEN=<your-bot-token>

Optional comma-separated allowlist (maps to the wizard field “Telegram User ID (for DM access)”):

$ export TELEGRAM_ALLOWED_IDS="123456789,987654321"

Option B: Interactive nemoclaw onboard

When the wizard reaches Messaging channels, it lists Telegram, Discord, and Slack. Press 1 to toggle Telegram on or off, then Enter when done. If the token is not already in the environment or credential store, the wizard prompts for it and saves it to the store. If TELEGRAM_ALLOWED_IDS is not set, the wizard can prompt for allowed sender IDs for Telegram DMs (you can leave this blank and rely on OpenClaw pairing instead). NemoClaw applies that allowlist to Telegram DMs only. Group chats stay open by default so rebuilt sandboxes do not silently drop Telegram group messages because of an empty group allowlist.

Step 11: Run nemoclaw onboard

Complete the rest of the wizard so the blueprint can create OpenShell providers (for example <sandbox>-telegram-bridge), bake channel configuration into the image (NEMOCLAW_MESSAGING_CHANNELS_B64), and start the sandbox.

Channel entries in /sandbox/.openclaw/openclaw.json are fixed at image build time. Landlock keeps that path read-only at runtime, so you cannot patch messaging config inside a running sandbox.

If you add or change TELEGRAM_BOT_TOKEN (or toggle channels) after a sandbox already exists, you typically need to run nemoclaw onboard again so the image and provider attachments are rebuilt with the new settings.

NemoClaw stores a SHA-256 hash of each messaging token in the sandbox registry at creation time. When you re-run nemoclaw onboard --non-interactive with a new token, NemoClaw detects the change, backs up workspace state, deletes the sandbox, recreates it with the new credential, and restores the backup. This makes credential rotation safe to script.

Telegram, Discord, and Slack each allow only one active consumer per bot token. If you enable a messaging channel and another sandbox already uses the same token, onboard prompts you to confirm before continuing in interactive mode and exits non-zero in non-interactive mode. nemoclaw status also reports cross-sandbox overlaps so you can resolve duplicates before messages start dropping.

For a full first-time flow, refer to Quickstart (see the nemoclaw-user-get-started skill).

Step 12: Confirm Delivery

After the sandbox is running, send a message to your bot in Telegram. If something fails, use openshell term on the host, check gateway logs, and verify network policy allows the Telegram API (see Customize the Network Policy (see the nemoclaw-user-manage-policy skill) and the telegram preset).

Step 13: nemoclaw start (cloudflared Only)

nemoclaw start starts cloudflared when it is installed, which can expose the dashboard with a public URL. It does not affect Telegram connectivity.

$ nemoclaw start

Reference

• Sandbox Image Hardening

Related Skills

• nemoclaw-user-monitor-sandbox — Monitor Sandbox Activity for sandbox monitoring tools
• nemoclaw-user-reference — Commands for the full deploy command reference