← Back to Blog

Give Your Hermes Agent a Browser It Can Control — with a Raspberry Pi

Your Hermes Agent runs on a cloud server. It can SSH into things, call APIs, run code, and read files. But it can't see the web. It can't log into a dashboard, fill out a form, or click through a checkout flow — the things that make up half of real-world business automation.

This is the story of how I gave my agent eyes. A $35 Raspberry Pi, a Chromium browser, and a single SSH reverse tunnel. My Hermes Agent and I now share a browser we both control.

Why a Shared Browser?

An AI agent that can drive a browser opens up a completely different class of automation:

• Login to web dashboards — your agent logs into Stripe, Shopify, LinkedIn, or any SaaS platform and performs actions on your behalf
• Fill and submit forms — data entry, sign-ups, registrations, support tickets
• Scrape dynamic content — pages that require JavaScript rendering, authentication, or multi-step navigation
• Cross-post to social media — publish to LinkedIn, Twitter, Facebook groups, forums
• Monitor dashboards — your agent checks admin panels, downloads reports, and alerts you on changes

Without a browser, your agent calls APIs. APIs are great — they're fast, structured, and reliable. But most business tools don't have a public API for every action you want to take. The browser is the universal API. Every web app has one.

The Problem: Your Agent Is in the Cloud

When your Hermes Agent runs on a cloud server (like a derez.ai instance), it has no local display, no browser, and no way to open one. Running a headless browser on the server works for simple page loads, but many sites detect headless Chrome and block it, and you can't interact with the browser yourself — it's a script, not a shared tool.

The solution: run the browser on a physical device at your location, and tunnel it to your cloud server via SSH.

Architecture

Here's how the pieces fit together:

The Chromium DevTools Protocol (CDP) exposes a WebSocket endpoint on port 9222. The SSH reverse tunnel makes that port available on your cloud server as if it were local. Your Hermes Agent connects to ws://127.0.0.1:9222 and sends commands. You can also open chrome://inspect on any machine on your local network to see exactly what the Pi's browser is showing — in real time.

Both you and your agent see the same browser. You can watch your agent work, step in if it gets stuck, or take over manually. It's a shared workspace.

What You Need

• Raspberry Pi — any model will do. A Pi 4 or Pi 5 is ideal. A Pi Zero 2 W works but is slower for JavaScript-heavy sites. You can also use an old laptop or a thin client
• Chromium browser — or Brave, Chrome, Edge. Any Chromium-based browser supports the remote debugging protocol
• SSH access to your cloud server — the server where your Hermes Agent runs. GatewayPorts should be set to yes in sshd_config (or you bind to localhost only, which is the default)
• Hermes Agent — with the computer-use or browser_* tools enabled, or the CDP skill loaded

Step 1: Set Up the Pi

Install Raspberry Pi OS Lite (no desktop needed — the browser runs headless-on-headless). SSH into the Pi and install Chromium:

sudo apt update
sudo apt install chromium-browser -y

That's it. No desktop environment, no X server, no VNC. Chromium runs in headless mode with the debugging port exposed.

Step 2: The Tunnel Script

Create a script that launches Chromium and establishes the SSH reverse tunnel. Save this as ~/browser-tunnel.sh on the Pi:

#!/usr/bin/env bash
set -euo pipefail

REMOTE_HOST="creek.derez.ai"
REMOTE_PORT=2202
REMOTE_USER="root"

DEBUG_PORT=9222
PROFILE="$HOME/.config/brave-remote"

pkill -f "remote-debugging-port=${DEBUG_PORT}" || true

chromium-browser \
    --remote-debugging-port=$DEBUG_PORT \
    >/dev/null 2>&1 &

sleep 3

exec ssh \
    -N \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -o ExitOnForwardFailure=yes \
    -R ${DEBUG_PORT}:127.0.0.1:${DEBUG_PORT} \
    ${REMOTE_USER}@${REMOTE_HOST} \
    -p ${REMOTE_PORT}

Make it executable and run it:

chmod +x ~/browser-tunnel.sh
~/browser-tunnel.sh

The script:

1. Kills any existing Chromium with the same debugging port
2. Launches Chromium with remote debugging enabled on port 9222
3. Waits for the browser to start
4. Opens an SSH reverse tunnel — port 9222 on the Pi becomes port 9222 on the cloud server
5. Stays connected indefinitely with keep-alive pings every 30 seconds

Step 3: Verify the Tunnel

From your cloud server, check that the port is available:

curl http://127.0.0.1:9222/json/version

You should get a JSON response with the browser version, WebSocket URL, and available pages. If you see the JSON, the tunnel is working.

To see the browser visually from your local machine, open Chrome or Brave and navigate to chrome://inspect. Click "Configure" and add localhost:9222 (or the Pi's local IP if you're on the same network). You'll see all open tabs and can inspect them live.

Step 4: Connect Hermes to the Shared Browser

From your Hermes Agent, you can now connect to the browser via the Chrome DevTools Protocol. The WebSocket endpoint is at ws://127.0.0.1:9222/devtools/browser.

Hermes can use this in two ways:

Option A: Use the built-in browser tools

Hermes has browser_navigate, browser_click, browser_type, and other browser_* tools. These normally use a headless browser on the same machine. To use your shared Pi browser instead, configure the browser tool to connect to the remote CDP endpoint:

# In ~/.hermes/config.yaml
browser:
  cdp_url: "ws://127.0.0.1:9222"

