Haven't installed OpenClaw yet? Click here for one-line install commands
curl -fsSL https://openclaw.ai/install.sh | bash
iwr -useb https://openclaw.ai/install.ps1 | iex
curl -fsSL https://openclaw.ai/install.cmd -o install.cmd && install.cmd && del install.cmd
Worried about affecting your computer? ClawTank runs in the cloud with no installation — no risk of accidental deletion
Key Findings
  • OpenClaw Gateway is the central hub of the entire agent system, running on the default Port 18789 via the WebSocket protocol, responsible for task scheduling, Node management, and LLM request routing[1]
  • Gateway offers two operating modes — Local and Remote. Local mode binds only to 127.0.0.1, suitable for personal development; Remote mode with Token authentication supports cross-device and cross-network access[3]
  • Headless mode combined with systemd or Docker containerization enables 24/7 stable service on cloud servers without a graphical interface
  • Tailscale provides a zero-configuration secure VPN tunnel, eliminating the complexity of Port Forwarding and dynamic DNS — the best choice for personal and small-team remote access to the Gateway[4]
  • Gateway Token is the sole authentication mechanism in Remote mode. It is recommended to enable automatic rotation and pair it with TLS encrypted transport to ensure the agent system is not accessed without authorization[5]

When you first launch the OpenClaw tutorial, the system automatically starts a Gateway service on your local machine. You may never even realize it exists — it runs silently in the background, receiving every command you send from the CLI or Web UI, coordinating Nodes to execute tasks, and returning results. This seemingly transparent component is actually the nerve center of the entire OpenClaw agent architecture.[1]

Once your needs go beyond "running a few tasks on your own laptop" — for example, you want to remotely trigger agents from your phone, deploy a 24/7 automated workflow on a cloud VPS, or let team members share a single Gateway resource — you need to deeply understand Gateway's mode switching, deployment strategies, and security settings.

This article starts from Gateway's architectural role and systematically covers the configuration methods for both Local and Remote modes, the complete process for headless cloud deployment, Tailscale secure remote access, Gateway Token authentication mechanisms, and troubleshooting strategies for common production environment issues. Whether you're a developer just getting started with OpenClaw or a DevOps engineer planning cloud deployment, this guide will provide the technical reference you need.

1. What Is the Gateway? Its Role in the OpenClaw Architecture

Gateway is the unified entry point and scheduling core of the OpenClaw agent system. It runs as a WebSocket server on Port 18789 and serves as the sole hub for communication between all Nodes, Channels, and external Clients.[1]

1.1 Gateway's Position in the Four-Layer Architecture

OpenClaw's runtime architecture consists of four layers:

Gateway's responsibilities in this architecture go far beyond "message forwarding": it maintains a Task Queue for scheduling, manages context memory and conversation history for each Workspace, coordinates API requests to different LLM providers (rate limiting, key routing), and handles Node connection lifecycles (registration, heartbeats, disconnection recovery).

1.2 WebSocket Protocol & Port 18789

Gateway uses WebSocket rather than traditional HTTP as its core communication protocol because AI agent workflows are inherently bidirectional and long-lived — Nodes need to receive task assignments in real time, and Gateway needs to get execution progress and results in real time. WebSocket's full-duplex nature perfectly matches this requirement.[2]

The default Port 18789 falls within the IANA registered port range (1024–49151), making it less likely to conflict with common services. Gateway also provides HTTP endpoints on the same Port for health checks (/health), status queries (/status), and REST API access.

You can check the Gateway's running status at any time with the following command:

# Check Gateway running status
openclaw gateway status

# Expected output
# Gateway Status: running
# Mode: local
# Address: ws://127.0.0.1:18789
# Uptime: 2h 15m 32s
# Connected Nodes: 1
# Active Tasks: 0
# Queued Tasks: 0

If the Gateway is not running, openclaw gateway status will return Gateway Status: stopped, and you can start it manually:

# Manually start Gateway
openclaw gateway start

# Manually stop Gateway
openclaw gateway stop

# Restart Gateway
openclaw gateway restart

2. Local vs Remote Mode: Differences & Choosing

OpenClaw Gateway provides two core operating modes corresponding to two fundamentally different use cases. Understanding their differences is the first step to proper deployment.[3]

2.1 Local Mode

Bind Address: 127.0.0.1:18789 (loopback interface only)

