Openclaw on Home

Tank OS: Running OpenClaw locally in a safe and open way

Sun, 14 Jun 2026 00:00:00 +0000

Tank OS packages OpenClaw as a rootless Podman workload inside a Fedora bootc VM - AI generated

Introduction

In this post, I want to describe how to run OpenClaw on a laptop using Tank OS, a Fedora bootc image that packages OpenClaw as a rootless workload inside an immutable operating system. This is a different path from the approach in the previous post on Deploying OpenClaw on OpenShift. Tank OS runs on a regular machine through a virtual machine. The result is the same agent, running locally without any cluster dependency.

What is Tank OS

Tank OS was created by Sally O’Malley, a principal software engineer at Red Hat and one of the OpenClaw maintainers. The project was published in April 2026, shortly after OpenClaw’s rise to the most-starred software repository in GitHub’s history. In the TechCrunch article that accompanied the release, O’Malley was direct about the risk: OpenClaw is “an incredibly powerful application” but one that can be “dangerous” without proper configuration. “It’s not a tool that you can use easily unless you do have some sort of technical experience,” she said. Tank OS is her response to that gap.

Tank OS packages OpenClaw inside a Fedora bootc image, which is a complete Linux operating system distributed as a container image. You do not install Tank OS on top of your existing OS. Instead, you build a QCOW2 disk image from the bootc image and boot it in a virtual machine. OpenClaw runs inside that VM as a rootless Podman container, isolated from the host.

Prerequisites

The following steps have been tested on a Apple Silicon MacBook. Before starting, the following must be in place:

Homebrew - the package manager for macOS, used to install QEMU
QEMU version 11 or later - the open source machine emulator used to run the Tank OS virtual machine: brew install qemu
Podman version 5 or later — the container engine used by the smoke-test script to pull the Tank OS image and run bootc-image-builder to produce the QCOW2 disk image
An SSH key pair at ~/.ssh/. The Tank OS image locks the default user’s password, so this key is the only way in.

If you do not have a key at that path, generate one:

ssh-keygen -t ed25519 -f ~/.ssh/github -C "tank-os"

Getting Started

The entry point to Tank OS is slightly unconventional, and worth explaining before running anything.

Rather than providing a traditional setup script, the Tank OS GitHub repository includes an agent prompt at the bottom of its README. The idea is that you copy that prompt, paste it into a coding agent such as Claude Code, and the agent handles the bootstrap: it clones the repository, inspects the structure, and produces the smoke-test.sh script that drives the actual workflow. Instead of reading through setup instructions and editing configuration by hand, you hand the prompt to the agent and get a runnable script back.

This is an uncommon way to explore a new project. The approach makes sense here because the setup involves several environment-specific details, including QEMU firmware paths, the difference between rootful and rootless Podman, and SSH key locations. An agent can adapt these to your machine setup without requiring manual edits to a configuration file.

Building, Booting, and Running OpenClaw

Once the agent has produced the smoke-test.sh script, the rest of the workflow runs through that script in four phases.

Phase 1: Building the Disk Image

First, make sure the default Podman machine is running:

podman machine init
podman machine start

Then run the build phase:

./smoke-test.sh build

This phase does several things automatically. It reads your SSH public key from ~/.ssh/github.pub and writes a config.json file that embeds the key into the disk image at build time. Without this step, the VM boots with no login path because the openclaw user password is locked in the default image.

Next, the script establishes a rootful Podman connection, required by the bootc-image-builder to write to the container storage, pulls the Tank OS image into the rootful store, and runs the bootc-image-builder as a privileged container to produce the QCOW2 disk image.

The output is then resized to 20 GB. The default 10 GB is not enough once the 3.5 GB OpenClaw container image and the OS are both on disk.

The build takes a few minutes. When it finishes, the QCOW2 file is in the output directory out-tank-os, ready to boot.

Terminal output once the build step completes.

Phase 2: Starting the VM

./smoke-test.sh vm

This starts QEMU with Apple’s Hypervisor Framework for acceleration, four virtual CPUs, 4 GB of RAM, and port forwarding from localhost:2222 to port 22 inside the VM. The VM boots using the UEFI firmware that Homebrew installs alongside QEMU.

