DEV Community: Sachin Shah

Integrating OpenClaw with Google Cloud: A Solo Developer's Guide

Sachin Shah — Fri, 17 Apr 2026 03:39:00 +0000

Running an AI personal assistant from your laptop sounds great until the lid closes, the Wi-Fi drops, or your machine restarts. If you want a gateway that stays online 24/7, reachable from any device, you need to move it off your local hardware and onto something persistent.

This guide walks you through deploying OpenClaw on a GCP Compute Engine VM using Docker, from zero to a running gateway you can access over an SSH tunnel.

The target reader is a solo developer who wants a private, always-on AI assistant without managing Kubernetes or paying for a managed platform. The total infrastructure cost is roughly $12-25/month for the VM, plus whatever you spend on model API calls.

Why It Matters

A personal AI assistant is only useful if it is always reachable. Running the OpenClaw gateway on your laptop means it goes down when you sleep your machine, switch networks, or reboot for updates. You also lose access from your phone, tablet, or any other device that is not your development machine.

The economics favor self-hosting. Commercial AI agent platforms charge per resolution or per seat. OpenClaw separates infrastructure cost from model cost: you pay for compute (the VM) and API calls (the model provider), with zero per-message platform fees.

For a solo developer handling personal tasks, model costs at $0.01-$0.05 per message put annual spending well under $1,000, often under $300. The VM adds $12-25/month depending on the machine type you choose. That is the full cost of an always-on, private AI assistant.

The Compute Engine and Docker pattern solves the core problem: your assistant runs on a persistent VM in Google's data center, survives reboots via Docker's restart policy, and keeps state on host-mounted volumes that outlive container rebuilds.

What the System Does?

OpenClaw is a self-hosted AI gateway. It sits between your messaging channels (WhatsApp, Telegram, Discord, iMessage, and others) and model providers (Anthropic, OpenAI, OpenRouter, Groq). You configure it once, and it routes conversations from any connected channel through a single agent backed by the model of your choice.

For the personal assistant use case, the setup looks like this: one dedicated phone number or bot account acts as your always-on agent. You message it from your real phone, and the OpenClaw gateway processes the message, calls the model API, and sends back a response. The gateway also exposes a Control UI (a web dashboard) where you manage settings, approve devices, and monitor conversations.

The gateway runs as a single Node.js process inside a Docker container. It reads configuration from ~/.openclaw/openclaw.json, persists workspace data to ~/.openclaw/workspace, and binds a WebSocket server on port 18789. When deployed on a VM, this process stays up indefinitely thanks to Docker Compose's restart: unless-stopped policy.

Beyond the core gateway, OpenClaw has an extensible plugin system. ClawdHub offers 200+ skills covering common workflow tasks. Persistent memory via Mem0, WhatsApp/Telegram channel pairing, and Gmail OAuth are all available as configuration layers on top of the base gateway. This guide focuses strictly on getting the gateway running on GCP; those extensions are covered briefly in "Where to Go Next" section.

Architecture Overview

The deployment has five layers, from your laptop to the model providers:

Your laptop runs a browser pointed at localhost:18789
gcloud compute ssh with port forwarding creates an encrypted tunnel from your laptop to the VM
GCP Compute Engine VM (Debian 12, e2-small) hosts Docker
Docker Compose runs the openclaw-gateway container, bound to 127.0.0.1:18789 on the VM
The gateway makes outbound HTTPS calls to model provider APIs (OpenRouter, Anthropic, Groq, etc.) and optionally to ClawdHub for plugin management

The gateway port is bound to loopback only on the VM. No firewall rules need to be opened for inbound traffic beyond SSH (port 22). All access to the Control UI goes through the SSH tunnel.

Runtime Request Flow

The key security property of this architecture: the gateway never listens on a public interface. The 127.0.0.1: prefix in the Docker Compose ports directive ensures the gateway is only reachable from the VM's loopback. Your SSH tunnel bridges the gap between your laptop and that loopback port. Google recommends this port-forwarding-over-SSH pattern as a primary method for securing services on VMs.

Setup: Prerequisites

Before starting, make sure you have:

A GCP account (free tier is eligible for e2-micro, but you will want e2-small or e2-medium for this deployment)
gcloud CLI installed on your local machine (install guide)
SSH access from your laptop to GCP VMs (handled automatically by gcloud compute ssh)
Basic familiarity with Docker and Docker Compose
An API key for at least one model provider (OpenRouter, Anthropic, Groq, etc.)
Roughly 20-30 minutes end to end

