Journey · Step 03

OpenClaw on the VPS

This is the point where the environment stopped being local-only. The laptop remained the active execution surface, but the persistent layer moved to a VPS so memory, orchestration, and cross-session continuity could live somewhere stable.

Move OpenClaw onto a private remote host, keep the service off the public internet, and make the remote side stable enough to act as the long-lived memory and orchestration layer behind the local tools.

1. Provision the VPS

Create the remote Linux host

The remote side runs on a private VPS. The exact instance size is less important than the role it plays: it is the durable machine that remains available independently of the laptop.

The sensible first route is to create the VPS in the provider panel, choose a Linux image, and confirm SSH access before doing anything else.

# local verification once the VPS exists
ssh user@example-vps
uname -a
pwd

2. Install the base runtime

Make the host capable of running OpenClaw

Once SSH works, install the runtime dependencies. The normal path is Node.js, npm, and then the OpenClaw CLI.

curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo bash -
sudo apt-get install -y nodejs
node --version
npm --version
npm install -g openclaw
openclaw --help

The point here is simple: if the CLI does not run cleanly on the VPS, there is no reason to proceed to configuration.

3. Initialize the remote OpenClaw workspace

Create the remote workspace and bootstrap files

After the CLI is installed, initialize OpenClaw on the VPS and bind it to a remote workspace directory.

mkdir -p ~/.openclaw/workspace
openclaw setup --workspace ~/.openclaw/workspace

At this point OpenClaw seeds the starter files. After setup, inspect the workspace to confirm that the remote side has the expected shape.

cd ~/.openclaw/workspace
find . -maxdepth 2 -type f | sort

4. Keep the gateway private

Bind the service to localhost and avoid public exposure

One of the key design choices preserved in memory is that the gateway stayed loopback-bound. That means the service listened on the VPS itself, not on a public interface.

# conceptual binding model
# gateway listens on 127.0.0.1
# external public access is not used for the memory layer

This matters because it sharply reduces exposure. The memory system is not a public web app and should not be treated like one.

5. Add Tailscale for private connectivity

Use a private network path between the laptop and the VPS

Tailscale is part of the security model here. It gives the laptop a private path to the VPS without turning the remote service into a public endpoint.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Once Tailscale is connected, the VPS is reachable over the tailnet, which gives the setup a controlled internal path for administration and service access.

6. Add a firewall on the VPS

Leave only the minimum public ports open

The provider firewall stays tight. Public ports are opened only when they are required for something actually intended to be public, such as the website itself.

# conceptual firewall model
# allow 80/tcp for public HTTP if needed
# allow 443/tcp for public HTTPS if needed
# keep SSH/admin access private or tightly restricted
# deny everything else by default

7. Bridge the local machine to the private service

Use an SSH tunnel where direct private service access is needed

The remembered setup also included a persistent SSH tunnel. That makes sense when the service stays loopback-bound on the VPS and the laptop needs a convenient local bridge to it.

ssh -N -L 3000:127.0.0.1:3000 user@example-vps

The exact port can vary. The design idea is the important part: use a local tunnel to reach a service that remains private on the remote host.

8. Expose OpenClaw into Claude Code through MCP

Install openclaw-mcp on the VPS and point Claude at it

Later in the evolution of the setup, openclaw-mcp was installed globally on the VPS and wired into Claude Code using the local MCP config file.

npm install -g openclaw-mcp

On the laptop side, the MCP server entry belongs in:

~/.claude/.mcp.json

That decision matters because the MCP config location has to be right or Claude Code simply will not load the server.

9. Verify the remote layer

Check both service reachability and tool visibility

Once the VPS side is configured, verify two things: the service is reachable through the private path, and the OpenClaw tools are visible where they are supposed to be visible.

# examples of the checks that matter
ssh user@example-vps
openclaw --help
tailscale status
# restart Claude Code after MCP config changes

Problem

Local-only context is fragile. It disappears with terminals, reboots, and tool restarts.

Result

OpenClaw becomes the persistent remote layer, reachable privately, stable across sessions, and ready to support the next stage of the system.