Now every browser_navigate call from your agent drives the Pi's browser. You can watch each tab open and each click happen in real time.

Option B: Direct CDP commands through a skill

For more fine-grained control, load a CDP skill that sends raw DevTools Protocol commands. This lets you inspect DOM elements, evaluate JavaScript, capture screenshots, and intercept network requests:

hermes skills install browser-use

Your agent can then run commands like:

"Navigate to the LinkedIn company page, find the 'Create post' button, write a new update, and publish it."

And it will do exactly that — in the browser you can see on your screen.

What This Enables

Once you have a shared browser, the automation possibilities expand dramatically:

• Social media management — your agent posts to LinkedIn, Twitter, Facebook groups, and forums. It handles the login, the editor, the formatting, and the publishing. You review the draft before it goes live.
• SaaS dashboard monitoring — your agent logs into your Stripe dashboard, downloads the monthly report, checks for failed payments, and summarizes the results in Slack.
• Form filling at scale — need to submit 50 support tickets? Your agent opens each one, fills in the details, and clicks submit. No API needed.
• Web research with visual feedback — your agent navigates competitor sites, takes screenshots, and reports back on pricing changes, feature updates, or new content.
• E-commerce automation — check inventory, place orders, track shipments, all through the browser interface.

Security Considerations

The Chrome DevTools Protocol is powerful — it gives full control over the browser. Anyone who can reach port 9222 can navigate to any site, read any open tab, and execute arbitrary JavaScript.

• Bind to localhost — the SSH tunnel binds to 127.0.0.1 on the server side. Only processes on the server itself can reach the CDP endpoint. Do not bind to 0.0.0.0.
• SSH key authentication — use an SSH key (not a password) for the tunnel. The REMOTE_USER should have key-based auth only.
• Dedicated Pi user — run the browser under a separate user account on the Pi. Don't use root.
• No persistent sessions — the script launches a fresh browser each time. No saved cookies, no lingering sessions. If you need persistent logins, use a dedicated profile directory.
• Limited network access — the Pi only needs outbound SSH to your server. Block all inbound ports on the Pi's firewall.

How It Works Under the Hood

When you add --remote-debugging-port=9222 to Chromium, it starts a WebSocket server on that port. The DevTools Protocol speaks JSON over WebSocket — every command is a method call with parameters, and every response is a result or an event.

CDP commands your agent can send:

{
  "id": 1,
  "method": "Page.navigate",
  "params": { "url": "https://example.com" }
}

Response:

{
  "id": 1,
  "result": { "frameId": "..." }
}

The SSH reverse tunnel makes this WebSocket endpoint appear as if it's running on the server itself. The -R flag in SSH maps a remote port to a local port:

-R 9222:127.0.0.1:9222

This means: "when anyone connects to port 9222 on the remote server, forward that connection to port 9222 on localhost (the Pi)." The SSH connection stays open indefinitely, and the ServerAliveInterval option ensures it stays alive even through NAT or firewalls.

Why a Raspberry Pi Specifically

You could run the browser on your main workstation. That works — I did it for months. But a dedicated Pi has advantages:

• Always on — the Pi sits in a corner, plugged into power and Ethernet. 24/7 uptime without your workstation being on.
• Low power — ~5 watts. It costs less than a dollar a month to run.
• No interference — your agent can work while you sleep. No browser tabs mixed with your personal browsing. No accidental close.
• Dedicated to the task — the Pi has one job: run the browser and maintain the tunnel. Nothing else. No Chrome extensions you forgot about, no autofill on your personal accounts.
• Cheap enough to be disposable — a Pi 5 is $35. If you want two (one for staging, one for production), that's $70. Your workstation is probably worth 50x that.

That said, an old laptop, a thin client, or even a $10 Android TV box running Linux works just as well. The key is a dedicated, always-on device that runs Chromium and has stable internet access.

Bringing It All Together

Here's the complete workflow for a real task:

1. You ask — "Check if we have any new Stripe subscriptions from yesterday and post a summary to Slack."
2. Hermes opens the browser — it connects to ws://127.0.0.1:9222, opens a new tab, navigates to Stripe's dashboard
3. Hermes logs in — it finds the email field, types your credentials, clicks the login button
4. Hermes navigates the dashboard — it clicks through to "Subscriptions," filters by "Created (Yesterday)," reads the table
5. Hermes extracts the data — it evaluates JavaScript in the page context to get the subscription count, total revenue, and list of new customers
6. Hermes posts to Slack — it calls the Slack API directly (no browser needed for this) with a formatted summary
7. You see the result — in Slack, a message: "3 new subscriptions yesterday, $247 in new MRR. Details: ..."

You can watch every step happen in real time by opening chrome://inspect on your machine. Or you can walk away and check the result later. The Pi doesn't sleep.

What's Next

This is the foundation. Once you have a shared browser, the next step is to build persistent sessions — your agent logs into sites once, saves the cookies, and reuses them across tasks. Then multi-tab workflows where your agent keeps a reference tab open while working in another. Then scheduled browser tasks — cron jobs that drive the browser at 3 AM to generate daily reports.

The shared browser turns your agent from a read-only API caller into an interactive web operator. And it costs less than a pizza to set up.

derez.ai — Deploy your AI agent in 5 minutes. · How I Automated LinkedIn Publishing with an AI Agent · n8n + Hermes Agent: The 350-Tool Automation Hub