Local mode is the default state after installation. Gateway only accepts connections from the same machine — external networks have no access at all. This is the safest configuration because the attack surface is limited to the local OS level.[5]

Use Cases:

Limitations:

2.2 Remote Mode

Bind Address: 0.0.0.0:18789 (all network interfaces) or a specified interface

Remote mode allows connections from any network. Once enabled, Gateway will require Token authentication to prevent unauthorized access.[4]

Use Cases:

Limitations:

2.3 Mode Comparison Quick Reference

Aspect Local Mode Remote Mode
Bind Address 127.0.0.1 0.0.0.0 or specified interface
Authentication None (isolated locally) Gateway Token required
External Access Not allowed Allowed (requires authentication)
TLS Recommendation Not needed Strongly recommended
Suitable Scale Single user, single machine Multiple users, multiple devices
Initial Setup Difficulty Zero configuration Moderate

3. Local Mode Configuration

Local mode is the simplest starting point. If you have a fresh OpenClaw installation, Gateway runs in Local mode by default — you don't need to do any additional configuration.[2]

3.1 Check Current Mode

# Check current Gateway mode
openclaw config get gateway.mode

# Expected output
# gateway.mode = "local"

3.2 Explicitly Set to Local Mode

If you've previously switched modes, or want to ensure you're running in Local mode:

# Set Gateway to Local mode
openclaw config set gateway.mode local

# Restart Gateway for settings to take effect
openclaw gateway restart

3.3 Verify Gateway Listening Address

After configuration, confirm that Gateway is indeed bound only to the loopback interface:

# Check Gateway status
openclaw gateway status

# Use system tools to confirm Port binding (macOS / Linux)
lsof -i :18789

# Expected to see binding on 127.0.0.1:18789
# COMMAND   PID     USER   FD   TYPE  SIZE/OFF NODE NAME
# openclaw  12345   user   8u   IPv4  0t0      TCP  127.0.0.1:18789 (LISTEN)

3.4 Custom Port

The default Port 18789 won't conflict in most cases. But if another service in your environment occupies this Port, you can change it:

# Change Gateway Port
openclaw config set gateway.port 28789

# Restart for changes to take effect
openclaw gateway restart

# Confirm new Port
openclaw gateway status
# Gateway Status: running
# Mode: local
# Address: ws://127.0.0.1:28789

After changing the Port, all CLI interactions will automatically detect the new Port. However, if you use external tools (such as custom scripts or API Clients) to connect to the Gateway, you'll need to update the connection address accordingly.

3.5 Gateway Configuration Block in openclaw.json

The CLI commands above are equivalent to modifying the corresponding fields in ~/.openclaw/openclaw.json:

// ~/.openclaw/openclaw.json (Gateway-related settings)
{
  "gateway": {
    "mode": "local",           // "local" or "remote"
    "port": 18789,             // Gateway listening port
    "host": "127.0.0.1",       // Automatically set to 127.0.0.1 in Local mode
    "websocket_path": "/ws",   // WebSocket endpoint path
    "auto_start": true,        // Auto-start Gateway when OpenClaw launches
    "log_level": "info"        // Log level: debug, info, warn, error
  }
}

Recommendation: Prefer using the openclaw config set CLI command to modify settings — it automatically handles format validation and dependency checks, avoiding syntax errors from manual JSON editing.[3]

4. Remote Mode Configuration

Remote mode is the critical step to exposing your OpenClaw Gateway to the network. Whether your goal is cross-device access, cloud deployment, or team collaboration, the following configuration process is required.[4]

4.1 Enable Remote Mode

# Switch to Remote mode
openclaw config set gateway.mode remote

# System will prompt you to set a Gateway Token (first time switching)
# > Remote mode requires a gateway token for authentication.
# > Run 'openclaw doctor --generate-gateway-token' to create one.

4.2 Generate and Set Gateway Token

Gateway Token is the sole authentication credential in Remote mode. All Clients and Nodes connecting to the Gateway must provide this Token during connection.[5]

# Generate a new Gateway Token
openclaw doctor --generate-gateway-token

# Example output
# Generated gateway token: ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
# Token has been saved to your configuration.
#
# To connect from another device, use:
#   openclaw config set gateway.url wss://YOUR_IP:18789/ws
#   openclaw config set gateway.token ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

4.3 Set Remote URL

On the client machine that needs to connect to the remote Gateway, set the Gateway's URL and Token:

# Set on the remote client (e.g., your phone or another computer)
openclaw config set gateway.url wss://your-server-ip:18789/ws
openclaw config set gateway.token ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

# Test the connection
openclaw gateway health
# Gateway healthy: wss://your-server-ip:18789/ws
# Authentication: OK

4.4 Remote Configuration for Cloud Deployment

If Gateway is deployed on a cloud VPS (such as AWS EC2, GCP Compute Engine, Linode, or DigitalOcean), it is recommended to pair it with a reverse proxy and TLS:

# On the cloud server
openclaw config set gateway.mode remote
openclaw config set gateway.host 127.0.0.1    # Gateway still binds to localhost
openclaw config set gateway.port 18789
openclaw doctor --generate-gateway-token

# Nginx or Caddy handles TLS and authentication forwarding at the frontend
# Client connection address: wss://gateway.yourdomain.com/ws

Important Security Principle: Even in Remote mode, it is not recommended to have Gateway directly listen on 0.0.0.0 and be exposed to the public internet. The correct architecture is for Gateway to continue binding to 127.0.0.1, with an Nginx/Caddy reverse proxy at the frontend accepting external TLS connections and forwarding them to Gateway via the local loopback.[7]

4.5 Complete openclaw.json Remote Configuration Example

// ~/.openclaw/openclaw.json (Full Remote mode configuration)
{
  "gateway": {
    "mode": "remote",
    "port": 18789,
    "host": "127.0.0.1",
    "websocket_path": "/ws",
    "auto_start": true,
    "log_level": "info",
    "token": "ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6",
    "allowed_origins": [
      "https://gateway.yourdomain.com",
      "https://app.yourdomain.com"
    ],
    "rate_limit": {
      "enabled": true,
      "max_requests_per_minute": 120,
      "max_connections": 50
    }
  }
}

5. Headless Operation: Deploying Gateway in Non-GUI Environments

OpenClaw's default startup process attempts to initialize GUI components (system tray icon, notification windows, etc.). On Linux servers without a desktop environment or in Docker containers, this causes startup failure. Headless mode skips all GUI initialization and only starts the Gateway core service.[6]

5.1 Basic Headless Startup

# Method 1: Foreground run (recommended for screen/tmux)
openclaw gateway run

# Method 2: Environment variable
export OPENCLAW_HEADLESS=true
openclaw gateway run

# Method 3: Write to config file then start
openclaw config set gateway.headless true
openclaw gateway run

5.2 Persistence with screen/tmux

Processes started in SSH sessions will terminate when the SSH connection drops. The simplest persistence solution is screen or tmux:

# Using screen
screen -S openclaw-gw
OPENCLAW_HEADLESS=true openclaw gateway run
# Press Ctrl+A then D to detach
# Later reconnect: screen -r openclaw-gw

# Using tmux (recommended)
tmux new-session -d -s openclaw -n gateway
tmux send-keys -t openclaw:gateway \
'OPENCLAW_HEADLESS=true openclaw gateway run' Enter

# Add a log monitoring window
tmux new-window -t openclaw -n logs
tmux send-keys -t openclaw:logs \
'tail -f ~/.openclaw/logs/gateway.log' Enter

# Reconnect: tmux attach -t openclaw

5.3 systemd Service Configuration (Recommended for Production)

For production environments that need boot auto-start, automatic restart, and system log integration, systemd is the standard choice:

# /etc/systemd/system/openclaw-gateway.service

[Unit]
Description=OpenClaw Gateway Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=openclaw
Group=openclaw
WorkingDirectory=/opt/openclaw
Environment="OPENCLAW_HEADLESS=true"
Environment="OPENCLAW_GATEWAY_HOST=127.0.0.1"
Environment="OPENCLAW_GATEWAY_PORT=18789"
Environment="OPENCLAW_LOG_LEVEL=info"
EnvironmentFile=-/opt/openclaw/.env
ExecStart=/usr/local/bin/openclaw gateway run
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal
SyslogIdentifier=openclaw-gateway

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/opt/openclaw/data /opt/openclaw/logs

# Resource limits
LimitNOFILE=65536
LimitNPROC=4096

[Install]
WantedBy=multi-user.target
# Create dedicated system user
sudo useradd -r -s /usr/sbin/nologin -d /opt/openclaw openclaw
sudo mkdir -p /opt/openclaw/{data,logs,config}
sudo chown -R openclaw:openclaw /opt/openclaw