Choosing a VM Machine Type

This decision matters more than you might expect. The Docker image build (pnpm install --frozen-lockfile) is memory-intensive, and undersized VMs will OOM-kill the build process with exit code 137.

Type	Specs	Cost	Notes
e2-medium	2 vCPU, 4GB RAM	~$25/mo	Most reliable for local Docker builds
e2-small	2 vCPU, 2GB RAM	~$12/mo	Minimum recommended for Docker build
e2-micro	2 vCPU (shared), 1GB RAM	Free tier eligible	Often fails with Docker build OOM (exit 137)

Source: https://openclaws.io/docs/install/gcp

The official OpenClaw Dockerfile now includes NODE_OPTIONS=--max-old-space-size=2048 to cap the Node.js heap during dependency installation, which helps on e2-small instances. But e2-micro remains unreliable for the initial build. If you are budget-sensitive, one strategy is to create an e2-medium for the initial build, then downgrade to e2-small for steady-state operation.

Step-by-Step Implementation

Step 1: Install and initialize the gcloud CLI

Step-by-Step Implementation

Step 1: Install and initialize the gcloud CLI

Install the gcloud CLI on your local machine and authenticate so you can script all GCP operations from your terminal.


gcloud init

gcloud auth login

This sets your default project, region, and credentials. All subsequent gcloud commands in this guide use this authenticated session.

Step 2: Create and configure your GCP project

Create a dedicated project to keep billing, IAM, and logs isolated for your OpenClaw gateway. Then enable the Compute Engine API.


gcloud projects create my-openclaw-project --name="OpenClaw Gateway"

gcloud config set project my-openclaw-project

Enable billing for the project at https://console.cloud.google.com/billing (required before you can create VMs). Then enable the Compute Engine API:


gcloud services enable [compute.googleapis.com](http://compute.googleapis.com)

Step 3: Create the Compute Engine VM

Provision a Debian 12 VM with enough resources to build and run the OpenClaw Docker image.


gcloud compute instances create openclaw-gateway 

--zone=us-central1-a 

--machine-type=e2-small 

--boot-disk-size=20GB 

--image-family=debian-12 

--image-project=debian-cloud

The us-central1-a zone is one of the most cost-effective regions. The 20GB boot disk is enough for the OS, the OpenClaw repo, the built Docker image, and persistent state directories.

Step 4: SSH into the VM

Once the VM is running, SSH in. If the connection is refused immediately after creation, wait 1-2 minutes for SSH key propagation and retry.


gcloud compute ssh openclaw-gateway --zone=us-central1-a

Step 5: Install Docker and basic tooling

Inside the VM, install git, curl, and Docker. Add your user to the docker group so you can run Docker commands without sudo, then log out and back in for the group change to take effect.


sudo apt-get update

sudo apt-get install -y git curl ca-certificates

curl -fsSL https://get.docker.com | sudo sh

sudo usermod -aG docker $USER

Log out and SSH back in:


exit

From your local machine:


gcloud compute ssh openclaw-gateway --zone=us-central1-a

Verify Docker is working:


docker --version

docker compose version

Step 6: Clone the OpenClaw repository

Pull the OpenClaw source so you can build a custom Docker image with all required binaries baked in.


git clone https://github.com/openclaw/openclaw.git

cd openclaw

Step 7: Create persistent host directories

Docker containers are ephemeral. All long-lived state must live on the host. These directories are mounted into the container via Docker Compose and survive container rebuilds.


mkdir -p ~/.openclaw

mkdir -p ~/.openclaw/workspace

Step 8: Configure the `.env` file

Create a .env file in the repository root. This defines the image name, gateway binding, port, and where to mount configuration and workspace directories.


OPENCLAW_IMAGE=openclaw:latest

OPENCLAW_GATEWAY_TOKEN=change-me-now

OPENCLAW_GATEWAY_BIND=lan

OPENCLAW_GATEWAY_PORT=18789

OPENCLAW_CONFIG_DIR=/home/$USER/.openclaw

OPENCLAW_WORKSPACE_DIR=/home/$USER/.openclaw/workspace

GOG_KEYRING_PASSWORD=change-me-now

XDG_CONFIG_HOME=/home/node/.openclaw

Generate strong secrets to replace the change-me-now placeholders:


openssl rand -hex 32

Run this command twice: once for OPENCLAW_GATEWAY_TOKEN and once for GOG_KEYRING_PASSWORD. Paste the generated values into your .env file.

A note on bind semantics: OPENCLAW_GATEWAY_BIND=lan tells the gateway inside the container to listen on 0.0.0.0 (all interfaces). But the Docker Compose ports directive pins the host-side binding to 127.0.0.1, keeping the gateway loopback-only on the VM. The lan bind is necessary so that Docker's network bridge can route traffic from the host port into the container.

Lock down the file permissions:


chmod 600 .env

Step 9: Create the Docker Compose configuration

Create docker-compose.yml in the repository root:


services:

openclaw-gateway:

image: ${OPENCLAW_IMAGE}

build: .

restart: unless-stopped

env_file:

- .env

environment:

- HOME=/home/node

- NODE_ENV=production

- TERM=xterm-256color

- OPENCLAW_GATEWAY_BIND=${OPENCLAW_GATEWAY_BIND}

- OPENCLAW_GATEWAY_PORT=${OPENCLAW_GATEWAY_PORT}

- OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}

