OpenClaw Assistant on Raspberry Pi

1. Why run OpenClaw on a Pi?

I wanted a local assistant that could actually touch my files, run commands, and help with real tasks (like hardening the Pi, editing this site, and tracking lab work) without sending everything to a random SaaS. OpenClaw gives me:

A persistent “agent” (Juno) with memory and tools.
Direct access to my homelab over the LAN.
Control from Telegram, so I can talk to it like any other bot.

Key idea: treat the Pi as a small, always-on AI operations box that can help with security tasks, not just a chatbot window.

2. Hardware and base OS

I used another Raspberry Pi 4 as the base for this setup. The idea was to keep my OpenClaw assistant separate from the Wazuh SIEM Pi, but still on the same home network.

Platform: Raspberry Pi 4 Model B.
OS: Linux with a recent kernel (Debian/Ubuntu server style).
Network: on my home LAN behind a firewall, not directly exposed to the internet.

3. Installing OpenClaw

Following the OpenClaw docs, I installed the CLI globally with Node.js and then ran the onboard wizard to configure the main agent and channels.

# Install OpenClaw (Node.js required)
npm install -g openclaw

# Initial setup wizard
openclaw onboard

The wizard walked me through:

Creating the main agent (Juno) and workspace.
Wiring in model auth (OpenAI via ChatGPT OAuth and/or OpenRouter).
Enabling Telegram as the primary chat channel.

4. Wiring Telegram to the agent

I created a Telegram bot with @BotFather, grabbed the bot token, and added it to openclaw.json under the channels.telegram block. Access is restricted to my own Telegram user ID so only I can talk to the agent.

"channels": {
  "telegram": {
    "enabled": true,
    "dmPolicy": "allowlist",
    "botToken": "<bot-token>",
    "allowFrom": [
      "<my-telegram-user-id>"
    ],
    "groupPolicy": "allowlist",
    "streaming": "off"
  }
}

After restarting the gateway, I could DM the bot from Telegram and the messages were handled by my local OpenClaw agent on the Pi.

5. Hardening the Pi and OpenClaw (most important part)

This Pi can run commands and touch real data, so I treated it like a small production box. Before I let the assistant near anything important, I locked down the host:

Firewall: Installed and enabled UFW with a default deny on inbound traffic, only allowing SSH from my LAN.
Auto patching: Turned on unattended-upgrades so security updates install themselves.
SSH protection: Installed fail2ban to ban IPs that brute-force SSH.
Log hygiene: Enabled log redaction in OpenClaw so API keys and tokens don’t leak into logs.

# Example: firewall setup
sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable

Security takeaway: even though this is "just" a homelab assistant, it has elevated access. The hardening work (firewall, patches, fail2ban, log redaction) is what makes this project interesting from a SOC/blue-team perspective, not just the AI part.

6. What I use it for

With everything running, I use this Pi-hosted assistant for:

Daily cybersecurity news briefings (via cron jobs and web search).
Security checks on the Pi itself (firewall status, package updates, config issues).
Editing this portfolio site directly from the Pi’s workspace.
Planning and documenting homelab projects like the Wazuh SIEM.

The main takeaway is that this isn’t just “ChatGPT in a browser” — it’s a local, scriptable assistant with real access to my lab environment.