How to Manage Your Home Lab Infrastructure with an OpenClaw Agent on Raspberry Pi

Setting up a homelab is the fun part. Running it day after day is where things get tedious. You SSH into one machine to check disk space, open Portainer on another to restart a misbehaving container, pull up Grafana to confirm that memory is not spiking, then check that your latest FluxCD commit actually reconciled. Multiply that across 5, 10, or 20 services and the overhead adds up fast.

OpenClaw changes the interaction model. Instead of jumping between terminals, dashboards, and web UIs, you send a Telegram message: "What pods are failing in the monitoring namespace?" or "Show me Traefik logs from the last hour." The agent translates natural language into the right kubectl, docker, or SSH command, runs it, and sends back the results. Destructive operations like service restarts prompt for confirmation before executing.

A Raspberry Pi is a natural fit for this controller role. The Pi 5 draws roughly 5W at idle, which translates to about $5 per year in electricity. Compare that to leaving a laptop awake or spinning up a cloud VM at $6-7 per month. The Pi sits on your network, stays on 24/7, and costs almost nothing to operate. For a homelab that already runs on low-power hardware, adding a dedicated management node on a Pi keeps the philosophy consistent.

The real value is in Day 2 operations. Most homelab tutorials cover installation and initial configuration. Few address what happens on day 30, when a container silently runs out of memory, a disk fills up overnight, or a Kubernetes pod enters CrashLoopBackOff while you are asleep. An always-on agent watching your infrastructure catches these problems early, and it gives you a single interface to respond from anywhere your phone has signal.

The setup has two sides: the Pi itself and the infrastructure it will manage. Here is what you need before starting.

Raspberry Pi hardware:

• Raspberry Pi 5 with 8GB RAM (recommended). A Pi 4 with 8GB also works, but the Pi 5 offers faster CPU throughput and NVMe support
• USB-C power supply (27W official Pi 5 supply recommended for stable operation under load)
• Storage: 16GB+ microSD card works, but a USB SSD or NVMe drive via M.2 HAT dramatically improves I/O performance for a device running around the clock
• Ethernet cable for reliable connectivity to your lab network

Software requirements:

• Raspberry Pi OS Lite (64-bit). Skip the desktop environment for a headless server. Always use the 64-bit version because Node.js and most modern tooling require it
• Node.js 22 (ARM64 build)
• An API key from your preferred LLM provider (Anthropic, OpenAI, Google, or a locally hosted model via Ollama)
• Tailscale or another VPN for secure remote access to the management interface

Infrastructure to manage:

• Docker hosts, Kubernetes clusters (k3s, Talos, or standard k8s), standalone Linux servers, or any combination
• Services you want to monitor: Traefik, Pi-hole, Portainer, Prometheus, Netdata, Grafana, or whatever your lab runs

Accounts:

• A Telegram account and a bot token from BotFather (OpenClaw also supports Discord, WhatsApp, and Signal, but Telegram is the most common choice for homelab operators)

One-time hardware cost for a Pi 5 setup with case, power supply, and SSD runs $80-120. If you already have a Pi sitting in a drawer, the marginal cost is zero.

Start with a fresh Raspberry Pi OS Lite (64-bit) image. Flash it using Raspberry Pi Imager, enable SSH during the imaging process, and boot the Pi. Connect via SSH from your workstation.

Install Node.js 22, which OpenClaw requires as its runtime. The official OpenClaw documentation for Raspberry Pi recommends the NodeSource ARM64 build. Once Node.js is installed, run the OpenClaw installer, which handles dependencies and walks you through initial configuration including your LLM API key and gateway setup.

The installer creates a configuration directory at ~/.openclaw/ with JSON files for gateway settings, channel bindings, and skill definitions. The gateway binds to loopback (port 18789) by default, which means it is not exposed to your local network without explicit configuration. This is a deliberate security choice.

Setting up Telegram access:

Create a bot through Telegram's BotFather. You will receive a bot token that you add to your OpenClaw configuration as a channel. OpenClaw supports restricting access to specific Telegram user IDs, so only you (and anyone you explicitly allowlist) can issue commands. This is important because the agent will have the ability to run commands on your infrastructure.

Network access with Tailscale:

For remote management, install Tailscale on the Pi and join it to your tailnet. Tailscale Serve can expose the OpenClaw control UI only within your private network, keeping it off the public internet entirely. This gives you access to the web dashboard from anywhere on your tailnet without opening firewall ports.

Memory optimization for 2GB or 4GB models:

If you are running a Pi with less than 8GB of RAM, create a 2GB swap file and set vm.swappiness=10 to keep the system responsive. OpenClaw itself is lightweight, but Node.js can be memory-hungry during skill execution.

Give your homelab agent persistent storage and searchable documentation

Upload infrastructure skills, runbooks, and configs to a Fastio workspace. Intelligence Mode indexes everything for semantic search, and the MCP server lets your agent read and write files programmatically. generous storage, no credit card.

Start 14-Day Trial

Skills are the core abstraction that makes OpenClaw useful for infrastructure management. A skill is a Markdown file that describes a piece of your environment: what machines exist, what services run on them, how to access them, and what the agent is allowed to do. The LLM reads these skill files as context when processing your requests.

This approach comes directly from real homelab deployments. Mark Zhu's documented setup uses three primary skills to manage a multi-machine lab: a Home Lab Skill that describes SSH-accessible Linux machines, a Prometheus API Skill that queries monitoring metrics, and a Home Assistant Skill that controls smart devices through API webhooks.

The Merox.dev homelab setup takes a similar approach for a Talos Linux Kubernetes cluster running FluxCD for GitOps, plus Docker services managed through Ansible. The skill file lives in the same Git repository as the infrastructure manifests it describes, so changes to both the infrastructure and the agent's understanding of it are version-controlled together.

What a good infrastructure skill includes:

• Machine inventory: hostnames, IP addresses, SSH access details, and what each machine runs
• Service catalog: which containers or pods run where, their purpose, and how to check their health
• Access boundaries: what the agent can read vs. what it can modify. Destructive actions should require confirmation
• Protected resources: files and secrets the agent must never touch (encryption keys, SOPS files, kubeconfig, .env files)
• Preferred monitoring path: whether to check Prometheus metrics first or SSH directly for resource data

Prioritize monitoring over direct access. If you run Prometheus with Node Exporter, configure the skill to query Prometheus for CPU, memory, disk, and temperature metrics before falling back to SSH commands. This reduces the blast radius of agent actions and keeps the agent in a read-only posture for routine checks.

Conduct of code rules. Both the Merox and Zhu setups include explicit behavioral constraints in their skill files: the agent must explain its plan before executing, request confirmation for any state-changing operation, and never modify protected files. These constraints are part of the skill Markdown, not buried in application config, so they are visible and auditable alongside your infrastructure definitions.

Store skill files in ~/.openclaw/skills/ or in your infrastructure Git repository. When the skill lives next to your Ansible playbooks, Terraform configs, or Flux manifests, a single git log shows both infrastructure changes and the corresponding updates to the agent's context.

With OpenClaw installed and skills configured, your daily homelab management moves to Telegram. Here are the categories of tasks that homelab operators handle most frequently, and how they translate into agent interactions.

Container and pod health checks. Ask the agent to list pods in a specific namespace, show containers with non-zero restart counts, or check whether a specific deployment is running the expected number of replicas. The agent runs the appropriate kubectl or docker command and returns formatted results. For a lab running 15-20 services, this replaces the ritual of opening multiple dashboards every morning.

Log retrieval and analysis. When something breaks, the first step is almost always logs. Ask for Traefik access logs from the last hour, error-level entries from a specific pod, or journal output from a systemd service. The agent fetches the raw output and can summarize patterns if you ask it to. This is particularly useful when you are away from your desk and troubleshooting from your phone.

Resource monitoring. Disk space, CPU load, memory pressure, and temperature are the important signs of a homelab. If your skill is configured to query Prometheus, the agent pulls these metrics without SSHing into individual machines. Ask "Which machine has the least free disk space?" and get a ranked answer across your entire lab.

GitOps reconciliation. If you use FluxCD or ArgoCD for declarative infrastructure, the agent can trigger a reconciliation, check sync status, or show the diff between your Git state and the running cluster. The Merox.dev setup documents using flux reconcile commands through the agent, which is useful when you push a change and want to confirm it applied without opening the Flux dashboard.

Service restarts with confirmation. When a container needs to be bounced, the agent asks for confirmation before executing. This is a critical safety rail. A misunderstood command should not bring down your reverse proxy or DNS server. The confirmation prompt gives you a chance to verify the agent understood your intent correctly.

Scheduled checks. Some tasks benefit from running on a schedule rather than on demand. You can configure OpenClaw to run periodic health checks (disk space warnings, certificate expiration, backup verification) and send results to your Telegram chat proactively. This turns the agent from a reactive tool into a monitoring companion.