- GOG_KEYRING_PASSWORD=${GOG_KEYRING_PASSWORD}

- XDG_CONFIG_HOME=${XDG_CONFIG_HOME}

- PATH=/home/linuxbrew/.linuxbrew/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

volumes:

- ${OPENCLAW_CONFIG_DIR}:/home/node/.openclaw

- ${OPENCLAW_WORKSPACE_DIR}:/home/node/.openclaw/workspace

ports:

# Loopback-only (recommended for VPS)

- "127.0.0.1:${OPENCLAW_GATEWAY_PORT}:18789"

# Optional: Canvas host for iOS/Android nodes

# - "18790:18790"

Three things to understand about this configuration:

"127.0.0.1:${OPENCLAW_GATEWAY_PORT}:18789": The 127.0.0.1: prefix is the primary security control. It means the port is only accessible on the VM's loopback interface, not from the public internet.
restart: unless-stopped: The gateway automatically restarts after crashes or VM reboots. It only stays down if you explicitly docker compose stop it.
Volume mounts: ${OPENCLAW_CONFIG_DIR} and ${OPENCLAW_WORKSPACE_DIR} map host directories into the container. Configuration, auth profiles, and workspace data persist across container rebuilds.

Step 10: Build and launch

Build the Docker image and start the gateway in detached mode:


# Build image

docker compose build

# Start gateway

docker compose up -d openclaw-gateway

# View logs

docker compose logs -f openclaw-gateway

The build step takes several minutes on an e2-small instance. If it fails with Killed or exit code 137, your VM is out of memory. See the FAQ section for the fix.

When the gateway is ready, you will see:


[gateway] listening on ws://0.0.0.0:18789

Verify that the required binaries are baked into the image:


# Check binary availability

docker compose exec openclaw-gateway which gog

docker compose exec openclaw-gateway which goplaces

docker compose exec openclaw-gateway which wacli

Expected output:


/usr/local/bin/gog

/usr/local/bin/goplaces

/usr/local/bin/wacli

Step 11: Set allowed origins for the Control UI

When binding to lan, you must explicitly whitelist the Control UI origin, or the browser will be blocked:


docker compose run --rm openclaw-cli config set gateway.controlUi.allowedOrigins '["http://127.0.0.1:18789"]' --strict-json

Step 12: Open the SSH tunnel and access the Control UI

From your local machine (not the VM), open an SSH tunnel that forwards your laptop's port 18789 to the VM's loopback port 18789:


gcloud compute ssh openclaw-gateway --zone=us-central1-a -- -NL 18789:localhost:18789

The flags break down as:

-N: Do not execute a remote command (tunnel only)
-L 18789:localhost:18789: Forward local port 18789 to localhost:18789 from the VM's perspective

With this tunnel active, open http://127.0.0.1:18789 in your browser. You will see the OpenClaw Control UI.

Step 13: Complete onboarding

In the Control UI:

Navigate to Settings and then Token
Paste the OPENCLAW_GATEWAY_TOKEN value from your .env file
If the UI shows your browser as unauthorized, approve it:


