In a previous article, we saw how to deploy OpenClaw on Nutanix AHV. However, before you can fully enjoy this autonomous AI agent, it is crucial to prepare the ground. OpenClaw is not just a simple script: it’s an ecosystem that relies on several technological building blocks to “think” (local LLM), “execute” (Node.js) and “search” (SearXNG).

In this article, we are going to detail the step-by-step installation of all the necessary prerequisites on your virtual machine (running Ubuntu), explaining for each one why it is essential for OpenClaw to work properly.

1. NVIDIA Drivers: Unleashing GPU Power

OpenClaw can rely on large language models (LLMs) running locally. While it is technically possible to run these models on a processor (CPU), performance would be extremely slow. Installing NVIDIA drivers allows the system to leverage the graphics card (GPU) allocated to your VM via Nutanix AHV (vGPU or Passthrough), thereby ensuring fast and smooth AI inference.

Here is how to update your system and install the appropriate drivers:

# System update
sudo apt update && sudo apt upgrade -y

# NVIDIA server driver installation
sudo apt install nvidia-driver-535-server -y

# Reboot required to take effect
sudo reboot

After the reboot, check that your GPU is correctly recognized with the following command:

nvidia-smi

2. Node.js (v24): OpenClaw’s Execution Engine

The core logic of OpenClaw is developed in JavaScript/TypeScript. Node.js is the execution environment that allows running the agent’s code, managing its dependencies, and orchestrating calls between the interface, the AI model, and the various tools. We are targeting version 24.x here to ensure optimal compatibility.