# Enable and start the service
sudo systemctl daemon-reload
sudo systemctl enable openclaw-gateway
sudo systemctl start openclaw-gateway

# Check status and logs
sudo systemctl status openclaw-gateway
sudo journalctl -u openclaw-gateway -f

5.4 Docker Containerized Deployment

Docker provides the advantages of environment isolation and version management, making it the mainstream solution for cloud deployment:

# Dockerfile
FROM python:3.11-slim-bookworm

RUN apt-get update && apt-get install -y --no-install-recommends \
curl git ca-certificates && rm -rf /var/lib/apt/lists/*

RUN groupadd -r openclaw && useradd -r -g openclaw -d /app openclaw
WORKDIR /app

RUN pip install --no-cache-dir openclaw

RUN mkdir -p /app/data /app/logs && chown -R openclaw:openclaw /app
USER openclaw

ENV OPENCLAW_HEADLESS=true \
OPENCLAW_GATEWAY_HOST=0.0.0.0 \
OPENCLAW_GATEWAY_PORT=18789 \
OPENCLAW_DATA_DIR=/app/data \
OPENCLAW_LOG_DIR=/app/logs

EXPOSE 18789

HEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3 \
CMD curl -f http://localhost:18789/health || exit 1

CMD ["openclaw", "gateway", "start", "--headless"]
# docker-compose.yml
version: '3.8'

services:
openclaw-gateway:
  build: .
  container_name: openclaw-gw
  restart: unless-stopped
  env_file:
    - .env.gateway
  volumes:
    - openclaw-data:/app/data
    - openclaw-logs:/app/logs
  expose:
    - "18789"
  healthcheck:
    test: ["CMD", "curl", "-f", "http://localhost:18789/health"]
    interval: 30s
    timeout: 10s
    retries: 3

nginx:
  image: nginx:1.25-alpine
  container_name: openclaw-nginx
  restart: unless-stopped
  ports:
    - "443:443"
    - "80:80"
  volumes:
    - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    - /etc/letsencrypt:/etc/letsencrypt:ro
  depends_on:
    openclaw-gateway:
      condition: service_healthy

volumes:
openclaw-data:
openclaw-logs:
# Build and start
docker compose up -d --build

# View logs
docker compose logs -f openclaw-gateway

# Restart Gateway
docker compose restart openclaw-gateway

# Enter container for debugging
docker compose exec openclaw-gateway /bin/bash

6. Tailscale Remote Access: Zero-Configuration Secure VPN

Traditional remote access methods (Port Forwarding, dynamic DNS, self-signed certificates) are overly cumbersome for individual developers and error-prone. Tailscale offers an extremely simple alternative: an install-and-use WireGuard VPN tunnel that makes all your devices appear as if they're on the same local network.[4]

6.1 Why Choose Tailscale

6.2 Setup Process

# Step 1: Install Tailscale on the Gateway server
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# Step 2: Confirm Tailscale IP
tailscale ip -4
# e.g.: 100.64.0.1

# Step 3: Configure Gateway to listen on the Tailscale interface
openclaw config set gateway.mode remote
openclaw config set gateway.host 100.64.0.1
openclaw doctor --generate-gateway-token
openclaw gateway restart

# Step 4: Install Tailscale on client devices and connect
# (macOS / Windows / iOS / Android all supported)
sudo tailscale up

# Step 5: Configure Gateway connection on the client
openclaw config set gateway.url ws://my-server.tailnet-name.ts.net:18789/ws
openclaw config set gateway.token ogt_your_token_here

# Test connection
openclaw gateway health

6.3 Tailscale ACL Access Control

Tailscale's ACL (Access Control List) lets you precisely control which devices can access the Gateway:

// tailscale ACL policy (configured in Tailscale Admin Console)
{
"acls": [
  {
    "action": "accept",
    "src": ["tag:openclaw-client"],
    "dst": ["tag:openclaw-gateway:18789"]
  }
],
"tagOwners": {
  "tag:openclaw-gateway": ["autogroup:admin"],
  "tag:openclaw-client": ["autogroup:admin"]
}
}

6.4 Tailscale Funnel (Advanced: Public Sharing)

If you need to let external users without Tailscale access your Gateway (e.g., to demo for a client), you can use Tailscale Funnel to temporarily make it public:

# Temporarily expose Gateway to the Internet (automatic HTTPS)
tailscale funnel 18789

# External users can access via the following address
# https://my-server.tailnet-name.ts.net/

# Disable Funnel
tailscale funnel --reset

Note: Funnel exposes your Gateway to the public internet. Even with Tailscale's HTTPS encryption, make sure the Gateway Token is set to prevent unauthorized access.[8]

7. Gateway Token Security

Gateway Token is the last line of defense protecting your entire computer in Remote mode. The OpenClaw agent has the ability to execute Shell commands, manipulate the file system, and control the browser — meaning anyone who obtains your Gateway Token can theoretically do anything to your machine.[5][7]

7.1 Token Generation & Format

# Generate new Token
openclaw doctor --generate-gateway-token

# Token format: ogt_ prefix + 32-character random string
# Example: ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

# Manually specify Token (not recommended unless there's a special need)
openclaw config set gateway.token "your-custom-token-here"

7.2 Token Rotation

Regularly changing Tokens is a security best practice, especially in the following scenarios:

# Regenerate Token (old Token immediately invalidated)
openclaw doctor --generate-gateway-token --force

# All connected Clients and Nodes will be forcibly disconnected
# Need to update the new Token on each client
openclaw config set gateway.token ogt_new_token_here

7.3 Security Best Practices

# View recent authentication failure records
openclaw logs --follow --limit 100

# Configure authentication failure lockout (block source IP for 15 minutes after 5 consecutive failures)
openclaw config set gateway.security.max_auth_failures 5
openclaw config set gateway.security.lockout_duration_minutes 15

7.4 Managing Tokens via Environment Variables

In automated deployments, Tokens should be injected via environment variables rather than written into configuration files:

# .env.gateway (do not commit to version control)
OPENCLAW_GATEWAY_TOKEN=ogt_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...

# Use in systemd
EnvironmentFile=/opt/openclaw/.env.gateway

# Use in Docker Compose
env_file:
- .env.gateway

# Ensure file permissions for .env.gateway
chmod 600 /opt/openclaw/.env.gateway
chown openclaw:openclaw /opt/openclaw/.env.gateway

8. Common Issues & Troubleshooting

Below is a compilation of the most common problems and solutions encountered when deploying OpenClaw Gateway.[3]

8.1 Port Conflict

Symptom: Gateway fails to start; logs show Address already in use: 0.0.0.0:18789

# Check who is occupying Port 18789
sudo lsof -i :18789
# or
sudo ss -tlnp | grep 18789

# Common cause: previous Gateway process didn't exit cleanly
# Solution 1: Kill the occupying process
sudo kill -9 $(lsof -t -i :18789)

# Solution 2: Use a different Port
openclaw config set gateway.port 28789
openclaw gateway restart

8.2 Remote Mode Connection Failure

Symptom: Client cannot connect to remote Gateway, showing Connection refused or Connection timed out

# Troubleshoot Step 1: Confirm Gateway is running
openclaw gateway status

# Troubleshoot Step 2: Confirm Gateway listening address
ss -tlnp | grep 18789
# If it shows 127.0.0.1:18789, Gateway only accepts local connections
# Need to pair with a reverse proxy or Tailscale

# Troubleshoot Step 3: Confirm firewall rules
sudo ufw status
sudo iptables -L -n | grep 18789

# Troubleshoot Step 4: Test network connectivity
# Run on the client
curl -v http://your-server-ip:18789/health
# or (if using a reverse proxy)
curl -v https://gateway.yourdomain.com/health

# Troubleshoot Step 5: Confirm Token is correct
openclaw config get gateway.token

8.3 WebSocket Connection Drops

Symptom: Tasks disconnect mid-execution; logs show WebSocket connection closed unexpectedly

# Most common cause: reverse proxy Timeout setting is too short

# Nginx fix: increase proxy_read_timeout
# /etc/nginx/conf.d/openclaw.conf
location /ws {
  proxy_pass http://127.0.0.1:18789;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_read_timeout 3600s;    # At least 1 hour
  proxy_send_timeout 3600s;
  proxy_connect_timeout 30s;
}

# Gateway-side fix: adjust heartbeat interval
openclaw config set gateway.websocket.ping_interval 30
openclaw config set gateway.websocket.ping_timeout 10

8.4 Headless Startup Failure

Symptom: Shows cannot open display or Gtk initialization failed when starting on a GUI-less server

# Use foreground mode (no GUI needed)
openclaw gateway run

# Or set environment variables
export OPENCLAW_HEADLESS=true
export DISPLAY=    # Clear the DISPLAY variable

# Confirm Node.js version (requires 22+)
node --version

# Confirm OpenClaw is properly installed
openclaw --version

8.5 Gateway Status Query Command Reference

# Full status report
openclaw gateway status --deep

# JSON format output (convenient for script processing)
openclaw gateway status --json

# Health check (suitable for monitoring systems)
openclaw gateway health
curl -s http://127.0.0.1:18789/health | python3 -m json.tool

9. Cloud Deployment Architecture Recommendations

Based on team size and reliability requirements, here are three cloud deployment architecture recommendations.

9.1 Personal / Small Projects: VPS + Caddy

The lowest cost, least maintenance burden deployment. Suitable for individual developers or 1-3 person teams.

# Architecture Topology
[Client Devices] --wss--> [Caddy :443] --> [Gateway :18789] --> [LLM APIs]

# Caddyfile (automatic TLS)
gateway.yourdomain.com {
reverse_proxy /ws localhost:18789 {
  header_up Upgrade {http.upgrade}
  header_up Connection "Upgrade"
  transport http {
    read_timeout 1h
    write_timeout 1h
  }
}
reverse_proxy localhost:18789
}

# Recommended VPS specs: 2 vCPU / 4 GB RAM / 40 GB SSD
# Monthly cost: ~$5-$20 USD (Linode, DigitalOcean, Vultr)

9.2 Mid-Size Teams: Docker Compose + Nginx + Monitoring

Suitable for 5-20 person teams that need formal monitoring and logging infrastructure.

# Architecture Topology
[Multiple Clients] --wss--> [Nginx :443]
                          |
                    [Gateway :18789]
                          |
              +-----------+-----------+
              |           |           |
          [Prometheus] [Grafana]  [Loki]

# Deployment command
docker compose -f docker-compose.yml \
-f docker-compose.monitoring.yml up -d

9.3 Production Environment Checklist

Before pushing Gateway to production, verify each item:[7][8]

Security

Reliability

Performance

Resource Planning

Scale Concurrent Tasks CPU Memory Storage
Personal 1-3 2 vCPU 4 GB 20 GB SSD
Small Team 5-10 4 vCPU 8 GB 50 GB SSD
Enterprise 20+ 8+ vCPU 16+ GB 200 GB NVMe

9.4 Automated Backup Script

#!/bin/bash
# /opt/scripts/backup-openclaw.sh
set -euo pipefail

BACKUP_DIR="/backups/openclaw"
DATE=$(date +%Y%m%d-%H%M%S)
RETENTION_DAYS=30

mkdir -p "$BACKUP_DIR"

# Backup Workspace data
tar czf "$BACKUP_DIR/workspace-$DATE.tar.gz" \
/opt/openclaw/data/

# Backup configuration (excluding sensitive .env files)
tar czf "$BACKUP_DIR/config-$DATE.tar.gz" \
/opt/openclaw/config/

# Clean old backups
find "$BACKUP_DIR" -name "*.tar.gz" \
-mtime +$RETENTION_DAYS -delete

echo "[$(date)] Backup completed: workspace-$DATE.tar.gz"
# Add to Cron for daily backup at 2 AM
echo "0 2 * * * /opt/scripts/backup-openclaw.sh >> /var/log/openclaw-backup.log 2>&1" \
| sudo crontab -u openclaw -

Conclusion

Switching OpenClaw Gateway from Local to Remote mode is essentially a mindset shift from "personal tool" to "infrastructure." In Local mode, Gateway is a quiet background service on your laptop; in Remote mode, it becomes a network service that needs to be taken seriously — requiring authentication, encryption, monitoring, backups, and a disaster recovery plan.

The deployment paths covered in this article can be summarized in three progressive stages:

Which stage to choose depends on your specific needs. A personal developer's automation assistant may find the Tailscale approach to be the optimal solution; an agent platform serving enterprise users would need the full Docker + reverse proxy + monitoring stack.[6]

As the OpenClaw community continues to grow,[2] Gateway features are also evolving rapidly. It is advisable to closely follow updates in the official documentation regarding cluster coordination, multi-Gateway synchronization, and Zero-Trust security models — these will determine the critical path for OpenClaw's evolution from a personal productivity tool to an enterprise-grade AI agent platform.[1]