docker compose run --rm openclaw-cli devices list

docker compose run --rm openclaw-cli devices approve <requestId>

The onboarding wizard will walk you through model provider configuration and any channel setup you want to add. This is interactive and depends on your specific provider keys and channel preferences.

At this point, you have a running OpenClaw gateway on GCP, accessible from your laptop over an encrypted SSH tunnel.

What Worked Well

These observations are derived from the reference documentation and deployment architecture, not from personal production experience.

Single automated setup script. The docker-setup.sh script handles token generation, directory creation, and idempotent .env writing via its upsert_env() function. If you prefer automation over manual steps, you can run ./docker-setup.sh instead of steps 8-10 above. It generates tokens automatically using openssl rand -hex 32 with a Python fallback:


if [[ -z "${OPENCLAW_GATEWAY_TOKEN:-}" ]]; then

  if command -v openssl >/dev/null 2>&1; then

    OPENCLAW_GATEWAY_TOKEN="$(openssl rand -hex 32)"

  else

    OPENCLAW_GATEWAY_TOKEN="$(python3 - <<'PY'

      import secrets

      print(secrets.token_hex(32))

      PY

    )"

Persistent state survives everything. The volume mount pattern (${OPENCLAW_CONFIG_DIR}:/home/node/.openclaw) means configuration, agent auth profiles, and workspace data live on the host disk, not in the ephemeral container layer. Combined with restart: unless-stopped, the gateway comes back online with all its state intact after VM reboots, Docker daemon restarts, or container crashes.

SSH tunnel security is zero-config. No firewall rules need to be opened. No TLS certificates need to be managed. No reverse proxy needs to be configured. The gateway listens only on loopback; all access flows through the encrypted gcloud compute ssh tunnel. This is the GCP-recommended pattern for accessing services on VMs without exposing them to the public internet.

Docker Compose is the right tool for this workload. A single-host orchestrator with one service, predictable state, and no need for horizontal scaling. You can understand the entire deployment by reading one YAML file. There is no distributed state, no control plane, and no etcd to manage. For a solo developer running a personal assistant on a single VM, this is the correct level of complexity.

Limitations and Trade-offs

OOM risk during the initial build. The docker compose build step runs pnpm install --frozen-lockfile, which is memory-intensive. On e2-micro instances (1GB RAM), the kernel reliably OOM-kills this process with exit code 137. Even e2-small (2GB RAM) can be tight. The Dockerfile now includes NODE_OPTIONS=--max-old-space-size=2048 as a mitigation, but the safest path is to use e2-medium for the first build, then downgrade.

Single point of failure. One VM, one container, one process. If the VM goes down for maintenance or the zone has an outage, your assistant is offline. Docker Compose can restart a crashed container, but it cannot move workloads to another host. For a personal assistant this is usually acceptable. For anything with uptime requirements, it is not.

SSH tunnel is a manual step. Every time you want to access the Control UI, you must open the SSH tunnel from your terminal. The tunnel also drops when your terminal session closes or your laptop sleeps. There is no built-in mechanism in this deployment pattern to keep the tunnel persistent. Workarounds exist (e.g., ~/.ssh/config with LocalForward, autossh, or a launchd/systemd unit for the tunnel), but the reference guide does not cover them.

Setup complexity is real. OpenClaw earns a 3.5/5 for "Ease of Setup" in independent reviews, and a 4.2/5 overall rating qualified with "not recommended as a first AI agent tool for non-technical users." The YAML configuration, environment variable layering, and Docker build process require comfort with the terminal.

Cloud Run is not an option for this workload. A common question: "Why not Cloud Run instead of a VM?" OpenClaw's gateway is a long-running WebSocket daemon that requires persistent local storage. Cloud Run's file system is ephemeral (writes consume instance memory, data is lost on shutdown), and instances are disposable by design. Both criteria disqualify it from hosting the OpenClaw gateway.

Where to Go Next

Once your gateway is running, there are several directions to extend the setup.

Add messaging channels. The gateway supports WhatsApp (via QR pairing), Telegram (via bot token), Discord, iMessage, and more. The personal assistant setup guide covers the "two-phone setup" for WhatsApp, where a second phone acts as the assistant's dedicated number. Configuration goes in ~/.openclaw/openclaw.json:


{

"channels": { "whatsapp": { "allowFrom": ["+15555550123"] } }

}

Add persistent memory with Mem0. By default, the agent forgets everything between sessions. The @mem0/openclaw-mem0 plugin watches conversations, extracts relevant context, and stores it for retrieval in future sessions:


openclaw plugins install @mem0/openclaw-mem0

Push your image to Artifact Registry. Instead of building on the VM every time, build locally (or in CI), push to GCP Artifact Registry, and pull from the VM. Compute Engine can pull containers directly from Artifact Registry repositories with the right IAM permissions.

Ship logs to Cloud Logging. Docker's gcplogs logging driver sends container logs directly to Google Cloud Logging without SSH. When running on a GCP VM, it auto-discovers project metadata from the instance metadata service.

Remove the public IP entirely with IAP. For a more hardened setup, create the VM without a public IP and use Identity-Aware Proxy (IAP) TCP forwarding for SSH. IAP verifies your Google identity before allowing the connection, eliminating the attack surface of a public IP:


gcloud compute ssh openclaw-gateway --zone=us-central1-a --tunnel-through-iap

Consider GKE if you outgrow a single VM. If you need multi-instance availability, automated rollouts, or are running multiple services alongside the gateway, Google Kubernetes Engine is the natural step up from Compute Engine. But for a personal assistant, a single VM is typically sufficient indefinitely.

Conclusion

The Compute Engine and Docker pattern gives solo developers an always-on AI assistant for $12-25/month in infrastructure costs plus model API spending. The architecture is simple enough to fit in one YAML file, secure by default (loopback binding and SSH tunnel), and resilient to container crashes (Docker restart policy and host-mounted volumes).

The main trade-offs are the manual SSH tunnel step, the single point of failure inherent to a single VM, and the OOM risk during the initial Docker build on small instances. These are acceptable trade-offs for a personal assistant workload.

If your needs grow beyond a single VM, GCP offers a clear upgrade path: Artifact Registry for image management, Cloud Logging for observability, IAP for zero-public-IP access, and GKE for multi-node orchestration. But start here. A single e2-small instance running Docker Compose is the simplest path to a private, persistent AI gateway.

FAQs

Why does my Docker build fail with "Killed" and exit code 137?

Exit code 137 means the Linux kernel OOM-killed the build process. This happens most frequently during pnpm install --frozen-lockfile on VMs with less than 2GB RAM. The fix is to upgrade your VM to at least e2-small (2GB) or e2-medium (4GB) for the initial build:


# Stop the VM first

gcloud compute instances stop openclaw-gateway --zone=us-central1-a

# Change machine type

gcloud compute instances set-machine-type openclaw-gateway 

--zone=us-central1-a 

--machine-type=e2-small

# Start the VM

gcloud compute instances start openclaw-gateway --zone=us-central1-a

The official OpenClaw Dockerfile now includes NODE_OPTIONS=--max-old-space-size=2048 to cap heap usage during dependency installation, which helps on 2GB machines.

Is it safe to expose port 18789 publicly?

The recommended configuration keeps the gateway loopback-only (127.0.0.1:18789 in the Docker Compose ports directive) and accesses it via SSH tunnel. If you need public exposure, remove the 127.0.0.1: prefix and configure GCP firewall rules accordingly. The gateway supports token-based authentication (the 64-character hex token in .env), but the official documentation advises reading the security docs before exposing any port publicly.

How do I access the gateway UI without keeping a terminal open?

The reference guide does not cover persistent tunnel configurations. Practical options include:

Adding a LocalForward 18789 localhost:18789 entry to ~/.ssh/config for the VM
Using autossh to maintain a persistent tunnel with automatic reconnection
Running the gcloud compute ssh tunnel command inside a tmuxor screen session

This is a known ergonomic gap in the current deployment pattern.

What are the minimum server requirements?

The documented minimum is 2GB RAM (e2-small) for the Docker build, though 4GB (e2-medium) is recommended for reliable first builds. At steady state, the running gateway uses less memory than the build process, so e2-small is generally sufficient for ongoing operation. Software requirements are Node.js 24 (or 22.16+) and Docker, both of which are installed during setup.

Can I use Cloud Run instead of Compute Engine?

