How to Deploy NVIDIA NemoClaw on JarvisLabs

NVIDIA NemoClaw is an open-source reference stack that sandboxes autonomous AI agents at the kernel level. It uses OpenShell to run OpenClaw (an always-on AI assistant) inside a sandbox, enforcing filesystem isolation, network policies, and process restrictions so the agent cannot escape.

This guide walks through the setup we used to run NemoClaw with local Nemotron 3 Nano 30B inference on a JarvisLabs GPU VM. No cloud API keys. All numbers in this post are measurements from our own test run and will vary in your environment.

Caution: NemoClaw is in early preview (released March 16, 2026). APIs and runtime behavior may have breaking changes. Do not use this in production.

Tested Environment

Everything below is what we observed on a single test run. Treat the numbers as a reference point, not a specification.

On our test day, jl gpus did not list an A100 VM in any region, only A100 containers. If you want to run on A100 today, your option is the container, which loses anything installed via apt on pause and resume. Otherwise, run jl gpus at install time and pick whatever VM SKU has enough VRAM for the model.

Before You Start

• JarvisLabs account + jl CLI installed (installation guide)
• The Nemotron 3 Nano 30B model download is ~24GB
• NemoClaw pulls ~2.4GB of container images
• Total disk usage: ~35GB (well within the 100GB VM disk)

To install the CLI (requires uv):

uv tool install jarvislabs
jl setup  # interactive, enter your API token from jarvislabs.ai/settings

VMs require an SSH key registered on your JarvisLabs account. Add your local public key once:

jl ssh-key add ~/.ssh/id_ed25519.pub --name my-work-mac
jl ssh-key list

If you already see your key in jl ssh-key list, you can skip this.

Why a VM Instead of a Container

NemoClaw needs Docker (it runs OpenShell inside Docker, which manages a K3s cluster internally). It also requires Node.js, the openshell CLI, and several system-level packages. On a JarvisLabs container, anything installed via apt is lost when you pause and resume. A VM gives you full disk persistence, so you set up once and everything survives pause/resume.

The tradeoff: VMs have a public IP, which means you need to set up a firewall. We cover that below.

NemoClaw Installation

Step 1: Create a VM

List what is currently available and pick a VM SKU with enough VRAM:

jl gpus

Then launch the VM. We used an H100 VM in IN2 because A100 VM was unavailable that day:

jl create --gpu H100 --region IN2 --vm --name nemoclaw-agent

Substitute the GPU and region you picked from jl gpus. Note the instance ID the CLI prints back.

SSH in using the JarvisLabs CLI (this handles the host key and the right user for you):

jl ssh <instance-id>

If you prefer the raw SSH command, jl ssh --print-command <instance-id> prints it.

All remaining commands run on the VM unless stated otherwise.

Step 2: Lock Down the Firewall

VMs have a public IP. Before installing anything, set up UFW to block incoming traffic except SSH:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw --force enable

On our JarvisLabs VM, NemoClaw's sandboxed containers could not reach the host Ollama server until we allowed Docker and K3s internal networks on port 11434. These were the CIDRs we needed:

sudo ufw allow from 172.17.0.0/16 to any port 11434 proto tcp
sudo ufw allow from 172.18.0.0/16 to any port 11434 proto tcp
sudo ufw allow from 10.42.0.0/16 to any port 11434 proto tcp

These CIDRs are what the Docker and K3s defaults used on our VM. NemoClaw's primary docs do not specify them, and they may differ in your environment. If onboarding later fails because the sandbox cannot reach Ollama, check docker network ls, docker network inspect, and kubectl get pods -A -o wide for the actual ranges in use and add rules to match.

Step 3: Install Ollama

curl -fsSL https://ollama.com/install.sh | sh

Expected output: >>> NVIDIA GPU installed.

Step 4: Configure Ollama to Listen on All Interfaces

By default, Ollama only listens on 127.0.0.1. NemoClaw's sandbox runs inside a container, so it needs Ollama listening on 0.0.0.0:

sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf > /dev/null <<EOF
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
EOF
sudo systemctl daemon-reload
sudo systemctl restart ollama

Verify it's listening correctly:

curl -s http://localhost:11434/api/tags

Expected output: {"models":[]} (empty because we haven't pulled a model yet).

Step 5: Pull the Nemotron Model

ollama pull nemotron-3-nano:30b

This downloads roughly 24GB of model weights. The pull time depends heavily on the datacenter network at the moment you run it, so do not calibrate off a specific number.

Expected output: success after the download completes.

Step 6: Verify Docker

Docker was pre-installed and active on the JarvisLabs VMs we tested. Confirm before moving on:

systemctl is-active docker

If it prints active, you are done. Otherwise, start it and make sure your user can talk to the socket without sudo:

sudo systemctl start docker
sudo systemctl enable docker
sudo usermod -aG docker $USER
newgrp docker

The newgrp docker applies the group change to the current shell. Without it, the NemoClaw installer fails with Docker permission errors.

Step 7: Install NemoClaw

curl -fsSL https://www.nvidia.com/nemoclaw.sh | \
  NEMOCLAW_NON_INTERACTIVE=1 \
  NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 \
  NEMOCLAW_PROVIDER=ollama \
  NEMOCLAW_MODEL=nemotron-3-nano:30b \
  bash

NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 is required for the non-interactive path. Without it, the script exits before onboarding because it cannot prompt you to accept third-party licenses.

The script installs the NemoClaw CLI, then runs non-interactive onboarding. The onboarding step's preflight can auto-install OpenShell if it is missing.

Expected output: onboarding walks through a numbered [i/N] sequence (preflight, starting the OpenShell gateway, configuring and setting up inference, creating the sandbox, setting up OpenClaw, applying policy presets, and a final summary). The exact step labels and count shift between versions, so treat what scrolls past as progress indicators rather than a contract. Creating the sandbox is the slow step on a cold VM because it pulls the sandbox image.

When the build finishes you should see a summary along the lines of:

Sandbox      my-assistant (Landlock + seccomp + netns)
Model        nemotron-3-nano:30b (Local Ollama)

If onboarding fails during the inference setup step with containers cannot reach host.openshell.internal:11434, the sandbox cannot reach Ollama. Recheck the firewall rules from Step 2, confirm the Docker and K3s CIDRs actually in use, and rerun the installer.

Step 8: Verify Inference

Test that Ollama is serving the model correctly on the host:

curl -sf http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"nemotron-3-nano:30b","messages":[{"role":"user","content":"What is the capital of France? Reply in one sentence."}]}'

Expected output: A JSON response with "choices" containing the model's reply. The first query takes a few seconds while the model loads into GPU memory. In our test run, warm queries were faster, but actual latency depends on prompt length, GPU, and current load.

This verifies Ollama on the host. The NemoClaw sandbox routes inference through inference.local internally, and the onboarding wizard already validated that path.

Step 9: Connect to the Sandbox

nemoclaw my-assistant connect

This drops you into a sandboxed shell. From here, launch the OpenClaw chat interface:

openclaw tui

You're now chatting with Nemotron 3 Nano 30B through a sandboxed agent. Network requests, filesystem access, and process behavior inside the sandbox are intended to be governed by NemoClaw's policies, subject to the active policy and what the host kernel supports (Landlock enforcement is best effort).

Step 10: Clean Up

When you're done, exit the SSH session and pause from your local machine to stop billing. Find the instance ID with jl list:

jl list
jl pause <instance-id>

Because this is a VM, disk state persists across pause and resume. To come back later:

jl resume <instance-id>
jl ssh <instance-id>

jl resume may return a new instance ID if the original machine is no longer available. Use whichever ID it prints when you SSH back in.

Once you're back on the VM, check the services before trying to attach to the sandbox:

systemctl is-active docker ollama
nemoclaw my-assistant connect

