Tools 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

Mirroring Red Hat Documentation Locally with rh-mastery

Sat, 13 Jun 2026 00:00:00 +0000

Workflow diagram of rh-mastery process - AI generated

Introduction

In this post, I want to describe a tool built by my team mate Francisco J. Lopez Grüber that solves a problem most people quietly live with: Red Hat product documentation is comprehensive and well-maintained, but it lives on the internet. Accessing it requires a browser, a connection, and knowing where to look. For offline environments, air-gapped labs, or anything beyond casual browsing, that dependency quickly becomes friction.

rh-mastery addresses this directly. It mirrors Red Hat product documentation from docs.redhat.com as PDF files into a local directory tree, and optionally can convert those PDFs to Markdown. The Markdown output is where things get particularly interesting: combined with tools like qmd from Shopify CEO Tobias Lütke, the converted documentation becomes a local knowledge base that AI agents can query directly — no internet access required, no context switching, and no copy-pasting from browser tabs. For anyone building AI-assisted developer workflows, having structured access to accurate, version-tracked product documentation is a meaningful step up.

The tool is available on GitHub at flg-redhat/rh_mastery.

What rh-mastery Does

At its core, rh-mastery handles two tasks:

Sync: For a given product alias or slug, it probes docs.redhat.com, resolves the current documentation version, and downloads all available PDFs into a structured local directory tree: {download_base}/{slug}/{version}/.
Convert: Once PDFs are present, the convert command transforms them into Markdown files using PyMuPDF4LLM (default) or Docling as an optional heavier-weight alternative. Each Markdown file includes a short YAML front matter block with provenance metadata — title, source, version, and conversion timestamp.

Individual products can be targeted using short aliases such as --ocp or --ansible, or by passing the full Red Hat documentation slug directly. To download the complete documentation for all tracked products at once, rh-mastery sync --all handles that in a single invocation.

The recommended way to run rh-mastery is via its container image, which keeps dependencies isolated and makes the workflow reproducible.

Setting Up the Environment

The image is built from Red Hat Universal Base Image 10 Init and includes systemd, allowing for optional scheduled syncs via timers or cron inside the container. Build it from the repository root:

git clone https://github.com/flg-redhat/rh_mastery
cd rh_mastery
podman build -f Containerfile -t rh-mastery:latest .

Create a local data/ directory to hold the downloaded files. This directory will be mounted into the container, so its contents persist across container restarts and recreations.

mkdir -p data

The Workflow

The end-to-end workflow from a fresh image to a set of Markdown files ready for distribution follows five steps.

Start the container

podman run -d --name rh-mastery \
 --systemd=always --rm \
 -v ./data:/var/lib/rh-mastery:Z \
 rh-mastery:latest

This starts the container in detached mode and mounts the local data/ directory into /var/lib/rh-mastery inside the container. All downloads and converted files will appear under data/ on the host.

Open an interactive shell

podman exec -it rh-mastery bash

Sync the documentation

rh-mastery sync --all

This downloads the current documentation for all tracked products into the mounted volume. Individual products can be synced using their alias, for example rh-mastery sync --ocp or rh-mastery sync --ansible. Run rh-mastery --help inside the container to see the full alias table.

Convert PDFs to Markdown

rh-mastery convert --all

This converts every synced PDF into a Markdown file alongside it. Both the original PDFs and the converted Markdown files are present after this step. The conversion uses PyMuPDF4LLM by default, which handles most layouts well. For documents with complex tables or multi-column layouts, the --engine docling option is available but requires installing additional dependencies.

Exit the container and clean up PDFs (optional step)

Once conversion is complete, exit the container shell. Depending on the use case, the original PDF files may no longer be needed, if Markdown is the target format, removing the PDFs reduces the total size of the data directory significantly:

exit
find ./data/RHDocumentation -name "*.pdf" -delete

The Markdown files in data/RHDocumentation are now ready for local use, distribution, or ingestion by an AI agent.

From Markdown to AI Agent Knowledge

The Markdown output from rh-mastery is structured and annotated, which makes it well-suited for ingestion by AI agents and local language model tooling. Each file carries front matter metadata that allows agents to identify the product, version, and source, and the content retains the section hierarchy of the original documentation.

qmd, built by Tobias Lütke, is a lightweight tool for querying local Markdown files. Pointed at the directory tree produced by rh-mastery, it gives AI agents fast, accurate access to the full Red Hat documentation corpus, entirely offline and without relying on external APIs or web retrieval. The combination is particularly effective in environments where internet access is restricted, or when a development workflow benefits from a self-contained, version-locked knowledge source.

Conclusion

rh-mastery turns what would otherwise be an ongoing manual effort into a single repeatable command. The container image keeps the setup clean, and the Markdown output opens up practical AI-assisted use cases that go beyond what a standard documentation browser can offer. Francisco’s tool fills a gap that is easy to overlook until you actually need it.

References

rh-mastery - GitHub repository by Francisco J. Lopez Grüber - link
qmd - GitHub repository by Tobias Lütke - link
Red Hat product documentation - link

Hermes Agent: A Personal AI That Gets More Useful Over Time

Sat, 02 May 2026 00:00:00 +0000

How Hermes Agent Works: From Closed-Loop Learning to Multi-Platform Deployment - AI generated

Introduction