No. OpenClaw's gateway is a long-running WebSocket daemon that requires persistent local storage. Cloud Run's file system is ephemeral (data is lost when the instance stops), instances are disposable by design, and the platform is optimized for stateless HTTP services. Compute Engine is the correct GCP service for this workload.

How much will this cost per month?

VM cost depends on machine type: e2-small runs about $12/month, e2-medium about $25/month. Model API costs are separate and depend on your usage and model choice (typically $0.01-$0.05 per message). The gateway software itself is free and open source. GCP egress costs for SSH tunnel traffic are negligible for personal use. Total cost for a solo developer is typically $15-30/month including moderate model API usage.

Hermes Agent: The AI That Actually Gets Smarter Every Time You Use It

Sachin Shah — Thu, 09 Apr 2026 14:06:06 +0000

Most AI assistants forget everything the moment a session ends. But Hermes Agent builds a memory of who you are, creates reusable skills from your past conversations, and keeps getting more capable the longer it runs. It's open source, works on a $5 VPS, and you can talk to it from Telegram while it runs quietly in the cloud. This post walks you through what it is, why it's worth paying attention to, and how to get started.

What Exactly Is An Agent?

Before we go further, let's get one thing straight: there's a real difference between a chatbot and an agent, and it matters here.

A chatbot answers your question and moves on. Every message exists in isolation. There's no memory of what you asked yesterday, no ability to take actions beyond generating text, and no way for it to get better at helping you specifically over time.

An agent is different. Think of it like the difference between a search engine and an intern. The search engine returns results. The intern can go look something up, open a file, write a script, test it, fix it when it breaks, and come back to you with a finished result. They know your preferences. They get faster and more useful as time goes on.

Hermes Agent is the intern version.

What Is Hermes Agent?

Hermes Agent is an open-source AI agent built by Nous Research. It is not a chatbot, and it is not a coding tool tied to an IDE. It is a standalone agent with a built-in learning loop that creates skills from experience, builds memory across sessions, and gets more capable the longer you use it. You can deploy it anywhere and talk to it from the messaging apps you already use.

Let me paint a familiar picture. You spend 20 minutes setting up an AI assistant. You tell it your preferences, your project context, and how you like things done. It's helpful. Then you close the tab. The next day, you come back to a blank slate. You re-explain everything from scratch, like a first date you've already been on. If that loop sounds exhausting, Hermes Agent was built to break it.

A Built-In Learning Loop

Most AI tools are frozen. You get the same capability on day one as you get on day one hundred. Hermes is designed around the opposite idea. So, every conversation teaches the agent something. After each session, Hermes reviews what happened and decides what's worth keeping as a permanent memory. It also does something more interesting, i.e., it creates skills.

What Are Skills?

Think of skills like recipes. The first time Hermes works through something complex like setting up a project scaffold or running a multi-step research task, it writes down the steps that worked. It stores those steps as a reusable skill. The next time you ask for something similar, it doesn't start from scratch. It pulls out that recipe and executes it faster, more reliably, and without you having to re-explain the context.

These skills live outside any single conversation. They compound across sessions. The more you use Hermes, the richer its skill library gets, and because it can improve existing skills during use, the recipes get better over time.

Hermes also builds a growing model of your preferences, your recurring projects, and your working style. It calls this the memory system, and it's backed by real persistent storage that survives restarts, re-deployments, and long idle periods.

Key Takeaways

Here's something that surprised me about Hermes. Most AI tools require you to have your machine open and running, but Hermes can live on a \$5 VPS you never SSH into directly. It can run on serverless infrastructure that costs nearly nothing when idle because it hibernates between conversations. You set it up once, and it stays alive in the cloud doing work whether your laptop is open or not.

Supported environments

The supported environments include your local machine, Docker containers, remote SSH servers, and two serverless options called Daytona and Modal. Daytona and Modal are the interesting ones for beginners as they handle all the infrastructure for you, and you only pay for compute when Hermes is actively doing something.

Connecting to platforms

Since Hermes isn't tied to your laptop, you can reach it from wherever you are. It connects to over 14 messaging platforms, including Telegram, Discord, WhatsApp, Slack, and Signal.

The Telegram integration is particularly worth setting up early. Once it's running, you can send Hermes a task from your phone while you're away from your desk, and it will execute it on the cloud VM, respond with results, and keep that work in memory for your next session. No need to open a laptop. No need to keep a terminal running.

