Run NemoClaw in a self-managed VPS test environment so the runtime lives inside a persistent remote boundary instead of on your local machine. NVIDIA currently labels NemoClaw as alpha/early-preview software and says not to use it in production environments. Treat this page as a controlled setup and review checklist, not a production deployment runbook. Virtarix provides the VPS infrastructure. You install, configure, secure, update, and operate the software you run on it. Virtarix Cloud VPS plans include NVMe storage, full root access, 3 live VPS locations, IPv4/IPv6, and an always-on server environment. Each VPS/VDS plan includes 1 free snapshot and 1 backup.
NemoClaw Control Panel
Sandbox Active
root@nemoclaw-vps:~$ nemoclaw my-assistant status --sandbox
> ✓ NemoClaw sandbox active. Preview limits noted.
Use this path when you want the shortest practical route from VPS order to a usable NemoClaw test workspace. The full checklist below expands each step.
This page is for users who want NemoClaw-related experiments to run inside a narrow, controlled VPS boundary instead of a local workstation.
Use a VPS when policies, permissions, logs, and runtime isolation need to be reviewed separately from daily local workstations.
Keep guardrail tests, command permissions, OpenShell-related requirements, and rollback notes in a dedicated server environment.
Use a disposable or tightly controlled VPS while comparing repository instructions, dependencies, and early-preview limitations.
Virtarix provides the VPS infrastructure. You install, configure, secure, update, and operate the software you run on it.
Before selecting a plan or installing NemoClaw, confirm server access, runtime path, credentials, firewall exposure, and recovery steps for the test deployment.
Use a Linux VPS that matches the current NemoClaw and OpenShell prerequisites, with Ubuntu as a practical target plus SSH and root or sudo access ready for host preparation.
Have basic terminal knowledge, Git, and the package managers required by the selected NemoClaw installation path.
Have Docker available before onboarding, or let the NemoClaw installer prepare Docker on supported Linux. Verify Node.js, npm, nvm or fnm shell paths, Docker group membership, and zstd where the selected path requires them.
Add other runtimes only when your selected provider, tools, repositories, or project workflows require them.
Prepare your own API keys, provider accounts, model access, repositories, configuration, domain or firewall rules, your own recovery backups, and the included snapshot/backup before persistent or sensitive changes. Do not place real secrets in shell history, public repositories, screenshots, support tickets, or shared logs.
Before running commands, decide how NemoClaw should be installed, updated, restarted, and recovered on the VPS. Use current upstream documentation as the authority for exact versions, flags, provider options, security policies, and alpha-status limitations.
Minimum practical starting point for a NemoClaw test environment:
The VPS is the runtime layer. You connect over SSH, configure NemoClaw, and control logs, state, and access. Review the NemoClaw VPS hosting page before scaling beyond testing.
You (Operator)
You connect over SSH and control the full workflow, configuration, security, and updates.
Virtarix VPS
Provides the persistent server with storage, networking, root access, snapshots, and backups.
NemoClaw Runtime
NemoClaw runtime layer and processes running on the VPS.
External Services
API and model providers, repositories, tools, and integrations that you connect and manage.
Follow this sequence as a practical test-deployment checklist, but confirm NemoClaw-specific versions, installer flags, provider names, and service commands against current official documentation before relying on the server.
Prepare the VPS, connect over SSH, and create a clean workspace before installing NemoClaw, OpenShell, and Docker-related prerequisites.
Deutsch
ssh root@YOUR_SERVER_IPsudo apt update && sudo apt upgrade -yCreate a dedicated non-root deployment user for day-to-day project work, then verify that user can connect by SSH and run sudo before disabling root or password login. Reconnect as the deployment user before installing or configuring the agent when your selected runtime path stores user-scoped configuration.
# Create a dedicated non-root user for day-to-day project work
adduser deploy
usermod -aG sudo deployCreate one directory tree for NemoClaw config examples, working files, logs, and backups. Keep secrets out of shell history and commit only templates, not real keys.
APP_HOME="$HOME/self-host-nemoclaw-on-vps-runtime"
mkdir -p "$APP_HOME/config" "$APP_HOME/workspace" "$APP_HOME/logs" "$APP_HOME/backups"
chmod 700 "$APP_HOME/config"
printf '%s\n' "# add real provider keys privately" > "$APP_HOME/config/env.example"
chmod 600 "$APP_HOME/config/env.example"Install base packages, follow the current upstream install path, and configure runtime/environment settings.
Install general tools first. Then install Docker Engine through the supported path for your Ubuntu release, or let the NemoClaw installer prepare Docker on supported Linux. If you add a user to the Docker group, open a new SSH session before checking Docker access as that user.
sudo apt update
sudo apt install -y git curl wget unzip ca-certificates gnupg zstd
if command -v docker >/dev/null 2>&1; then
sudo systemctl enable --now docker
docker --version
docker info || echo "Check Docker group membership or your approved Docker access path."
else
echo "Install Docker Engine or let the NemoClaw installer prepare it before onboarding."
fiNVIDIA’s current NemoClaw documentation lists Node.js 22.16 or later, npm 10 or later, Docker, and a tested Linux plus Docker path, with zstd needed for some local Ollama onboarding paths. NemoClaw is alpha/early-preview software and not for production environments. Use official NemoClaw documentation to confirm exact versions, supported providers, platform notes, and command syntax before relying on the server setup.
NVIDIA documents a guided installer that runs as a normal user, installs NemoClaw user-locally, onboards OpenClaw into an OpenShell-managed sandbox, and checks Docker before onboarding. Run the public installer only after reviewing NVIDIA’s prerequisites, third-party software notice, current release notes, and your organization’s script-execution policy. For stricter environments, download and inspect the installer script before executing it.
# Confirm Docker access from the deployment user first
docker info
# Official NemoClaw quickstart installer path
curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
# If the installer updated your shell path, source your shell config or open a new SSH session.
source ~/.bashrc
# The installer normally launches onboarding; if it prints a finish command, run that command.
nemoclaw list
nemoclaw status
nemoclaw my-assistant status
nemoclaw my-assistant logs --followFor NemoClaw, use the guided onboarding and NemoClaw inference configuration flow rather than assuming a generic repository environment-template workflow. Keep provider credentials, sandbox settings, policy files, and model-routing choices aligned with the current NemoClaw/OpenShell documentation. Replace the placeholders with provider names, model IDs, and sandbox names supported by the current NemoClaw documentation and your provider account.
nemoclaw my-assistant status
nemoclaw inference get
nemoclaw inference set --provider <provider> --model <model> --sandbox my-assistantAfter onboarding, use NemoClaw’s own lifecycle commands to inspect the sandbox and connect to the OpenClaw environment. Do not assume there is a host-level NemoClaw systemd unit unless you created one separately.
nemoclaw my-assistant status
nemoclaw my-assistant dashboard-url
nemoclaw my-assistant logs --follow
nemoclaw my-assistant connectKeep Docker and the selected NemoClaw sandbox observable, lock down access, test the setup, and plan ongoing maintenance.
Keep Docker running and use NemoClaw/OpenShell lifecycle commands for the sandbox. Avoid generic Docker Compose, raw container restart, or host-level service-manager commands unless the official path you selected explicitly creates and documents them.
sudo systemctl status docker --no-pager
nemoclaw my-assistant status
nemoclaw my-assistant doctor
nemoclaw my-assistant logs --followUse SSH keys where possible, restrict password login if appropriate, enable a firewall, expose only the ports NemoClaw/OpenShell actually needs, keep dashboard and gateway access loopback-only unless you intentionally tunnel it behind your own access controls, protect NemoClaw configuration, OpenShell policy files, sandbox settings, dashboard URLs, provider credentials, and Docker access, keep packages updated, and use your own backups or the included snapshot/backup before major changes.
Confirm Docker access from the deployment user, check NemoClaw sandbox status, run focused health checks, review logs, test provider authentication, inspect OpenShell policy behavior, test nemoclaw my-assistant connect --probe-only, restart the VPS, and confirm the sandbox, gateway, dashboard access, and configuration return cleanly.
NemoClaw is security-oriented, so the VPS should be treated as a controlled boundary for policies, logs, secrets, command permissions, and runtime experiments.
Use a VPS to keep guardrail experiments, allowed-command decisions, and OpenShell-related dependencies separate from personal machines.
Keep run output, service logs, policy notes, and failed authentication evidence in one server-side location.
Track API keys, outbound network rules, firewall policy, dashboard access, gateway access, and exposed service ports before adding real workloads.
Begin with the smallest possible access surface. Track policies, command permissions, network access, provider keys, dashboard access, logs, and rollback steps before adding real workloads.
Use SSH keys where possible.
Keep root login limited.
Use a non-root user where practical.
Restrict ports.
Keep dashboard URLs, gateway tokens, local forwards, and tunnels private; treat them like credentials.
Store provider credentials, sandbox settings, and policy material only in the NemoClaw/OpenShell configuration paths documented for your selected setup.
Avoid committing real NemoClaw config, OpenShell policy files, provider keys, sandbox settings, or credential reset notes.
Review SSH access logs, Docker/OpenShell runtime logs, policy-file changes, guarded-action audit trails, provider-key usage, and outbound network rules.
Keep packages updated.
Snapshot before major NemoClaw changes and record the rollback step.
Monitor failed login attempts.
Rotate exposed keys.
Keep experiments separate from production systems.
Document policy files, guardrail decisions, OpenShell-related requirements, allowed commands, outbound network rules, exposed ports, and rollback steps before real workloads are added.
The server can contain policy files, guardrail decisions, OpenShell-related requirements, allowed commands, outbound network rules, dashboard URLs, provider credentials, and security-review logs. Keep it isolated from production systems while NemoClaw remains alpha.
Common setup problems to check before blaming the VPS or framework.
Server firewall, wrong IP, or SSH service unavailable Confirm the VPS is running, check the IP, and verify port 22 or your configured SSH port.
Wrong key, wrong user, or disabled login method
Check ~/.ssh/authorized_keys, user permissions, and your SSH config.
Base packages or runtime packages were not installed Re-run the dependency step and compare Docker, Node.js, npm, zstd, provider, and platform requirements with official NemoClaw docs.
The selected NemoClaw path expects a different Node.js, Docker, or sandbox/runtime version Use the version manager or package source recommended by upstream docs.
Docker daemon stopped, not installed, or not reachable from the deployment user
Start Docker, confirm docker info works for the deployment user, open a fresh login session after group changes, and inspect NemoClaw/OpenShell logs.
Sandbox or gateway stopped after logout Use NemoClaw/OpenShell lifecycle commands and the documented sandbox runtime path rather than wrapping unknown host commands in a service manager.
A selected NemoClaw, OpenShell, sandbox, webhook, or supporting tool is bound to a port already used by another process
Run ss -tulpn and move one service to a different port.
A required NemoClaw, OpenShell, sandbox, webhook, or supporting tool port is not open Open only the required port and keep all other ports restricted.
Configuration is absent or incomplete Compare the generated configuration with the selected deployment path and add only the secrets, provider settings, policy presets, and paths required.
Key is wrong, expired, or lacks access Rotate the key through the provider and update the server configuration.
Logs, caches, Docker images, sandbox snapshots, or repositories grew over time
Check df -h, rotate logs, clean caches, remove unused images carefully, and scale storage if needed.
Too many sandbox processes, OpenShell components, Docker images, or background jobs Reduce concurrency, inspect process memory, and scale the VPS if the workload is valid.
You may not need a VPS if you are only testing NemoClaw locally, working from one private machine, reviewing a small repository, or experimenting without persistent SSH access.
This setup is not ideal if you do not want to manage Linux updates, SSH access, firewall rules, disk usage, credentials, or repository permissions yourself.
Use a VPS when the workspace, policy state, logs, tools, and OpenShell-protected workflow should stay available in a controlled remote environment.
Deploy a NemoClaw VPS and use this guide as your review checklist while you prepare a controlled, non-production setup.