# Adding the NodeSource repository and installing
curl -fsSL [https://deb.nodesource.com/setup_24.x](https://deb.nodesource.com/setup_24.x) | sudo -E bash -
sudo apt install -y nodejs

# Verifying the installed version
node --version  # should display v24.x

3. Ollama & Qwen 2.5: The Local Brain of the Operation

Ollama is the tool that will allow us to easily download and run our AI model locally. For OpenClaw, we are going to use the Qwen2.5 (7B) model. Why this choice? It’s a lightweight model (suitable for GPUs with about 8 GB of VRAM) and, above all, it is excellent at “Tool Calling”. It is this capability that allows OpenClaw to understand that it needs to execute a web search or run a script rather than simply generating text.

# Installing Ollama
curl -fsSL [https://ollama.ai/install.sh](https://ollama.ai/install.sh) | sh

# Start the Ollama service (in the background)
ollama serve &

# In another terminal, verify that Ollama detects the GPU:
nvidia-smi  # You should see ollama in the list of GPU processes

# Pull (download) the recommended model
ollama pull qwen2.5:7b

# Test the model and verify its execution on the GPU
ollama run qwen2.5:7b "say hello"

# While the model is generating a response, check VRAM usage
nvidia-smi

4. Docker: The Containerization Infrastructure

In order to extend OpenClaw’s capabilities (especially for web search which we will see next), we need third-party services. Docker allows these services to be deployed in an isolated, standardized, and fast manner, without polluting our host system with multiple complex dependencies.

# Installing initial dependencies
sudo apt update
sudo apt install -y ca-certificates curl gnupg

# Adding Docker's official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL [https://download.docker.com/linux/ubuntu/gpg](https://download.docker.com/linux/ubuntu/gpg) | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Configuring the Docker repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  [https://download.docker.com/linux/ubuntu](https://download.docker.com/linux/ubuntu) \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Installing Docker packages
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Adding your user to the docker group to avoid using 'sudo' every time
sudo usermod -aG docker $USER
newgrp docker

# Verifying the installation
docker --version

5. SearXNG: Giving AI Access to the Web

For OpenClaw to be a truly performant search agent, it cannot rely solely on the data contained in the Qwen model (which stops at its training date). SearXNG is a privacy-respecting metasearch engine. By installing it via Docker, we provide OpenClaw with an API (on port 8080) that it can use to retrieve real-time information from the web and source its answers.

# Create a dedicated directory for configuration
mkdir -p ~/searxng && cd ~/searxng

# Run the SearXNG container
docker run -d \
  --name searxng \
  --restart unless-stopped \
  -p 8080:8080 \
  searxng/searxng

# Verify that the container is running correctly
docker ps

# Test that the SearXNG API is responding
curl http://localhost:8080

6. Homebrew & GCC: The Compilation Tools

The OpenClaw Node.js ecosystem sometimes relies on low-level libraries or native packages that need to be compiled directly on your machine during installation. Homebrew (the well-known package manager on macOS, also very handy on Linux) and the GCC compiler are essential to avoid errors during the final dependency installation phase (the famous npm install).

# Install the base Ubuntu compilation package
sudo apt-get install build-essential

# Install Homebrew
/bin/bash -c "$(curl -fsSL [https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh](https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh))"

# The end-of-installation instructions for Homebrew will ask you
# to add Homebrew to your PATH. Generally, it looks like this:
# (Make sure to adapt the path if necessary)
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /home/$USER/.bashrc
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

# Install GCC via Homebrew
brew install gcc

Conclusion

Your virtual machine on Nutanix AHV is now a rich and complete environment, equipped with high-performance GPU drivers, an execution engine (Node.js), an LLM ready to answer (Ollama), web access (SearXNG), and the right compilation tools.

The groundwork is perfectly laid. All that’s left is for you to finalize the installation of the application itself by following the rest of our guide on OpenClaw.

If you follow my ramblings on the blog, you know I love tinkering with my clusters and testing somewhat out-of-the-box stuff (cf. my Steamdeck articles for example). Recently, I had a thought: Gemini or Claude in the public cloud is great for coding a Python script or writing emails. But when it comes to asking it to interact with our local infrastructure, that’s where it gets stuck.

So I wondered how I could connect artificial intelligence closer to my VMs. With this in mind, I got my hands on OpenClaw. Honestly, it was a bit of an obstacle course at the start. No more simple conversational gadgets, here we are talking about deploying a true Private AI on a Nutanix AHV cluster capable of acting on our infrastructure. Let me present the tech stack I chose for this experiment.

What is OpenClaw?

For those who have been living in a cave these past few months, OpenClaw is a GitHub project that exceeded 300k stars in just a few months. Imagine an ultra-intelligent thought translator coupled with a butler. Instead of clicking through dozens of menus in a complex interface, you simply ask your infrastructure to work for you in natural language (via a universal web interface or even messaging apps like WhatsApp and Telegram). It is even capable of working on its own while you sleep!

But where it gets exciting for us engineers is under the hood. OpenClaw is not just another “stateless” Large Language Model (LLM) that forgets everything with each new request. It is a true Agentic Gateway. Concretely, this means it orchestrates autonomous agents equipped with tools. These agents can be configured to tap directly into our cluster’s private APIs (like the REST APIs of Prism Element or Prism Central), code, browse the web, and synthesize certain information. In short, we don’t just ask the AI questions anymore, we delegate tasks to it.

Why Self-hosted?

In the field, the question of data governance arises the second the word “AI” is pronounced. Out of the question to send sensitive information to servers over which I have no control!

Choosing the Self-hosted route with OpenClaw means taking back absolute control. Data flows, execution logs, and API credentials stay locked down warm and safe on my network, isolated from the internet if desired.

Architecture and Tech Stack

For this project, a simple “Next, Next, Finish” on the corner of a table was out of the question. Here is the robust technical architecture I ended up validating for my deployment.

The Foundation: Nutanix AHV & Ubuntu 24.04 LTS

To run this beast, you need solid foundations. I provisioned a virtual machine running Ubuntu 24.04 LTS hosted directly on my Nutanix AHV cluster.

On the sizing side, I went with 8 vCPUs, 32 GB of RAM, and 250 GB of dedicated storage. You might tell me: “32 GB for a gateway, isn’t that a bit too much?” The gateway will have to ingest substantial data streams, maintain the cache of the various active agents, and potentially handle heavy parallel API querying. And besides, I can allocate these resources in my lab, so why deprive myself?

The Application Engine: NodeJS 22

At the heart of OpenClaw, the magic happens thanks to NodeJS 22. It is the execution engine that runs the gateway and its AI agent integrations.

Why is Node 22 an excellent architectural choice here? For its asynchronous management (Event Loop). When you ask OpenClaw to do a status report on 50 VMs, the gateway will initiate multiple API calls to Prism Central while keeping your WebSocket stream open to reply in real-time in the chat interface. NodeJS excels in this non-blocking concurrency management.

Network Routing: Caddy

The usual operating mode for OpenClaw is to deploy it locally on the machine from which you will connect to it, or to set up a tunnel to access the remote instance. Let’s not lie to ourselves, I wanted to type the IP in my browser and be able to access my instance, whether I’m on my PC or my tablet.

To make this possible, I use a Caddy Reverse Proxy. Caddy manages traffic routing and HTTPS encryption fully automatically.

I can already hear you saying: “Yes, but if a guy connects to your local network, he will have access to your instance!”. Well no! Because OpenClaw natively integrates a Device Whitelisting system. If your PC has never been connected to the instance, you will have to provide the “Gateway Token”. Then, you will have to accept this new connection on the OpenClaw instance side. As you can see, only previously authorized devices can enjoy your local instance.

The Entry Point: Discord

The choice of entry point, which will allow you to interact with OpenClaw, is often a matter of taste and colors.

OpenClaw directly integrates a chat system so you can talk to it. It’s good, it’s native, but inaccessible if I’m not at home. The system also offers to configure external entry points like Telegram, WhatsApp, Discord, or even Teams and Slack. And that is clearly a big plus because it gives almost unlimited possibilities!

What’s Next?

The goal of this article was to present the architecture envisioned for my OpenClaw assistant, to understand what we are deploying and why. We therefore have a coherent technical stack, performant thanks to Nutanix AHV, and hosted locally.

In a future article, I will explain how to install OpenClaw step by step until you have a functional instance.