How to Set Up OpenClaw Safely on a Remote Server

A remote server gives you more control over data, network boundaries, and operating costs, but only if the deployment is actually hardened. A rushed OpenClaw server setup can leave SSH exposed, secrets sitting in shell history, ports open to the internet, and the service running with far more privilege than it needs.

This guide shows one clean path for an OpenClaw remote setup on an Ubuntu server using Docker Compose, a non-root service account, a local bind, and a reverse proxy in front. The exact package names may vary by host, but the pattern is what matters: small blast radius, explicit config, and simple operations.

If you want broader product context first, start at the VibeLab homepage. If you already know you need a deeper hardening checklist, keep an eye on the guide purchase button on this page because we will reference it twice in the walkthrough.

Start with a minimal Ubuntu host and create a dedicated operator account. Do not run your entire secure OpenClaw deployment as root.

sudo apt update && sudo apt upgrade -y
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo mkdir -p /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo cp ~/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh

Then harden SSH and enable a basic firewall:

sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl reload ssh
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

At this point, reconnect as deploy and keep root usage limited to package installs and system administration.

Containerizing OpenClaw makes it easier to keep the runtime isolated from the rest of the server. Install Docker from the distro packages if you want simplicity:

sudo apt install -y docker.io docker-compose-v2
sudo systemctl enable --now docker
sudo usermod -aG docker deploy
newgrp docker

Now create a predictable layout for your OpenClaw server setup:

mkdir -p ~/openclaw/{config,data,logs}
cd ~/openclaw
touch .env
chmod 600 .env

Keeping config, persistent data, and logs in one directory makes backups, auditing, and ownership checks much easier. It also prevents random copies of credentials from being scattered across the machine.

Your .env file should contain only the secrets and host-specific values you need. Keep it readable by the deploy user only.

cat > ~/openclaw/.env <<'EOF'
OPENCLAW_HOST=127.0.0.1
OPENCLAW_PORT=3000
OPENCLAW_DATA_DIR=/var/lib/openclaw
OPENCLAW_LOG_LEVEL=info
OPENCLAW_ADMIN_TOKEN=replace-with-long-random-string
EOF

Then create docker-compose.yml with a localhost bind so the app is not directly public:

cat > ~/openclaw/docker-compose.yml <<'EOF'
services:
  openclaw:
    image: ghcr.io/openclaw/openclaw:latest
    restart: unless-stopped
    env_file: .env
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - ./config:/app/config
      - ./data:/var/lib/openclaw
      - ./logs:/var/log/openclaw
    read_only: true
    tmpfs:
      - /tmp
EOF

The key decision here is the 127.0.0.1 bind. That single line removes a huge amount of exposure by forcing all public access through a proxy you control. If you want the broader operating checklist behind this pattern, The OpenClaw Security Guide is available here for $29.

Launch the stack and verify that OpenClaw is listening locally before you add TLS or DNS.

cd ~/openclaw
docker compose pull
docker compose up -d
docker compose ps
ss -ltnp | grep 3000
curl -I http://127.0.0.1:3000

You want to see the container running and the socket bound to 127.0.0.1:3000, not 0.0.0.0:3000. If the port is public, fix that before moving on. This is one of the easiest mistakes in an OpenClaw remote setup, and it defeats the point of using a reverse proxy in front.

Now expose the service safely with a reverse proxy. Caddy keeps the example short because it handles certificates automatically.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -fsSL https://dl.cloudsmith.io/public/caddy/stable/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -fsSL https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

Then configure the site:

sudo tee /etc/caddy/Caddyfile > /dev/null <<'EOF'
openclaw.example.com {
  reverse_proxy 127.0.0.1:3000
  encode gzip
  header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    X-Content-Type-Options "nosniff"
    X-Frame-Options "DENY"
  }
}
EOF
sudo systemctl reload caddy

At this stage you should have HTTPS termination, a private application port, and one clear ingress path. That is a much better starting point than exposing the app directly to the internet.

A secure OpenClaw deployment is not finished when the container starts. Add a few maintenance tasks so the server stays safe after day one.

crontab -e
# Example entries
0 3 * * * docker exec $(docker ps -qf name=openclaw) /app/bin/backup >> /home/deploy/openclaw/logs/backup.log 2>&1
15 3 * * 1 docker compose -f /home/deploy/openclaw/docker-compose.yml pull && docker compose -f /home/deploy/openclaw/docker-compose.yml up -d

Then run quick checks whenever you change the host:

docker compose logs --tail=100
sudo journalctl -u caddy -n 50 --no-pager
sudo ufw status
ls -lah ~/openclaw
stat -c '%a %n' ~/openclaw/.env ~/openclaw/config ~/openclaw/data

What you are looking for is boring stability: correct file permissions, no unexpected public listeners, clean restart behavior, and logs that do not spill secrets. Keep your admin token rotated and your base image updated.

That is the core setup. From here you can add IP allowlists, SSO in front of the proxy, or private networking if your environment supports it. If you want the fuller runbook for backups, incident response, and audit prep, buy The OpenClaw Security Guide for $29. It turns this starter deployment into a repeatable production checklist.