The terminal shows the VM console as the OS starts. The OpenClaw Podman service launches automatically as a systemd user unit.

Phase 3: Connecting to OpenClaw

Open a second terminal and wait for the VM’s SSH daemon to accept connections, then log in:

until ssh -o ConnectTimeout=3 -o StrictHostKeyChecking=no \
 -i ~/.ssh/github -p 2222 openclaw@localhost true 2>/dev/null; do
 echo 'Waiting for VM...'; sleep 5
done && ssh -o StrictHostKeyChecking=no -i ~/.ssh/github -p 2222 openclaw@localhost

Once logged into the VM, verify the agent is running with:

podman ps

Terminal output shows OpenClaw running as Podman container inside the Fedora VM

Once inside the VM, retrieve the gateway authentication token:

jq -r '.gateway.auth.token' ~/.openclaw/openclaw.json

If the command returns nothing, generate a token first, then repeat:

openclaw doctor --generate-gateway-token

In a third terminal, open the SSH tunnel so the OpenClaw web interface is reachable from your browser:

ssh -N -o StrictHostKeyChecking=no -i ~/.ssh/github -p 2222 \
 -L 18789:127.0.0.1:18789 \
 -L 18790:127.0.0.1:18790 \
 openclaw@localhost

Open http://127.0.0.1:18789 in a browser. Paste the gateway token when prompted. The OpenClaw dashboard appears and the agent is ready.

OpenClaw Gateway Dashboard running locally

Adding a Model Provider

Tank OS stores API keys as Podman secrets rather than in configuration files. From inside the VM, create a secret for your provider:

printf '%s' "$ANTHROPIC_API_KEY" | podman secret create anthropic_api_key -
printf '%s' "$OPENAI_API_KEY" | podman secret create openai_api_key -
printf '%s' "$GEMINI_API_KEY" | podman secret create gemini_api_key -
printf '%s' "$OPENROUTER_API_KEY" | podman secret create openrouter_api_key -

Then sync it to the OpenClaw configuration and restart the service:

tank-openclaw-secrets
systemctl --user restart openclaw.service

This updates the OpenClaw configuration and restarts the service.

OpenClaw Dashboard running locally, configured to use Anthropic Claude Sonnet model

Conclusion

Tank OS is a practical way to get OpenClaw running on a laptop without modifying the host system. The agent runs inside a virtual machine on an immutable Fedora base, which limits what a misconfigured agent can reach on the host. Updating is also clean: pull a new bootc image and reboot, and the system reflects the new state.

For teams that already have OpenShift running, the claw-installer approach from the previous post is faster to deploy and integrates with cluster authentication out of the box. Tank OS is the right choice when you want a self-contained local setup that does not depend on a cluster, a cost-effective way to explore OpenClaw, or a portable environment to run a demo.

References

Tank OS - GitHub repository - link
Deploying OpenClaw on OpenShift - link
Sally O’Malley - GitHub Profile - link
Red Hat’s OpenClaw maintainer just made enterprise Claw deployments a lot safer - TechCrunch - link
Running the Red Hat AI Inference Server on OpenShift - link
Fedora bootc documentation - link

Deploying OpenClaw on OpenShift

Sun, 07 Jun 2026 00:00:00 +0000

The claw-installer automates the full OpenShift deployment in minutes, including authentication and TLS-terminated route - AI generated

Introduction

In this post, I want to describe how to deploy OpenClaw on OpenShift using a browser-based installer. It is possible to configure OpenClaw to use a self-hosted model endpoint. This post builds on Running the Red Hat AI Inference Server on OpenShift for the model serving layer and sits alongside the Hermes Agent deployment post as a second option for running an AI agent on the same cluster.

The two approaches are different in character. Hermes uses YAML manifests applied to OpenShift, requires a custom ServiceAccount with the anyuid SCC, and is configured through environment variables and a config file. For OpenClaw it is possible to leverage the claw-installer repository, a community supported tool that automates the deployment of OpenClaw on OpenShift. The claw-installer uses a browser-based installer that generates and applies all manifests, runs inside the default restricted-v2 SCC without elevated permissions, and handles OpenShift OAuth authentication automatically through a sidecar container.