I came across the Hermes Agent project in early March 2026 and deployed it a couple of days later. A couple of weeks in I am still using it daily, and the use cases keep expanding rather than converging. Most tools settle into a narrow routine or fall off altogether. What keeps this one going is that the agent gets more useful the longer you run it. The project is young and moving fast, with new releases every few days. The initial setup requires patience: getting the configuration to a point where it actually saves time takes effort, and the frequent updates occasionally introduce breaking changes. That said, it is genuinely fun to use, and you learn a fair amount along the way.

Hermes Agent is an open-source, self-hosted AI agent framework built by Nous Research, an independent AI research lab based in New York. Nous Research is best known for the Hermes model family, a series of open-weight models fine-tuned on Llama that are used widely in the open-source AI community. The agent framework shares the name but is a separate project. It is MIT-licensed, model-agnostic, and runs on your own infrastructure, either as a self-hosted Python service or as a containerized deployment.

How It Works

The part that makes Hermes Agent different from most agent frameworks is the skill system. The agent ships with a set of preconfigured skills covering common tasks. Beyond that, you can ask it to create a skill from something it just did: it writes a structured Markdown document capturing the approach, what worked, and describes possible edge cases. The next time a similar task appears, the agent loads the relevant skill rather than starting from scratch. Skills can be triggered directly by asking Hermes to run one, or set on a schedule and executed automatically at defined intervals. Over time this turns completed work into a growing library of reusable operating knowledge. Version v0.12.0 added an Autonomous Curator to keep that library from growing unwieldy. It runs on a seven-day cycle by default, grades skills by usage, consolidates overlapping ones, and removes those that have stopped being useful. A short report is written after each run, so you can see what changed and why.

Alongside the skill system, the agent maintains three layers of memory: a persistent store for completed tasks and notes, a full-text search index across prior sessions, and a user model that accumulates preferences over time, coding style, communication tone, timezone, tools. The idea is that the agent gets more useful the longer you run it, not just better at individual tasks in isolation.

My Setup

Hermes Agent runs in my homelab as a service on a dedicated Linux host. Keeping it on a separate machine gives me direct control over what the agent has access to. Incoming traffic is routed through Traefik. I access it through three entry points depending on where I am and what I am doing. The primary interface is the Matrix chat protocol, which means I can reach the agent from any Matrix client on any device. I also connected it to a dedicated email inbox, so it can handle certain tasks asynchronously. For longer sessions at my desk I use Open WebUI, which gives a more comfortable interface for extended conversations.

The model configuration is versatile: the agent supports various AI services and model providers.

What I Gave It Access To

I gave the agent access to three local knowledge sources: my bookmarks, a structured knowledge base, and a local mirror of Red Hat’s product documentation.

The first is my bookmarks folder. I have been saving links as Markdown files in Obsidian for several years. The agent can search and cross-reference that collection when doing research, which means it draws on context I actually care about rather than training data alone.

The second is a knowledge base built on the LLM Wiki principle described by Andrej Karpathy. The idea is to maintain a curated set of structured Markdown files that an AI agent helps write and update over time. Topics, entities, comparisons, each in its own file. The agent both contributes to this knowledge base and draws from it when working on research tasks.

The third is a local mirror of Red Hat’s product documentation. A team mate built a tool called rh-mastery that pulls documentation from docs.redhat.com, converts it to Markdown, and stores it in a structured local directory. Pointed at that directory, Hermes can query accurate, version-tracked product documentation without touching the internet. For someone who spends a lot of time with Red Hat products, this closes a gap that is easy to overlook until you actually need it. More on rh-mastery in an upcomming post.

Practical Uses

The combination of bookmarks, structured knowledge, Red Hat’s product documentation, and the skill system makes the agent genuinely useful for research. When I ask it to investigate a topic, it starts with what I have already collected: prior notes, bookmarks, and documentation. If that is not enough, and when asked, it reaches out to the web to fill the gaps. The result is something grounded in material I collected and curated myself, which makes the output in most cases very useful.

One use I did not expect to find as useful: slide generation. I integrated Marp, a Markdown-based presentation framework, into the workflow. When I need to put together a presentation and am staring at a blank file, I can ask the agent to draft an initial structure. Getting past that first empty screen is often the hardest part. Whether I keep most of what it produces is a different question, but having something to react to is worth more than nothing to start from.

Skills and Subagents

The agent can develop and add skills on its own as it works, but skills can also be added manually or loaded from the community hub at agentskills.io. More interesting to me is the subagent capability: the agent can delegate tasks to specialized subagents, each backed by a specific AI service or holding a particular context. This makes it possible to compose workflows where different parts of a task go to the most appropriate model.

Conclusion

Several weeks in is not a long track record, and the project is still moving fast enough that some things will break between releases. That said, the architecture is sound and the development pace is truly impressive. Whether I will keep running it long-term, I genuinely do not know. For now, it is pulling its weight. For anyone already running a homelab and looking for a self-hosted agent that gets more useful over time rather than staying flat, Hermes Agent is worth the setup time.

Peter Steinberger, the creator of OpenClaw, another widely-used AI agent framework, put it well in a recent TED talk: “The bottleneck is no longer typing. It’s thinking.” That observation fits. The agent handles the mechanical parts of research and structuring. The judgment about what matters and what to do with it still has to come from someone. For now, a human in the loop is still necessary.

References

Hermes Agent on GitHub - link
Hermes Agent Documentation - link
Nous Research - link
Matrix - link
OpenRouter - link
Andrej Karpathy LLM Wiki concept - link
Marp - link
agentskills.io - link
Peter Steinberger TED talk - link