If Docker or Ollama is inactive, start them with sudo systemctl start docker ollama, give the OpenShell gateway a few seconds to come back, then rerun nemoclaw my-assistant connect.

How NemoClaw Security Works

NemoClaw layers several Linux kernel isolation mechanisms around the agent. Exact guarantees depend on the active policy and on host kernel support, so read this as a mental model rather than a contract.

Landlock restricts filesystem access. In the current baseline policy, /sandbox is read-only with a small set of writable subpaths (for example /sandbox/.openclaw-data, /sandbox/.nemoclaw, /tmp, and /dev/null). System directories are not writable. NemoClaw's hardening docs explicitly describe Landlock enforcement as best effort, because older kernels have less coverage.

seccomp filters system calls. The filter blocks dangerous paths such as ptrace and mount-related syscalls that would otherwise let the agent break isolation.

Network namespaces scope network access. Outbound traffic is not allowed by default. The agent can only reach endpoints that the active policy or an added preset allows, and policy-managed outbound access and inference are routed through OpenShell controls.

Inference routing keeps provider credentials out of the sandbox. When the agent calls the model, the request targets inference.local inside the sandbox, and the gateway routes it to the real provider (Ollama on localhost in our setup). API keys for hosted providers never enter the sandbox process.

The baseline policy is deliberately narrow. It includes things like inference and the npm registry, but broader access (for example GitHub, Telegram, Discord, PyPI) is added through named presets, not enabled by default. Run nemoclaw my-assistant policy-list to see what is active and nemoclaw my-assistant policy-add to opt in. Check NVIDIA's network policy docs for the current baseline list before trusting it for any specific workload.

NemoClaw Troubleshooting

Cost and GPU Requirements

Run jl gpus when you're ready to launch and pick a VM with enough VRAM for Nemotron 3 Nano 30B. In our test run on H100, Ollama reported total model memory around 26.1 GiB, which rules out 24GB cards for any real context length. A 40GB or 80GB card gives comfortable headroom.

We don't publish a tutorial-wide cost number because it depends directly on which SKU you pick and how long you keep the VM running. Multiply the hourly rate from jl gpus by your actual wall-clock time.

What is NemoClaw?

NemoClaw entered early preview on March 16, 2026. It is NVIDIA's reference stack for running autonomous AI agents inside a kernel-level sandbox so that web browsing, code execution, and filesystem access can be scoped with an explicit policy instead of trust.

The stack has four layers:

1. NemoClaw CLI, a TypeScript tool that drives the whole workflow
2. NemoClaw Blueprint, Python orchestration for sandbox and policy management
3. OpenShell, the runtime that creates and manages the sandboxed containers
4. OpenClaw, the AI assistant framework that actually runs inside the sandbox

NemoClaw is Apache 2.0 licensed and in early preview. It supports NVIDIA Endpoints, OpenAI, Anthropic, Google Gemini, and local inference via Ollama.

• GitHub: NVIDIA/NemoClaw
• Docs: docs.nvidia.com/nemoclaw
• Ollama integration: docs.ollama.com/integrations/nemoclaw

What We Learned

1. Firewall rules were the main networking gotcha on our JarvisLabs VM. NemoClaw runs containers inside Docker inside K3s, and they need to reach Ollama on the host. UFW blocks that by default, so we had to allow the Docker and K3s CIDRs actually in use on port 11434. If you hit containers cannot reach host.openshell.internal:11434, start here.

2. Ollama's default bind address breaks containerized setups. In our setup, the sandbox could not reach Ollama until we used a systemd override to set OLLAMA_HOST=0.0.0.0. Any guide that runs Ollama alongside Docker containers on the same host tends to hit this.

3. VMs work well for NemoClaw on JarvisLabs because the disk persists across pause and resume. The stack has deep system dependencies (Docker, K3s, Node.js, multiple container images). On a container instance, anything installed through apt is lost at pause and has to be redone, so a VM removes that friction.

If you want to try this yourself, sign in to JarvisLabs and run through the steps above. We'd love to hear where your numbers land.