What is OpenClaw

OpenClaw is an open-source agent framework designed to run on your own infrastructure. It connects to model providers, integrates with messaging platforms, and exposes a web interface for interacting with an agent.

Peter Steinberger created OpenClaw in late 2025. The project gained traction quickly: by early 2026 it had become the most-starred software project in GitHub’s history, overtaking repositories that had accumulated stars over decades. At the NVIDIA GTC keynote in March 2026, NVIDIA CEO Jensen Huang put it directly: “OpenClaw is the number one. It is the most popular open-source project in the history of humanity, and it did so in just a few weeks.”

GitHub Star History of OpenClaw relative to the Linux and React projects - [Source](https://www.star-history.com/blog/openclaw-surpasses-react-most-starred-software/)

The gateway is the always-on component. It manages sessions, routes requests between channels, dispatches tool calls, and emits events. On OpenShift, it runs as a three-container pod: an init container that handles startup configuration, an OAuth-proxy sidecar that ties authentication to the OpenShift OAuth server, and the OpenClaw gateway itself. The pod runs under the default restricted-v2 SCC.

OpenClaw supports the Model Context Protocol for tool integration. An mcp.json file placed in the agent workspace directory provisions MCP servers at deploy time, and the installer merges it into the main configuration.

Prerequisites

A running OpenShift cluster. The post Deploying OpenShift on AWS covers one way to get there.
The RHAIIS deployment from Running the Red Hat AI Inference Server on OpenShift running in the rhaiis namespace, or an external model provider API key if you prefer a AI model as a service.
Node.js 22 or later installed locally.

Deploying OpenClaw

Create a namespace:

oc new-project openclaw

Clone the installer:

git clone https://github.com/sallyom/claw-installer.git
cd claw-installer

Start the installer:

npm install && npm run build && npm run dev

The installer starts a local web server on port 3000. Open http://localhost:3000 in a browser.

Configure the deployment in the installer UI.

In the Deploy tab, select OpenShift as the deployment target. The installer reads the current oc context to detect the cluster and active namespace. Fill in the configuration form:

Agent Name: a name of your choice for your agent
Project / Namespace: the namespace to deploy the agent into, the installer pre-fills this from the current namespace in the oc context
Inference providers: add one or more model backends, for each provider specify the model endpoint, the model name, and the API key

OpenClaw Installer available at localhost:3000

If using RHAIIS as the model provider, the internal service DNS name keeps all model traffic inside the cluster. Retrieve the API key from the rhaiis namespace before filling in the form:

export MODEL_API_KEY=$(oc get secret vllm-api-key-secret -n rhaiis \
 -o jsonpath='{.data.VLLM_API_KEY}' | base64 -d)
echo $MODEL_API_KEY

Set the model endpoint to the internal cluster address:

http://rhaiis-vllm.rhaiis.svc.cluster.local:8000/v1

Click Deploy OpenClaw.

The installer generates and applies all manifests against the active cluster context. In the target namespace it creates a ServiceAccount with OpenShift OAuth annotations, secrets for the OAuth client and the gateway token, ConfigMaps for the agent configuration and workspace files, a 10Gi PVC backed by block storage, a Deployment running the three-container pod, a Service, and a TLS-terminated Route using the cluster wildcard certificate.

Once the pod reaches Running status, the OpenShift Topology view shows the deployment with two services: the gateway on port 18789 and the OAuth proxy on port 8443.

The openclaw deployment in the OpenShift Topology view, showing the pod, the gateway service on port 18789 and the OAuth proxy on port 8443 and the route

Retrieve the gateway token:

export OPENCLAW_HOST=$(oc get route openclaw -n openclaw \
 -o jsonpath='{.spec.host}')
export OPENCLAW_GATEWAY_TOKEN=$(oc get secret openclaw-secrets -n openclaw \
 -o jsonpath='{.data.OPENCLAW_GATEWAY_TOKEN}' | base64 -d)

echo "OPENCLAW_HOST : ${OPENCLAW_HOST}"
echo "OPENCLAW_GATEWAY_TOKEN : ${OPENCLAW_GATEWAY_TOKEN}"

Open the Route in a browser.

OpenShift OAuth handles authentication automatically. Log in with your cluster credentials when prompted. After login, the OpenClaw gateway dashboard appears. Paste the gateway token into the Gateway-Token field to authenticate the browser session with the running gateway.

The OpenClaw Gateway-Dashboard after the authentication step, showing the WebSocket connection URL and the Gateway-Token field used to authenticate the browser session

Approve the pairing in the installer.

Go back to the installer at http://localhost:3000, open the Instances tab, find the running instance, and click Approve Pairing. This confirms the connection between the local installer session and the cluster deployment.

The claw-installer Instances tab showing the openclaw deployment running on OpenShift, with the Approve Pairing control and other management options

Once the pairing is approved, the web interface is ready. The chat window connects to the configured model backend and the agent shows as ready. The OpenClaw dashboard can be used to further configure the agent, for example adding additional model providers or connecting messaging platforms.

OpenClaw Dashboard Overview

The OpenClaw gateway can expose an OpenAI-compatible API, so adding it as a connection in Open WebUI follows the same steps described in the Running the Red Hat AI Inference Server on OpenShift and Deploying Hermes Agent on OpenShift posts.

Conclusion

OpenClaw on OpenShift is a different path compared to the Hermes Agent deployment covered in the previous post. The installer handles all manifest generation from a web form, and the result is a running agent in minutes without writing any YAML. The OpenShift OAuth sidecar covers authentication from the start, using existing cluster credentials rather than a separately managed API key. The pod runs under the default restricted-v2 security policy, which matters in environments where elevated SCCs require explicit approval from a cluster administrator.

If RHAIIS is already running on the same cluster, pointing OpenClaw at the internal service address keeps all model traffic off the public network. Both agents can run on the same cluster in separate namespaces without any conflict.

References

Running the Red Hat AI Inference Server on OpenShift - link
Deploying Hermes Agent on OpenShift - link
claw-installer - GitHub repository - link
OpenClaw Project website - link
Peter Steinbergers GitHub Profile - link
OpenClaw surpasses React as most-starred software on GitHub - link
NVIDIA GTC 2026 Keynote - YouTube - link
Nvidia CEO Jensen Huang says OpenClaw is “definitely the next ChatGPT” - CNBC - link
Deploying OpenShift on AWS with Automated Cluster Provisioning - link
Deploying agents with Red Hat AI: The curious case of OpenClaw - link
OpenClaw - GitHub repository - link

Openclaw on Home

Tank OS: Running OpenClaw locally in a safe and open way

Tank OS packages OpenClaw as a rootless Podman workload inside a Fedora bootc VM - AI generated

Introduction

What is Tank OS

Prerequisites

Getting Started

Building, Booting, and Running OpenClaw

Phase 1: Building the Disk Image

Terminal output once the build step completes.

Phase 2: Starting the VM

Phase 3: Connecting to OpenClaw

Terminal output shows OpenClaw running as Podman container inside the Fedora VM

OpenClaw Gateway Dashboard running locally

Adding a Model Provider

OpenClaw Dashboard running locally, configured to use Anthropic Claude Sonnet model

Conclusion

References

Deploying OpenClaw on OpenShift

The claw-installer automates the full OpenShift deployment in minutes, including authentication and TLS-terminated route - AI generated

Introduction

What is OpenClaw

GitHub Star History of OpenClaw relative to the Linux and React projects - [Source](https://www.star-history.com/blog/openclaw-surpasses-react-most-starred-software/)

Prerequisites

Deploying OpenClaw

OpenClaw Installer available at *localhost:3000*

The openclaw deployment in the OpenShift Topology view, showing the pod, the gateway service on port 18789 and the OAuth proxy on port 8443 and the route

The OpenClaw Gateway-Dashboard after the authentication step, showing the WebSocket connection URL and the Gateway-Token field used to authenticate the browser session

The claw-installer Instances tab showing the openclaw deployment running on OpenShift, with the Approve Pairing control and other management options

OpenClaw Dashboard Overview

Conclusion

References

OpenClaw Installer available at localhost:3000