Built-in tools

Hermes ships with 47 built-in tools out of the box. These cover things like web search, file reading and writing, code execution, image generation, browser control, and more. You don't configure these individually. They're available by default, and Hermes decides which ones to reach for based on what you ask.

Browser agent

Hermes Agent can search the web and pull real information rather than guessing from training data alone. It can run code and test it in isolated sandboxes so failures don't affect anything outside the agent. It can browse websites with full vision support, meaning it can look at a page the way a human would, rather than just parsing raw text. Hermes can do is spawn sub-agents to handle work in parallel.

MCP support

On top of the built-ins, Hermes supports MCP (Model Context Protocol), which is an open standard for connecting agents to external services. If a tool you want isn't built in, there's a good chance an MCP server exists for it.

Getting Started in 60 Seconds

Hermes installs on Linux, macOS, and WSL2. Open your terminal and run the following:


curl -fsSL <https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh> | bash

Once installed, start your first session by running:


Hermes setup

Hermes will run this by default and will also look for any existing installation, like OpenClaw or any other agent.

You'll be prompted to connect an AI model provider on the first run. Hermes works with multiple providers, including OpenRouter (which gives you access to hundreds of models through one API key), OpenAI, and any provider that uses a standard API format.

After that first setup, you're in. Start talking by running:


Hermes

What to Try First

Here are a few good starting points to get a feel for what Hermes actually does:

Have a real conversation about an ongoing project you're working on.
Tell the agent your stack, your current challenges, and what you're trying to build. Let it respond and ask follow-up questions. At the end of that session, check what the agent stored in memory. You'll see it pulling out specific facts rather than saving the whole transcript.
Then start a new session the next day without re-explaining anything. See what the agent already knows about you.
After a couple of sessions, type something like "what skills have you created so far?" and see what's in its library.

The first few skills will feel basic. After a month of regular use, the skill library starts to feel like a real productivity layer.

One thing worth knowing before you dive in: Hermes is built by Nous Research, the same team behind several well-regarded open source AI models. The codebase is MIT licensed, which means you can read it, modify it, self-host it, and build on top of it without restrictions. The community around it is active, and the skills are shareable through an open standard called agentskills.io.

Where to Go From Here

If this post made you curious, the best next step is just getting it running and having a real conversation with it. The documentation at hermes-agent.nousresearch.com covers everything from basic setup to advanced topics like voice mode, scheduled automations, and research pipeline configuration.

The Discord and GitHub Discussions are genuinely useful if you hit a wall - the community is active, and the team is responsive.

Happy to answer questions in the comments if anything here was unclear. What would you want a persistent, self-improving agent to do for you? Drop it below 👇

DEV Community: Sachin Shah

Integrating OpenClaw with Google Cloud: A Solo Developer's Guide

Why It Matters

What the System Does?

Architecture Overview

Runtime Request Flow

Setup: Prerequisites

Choosing a VM Machine Type

Step-by-Step Implementation

Step 1: Install and initialize the gcloud CLI

Step-by-Step Implementation

Step 1: Install and initialize the gcloud CLI

Step 2: Create and configure your GCP project

Step 3: Create the Compute Engine VM

Step 4: SSH into the VM

Step 5: Install Docker and basic tooling

Step 6: Clone the OpenClaw repository

Step 7: Create persistent host directories

Step 8: Configure the .env file

Step 9: Create the Docker Compose configuration

Step 10: Build and launch

Step 11: Set allowed origins for the Control UI

Step 12: Open the SSH tunnel and access the Control UI

Step 13: Complete onboarding

What Worked Well

Limitations and Trade-offs

Where to Go Next

Conclusion

FAQs

Why does my Docker build fail with "Killed" and exit code 137?

Is it safe to expose port 18789 publicly?

How do I access the gateway UI without keeping a terminal open?

What are the minimum server requirements?

Can I use Cloud Run instead of Compute Engine?

How much will this cost per month?

Hermes Agent: The AI That Actually Gets Smarter Every Time You Use It

What Exactly Is An Agent?

What Is Hermes Agent?

A Built-In Learning Loop

What Are Skills?

Key Takeaways

Supported environments

Connecting to platforms

Built-in tools

Browser agent

MCP support

Getting Started in 60 Seconds

What to Try First

Where to Go From Here

Step 8: Configure the `.env` file