The common thread is that you interact with your entire lab through one text interface. No SSH sessions to juggle, no browser tabs to maintain, no remembering which dashboard shows which metric. The agent holds the map of your infrastructure in its skill context and routes each request to the right command on the right machine.

Infrastructure skills, runbooks, and configuration snippets accumulate quickly in a homelab. You need a place to store them that is accessible to both your agent and your future self when you inevitably forget how you set something up six months ago.

Local storage on the Pi works for the agent's runtime config, but it creates a single point of failure. If the SD card corrupts (a known risk for always-on Pi deployments) or you rebuild the Pi, you lose your skill files, custom scripts, and operational notes. Git repositories help with version control, but they are not always convenient for sharing configs across multiple agents or handing documentation to a collaborator.

Fastio workspaces give you a persistent layer that sits alongside your Git workflow. Upload your skill Markdown files, Ansible playbooks, Docker Compose definitions, and operational runbooks to a workspace. With Intelligence Mode enabled, those files are automatically indexed for semantic search and AI-powered chat, so you can ask questions like "How did I configure Traefik's TLS termination?" and get answers grounded in your own documentation, with citations pointing to the specific file.

The Fastio MCP server exposes workspace operations as structured tools. An agent with MCP access can read files from a workspace, upload new configs, and search across your documentation programmatically. This is useful when your OpenClaw agent generates a new skill file or audit report that you want to persist beyond the Pi's local storage.

For homelab operators running multiple agents (one for infrastructure, another for smart home, maybe a third for media management), a shared workspace becomes the coordination point. Each agent reads from and writes to the same workspace, and audit trails track which agent changed what and when. If you later want to hand off your homelab documentation to a friend or collaborator, ownership transfer lets you share access without rebuilding permissions from scratch.

The free tier at fast.io/pricing includes 50GB of storage, 5 workspaces, and included credits with no credit card required. For a homelab's worth of configuration files and runbooks, that is more than enough to get started.

Other options for this layer include S3-compatible storage (MinIO is popular in homelabs), Nextcloud, or even a simple Git repository with LFS for larger files. Fastio's advantage is the combination of persistent storage, built-in AI indexing, and MCP integration, which means your infrastructure agent can both read and write to the same place your documentation lives.

Giving an AI agent SSH access and the ability to run commands on your infrastructure is a meaningful security decision. Mark Zhu's writeup puts it plainly: "Giving an AI agent the ability to execute commands on your home lab and control your smart home devices carries significant security risks." The mitigation is not to avoid the risk entirely, but to scope it deliberately.

Principle of least privilege. Create a dedicated service account on each machine the agent accesses. Give it read access to logs, metrics, and container status. Limit write access to specific operations like restarting containers or triggering GitOps reconciliation. Do not give the agent root access or sudo without a password.

Protected files and secrets. Your skill files should explicitly list resources the agent must never read or modify: encryption keys (age.key), SOPS-encrypted files, kubeconfig with cluster-admin privileges, .env files containing API keys. The Merox.dev setup includes these exclusions directly in the skill Markdown.

Network isolation. Keep the OpenClaw gateway on loopback and use Tailscale for remote access. Do not expose port 18789 to your LAN unless you have a specific reason. The gateway token provides authentication, but defense in depth matters when the agent can run arbitrary commands.

Confirmation for destructive actions. Configure your skills to require explicit confirmation before any state-changing operation. A restart, a scale-down, a deployment rollback: none of these should happen because the agent misinterpreted a casual question as a command.

LLM provider considerations. Every command you send and every response you receive passes through your LLM provider's API. If your infrastructure details are sensitive, consider using a locally hosted model via Ollama to keep everything on-network. The tradeoff is reduced reasoning quality compared to cloud models like Claude or GPT-4, but for straightforward infrastructure commands, a capable local model can be sufficient.

Practical limits of the approach. OpenClaw is not a replacement for proper monitoring and alerting. Prometheus with Alertmanager, Uptime Kuma, or Grafana OnCall will catch problems faster and more reliably than an LLM polling on a schedule. The agent is best understood as an interactive management interface, not a monitoring system. Use it for ad-hoc queries, manual interventions, and daily operational checks. Use dedicated monitoring tools for automated alerting with defined thresholds.

The Kubernetes operator project (openclaw-operator on GitHub) demonstrates what production-grade security looks like for OpenClaw deployments: non-root execution, read-only root filesystems, all Linux capabilities dropped, seccomp profiles enabled, and default-deny network policies. Even in a homelab, borrowing these patterns improves your security posture.