Run OpenClaw Securely on a Debian Cloud Server: A Complete Guide from Setup to Hardening

Deploying OpenClaw to a cloud server sounds straightforward: install the environment, start the service, open a port, and access it remotely.

But that is exactly where the real problem begins.

Many people instinctively treat it like a normal web app, bind it to a public address, and open the port. That may be enough to make it work, but it is usually not the safest way to run something like OpenClaw. For a long-lived system that can connect to messaging channels and may hold keys or stateful data, the most important step is not getting it online first. It is tightening the boundary first.

This article lays out a more conservative deployment pattern:

Debian cloud server
OpenClaw running under rootless Podman
Gateway bound only to localhost
Remote access only through an SSH tunnel
Token authentication enabled by default
Minimal tool permissions kept by default
Sandboxing and DM isolation enabled by default

The goal is not “the fastest way to go live.” The goal is: run OpenClaw in a way that is closer to a long-lived production setup while minimizing its exposed surface area.

1. The Deployment Strategy

Here is the short version.

On a Debian cloud server, one of the safest ways to deploy OpenClaw is:

Harden the Debian host itself first
Install OpenClaw with rootless Podman
Bind the gateway only to 127.0.0.1
Access the Control UI only through an SSH tunnel
Enable token authentication by default
Disable high-risk tool capabilities by default
Run sessions inside a sandbox by default
Perform security audits and health checks regularly

If this is for personal use or a clearly trusted boundary, this architecture is usually simpler and safer than “public exposure plus reverse proxy.”

2. What the Final Architecture Should Look Like

When the deployment is complete, the system should look like this:

The Debian server exposes only 22/tcp
OpenClaw runs inside a rootless Podman container
The OpenClaw gateway listens on 127.0.0.1:18789
The Control UI is not exposed publicly
Your local machine reaches the web UI through an SSH tunnel
Pairing stays enabled for messaging channels
Tool permissions are minimized by default
Sessions run inside sandboxes by default

The core design idea is simple:

Treat OpenClaw as your private gateway, not as a public bot platform.

3. Prerequisites

This article assumes you already have:

A Debian cloud server
A normal admin account with sudo
A local machine that can connect to the server over SSH

It is strongly recommended not to use root as your everyday admin account.

4. Debian Commands You Can Run Directly

The commands below are split into two execution contexts: your local machine and the server.

4.1 Generate an SSH key on your local machine and log in

Run the following on your own computer first:

export VPS_USER="your_admin_user"
export VPS_HOST="your.server.ip.or.domain"

ssh-keygen -t ed25519 -C "openclaw-debian"
ssh-copy-id "${VPS_USER}@${VPS_HOST}"
ssh "${VPS_USER}@${VPS_HOST}"

The purpose is straightforward: make sure SSH public-key login already works before you harden SSH further. Later we will disable password login, so this step must succeed first.

4.2 Update the system and install the base dependencies on the server

Everything below is assumed to run on the server:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y git curl openssl podman nftables unattended-upgrades apt-listchanges

These packages cover the full deployment baseline:

git: clone the OpenClaw source
curl, openssl: common helper tools
podman: run OpenClaw rootlessly
nftables: host firewall
unattended-upgrades: automatic security updates
apt-listchanges: review package changes before upgrades

4.3 Enable automatic security updates

sudo tee /etc/apt/apt.conf.d/20auto-upgrades >/dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF

sudo systemctl enable --now unattended-upgrades

This is easy to skip, but it matters a lot on long-running servers. You may not log in every day to update manually, but security patches should still keep flowing.

One more reminder: make sure public-key login already works before doing this.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M%S)

sudo tee /etc/ssh/sshd_config.d/99-openclaw-hardening.conf >/dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin no
UsePAM yes
X11Forwarding no
EOF

sudo sshd -t
sudo systemctl reload ssh

After this, the server accepts only public-key login and blocks both password login and direct root login.

This is not an advanced hardening trick. It is one of the most basic and most valuable things you can do on a cloud server.

4.5 Configure nftables: default-deny inbound, allow only SSH

sudo tee /etc/nftables.conf >/dev/null <<'EOF'
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    iif lo accept
    ct state established,related accept

    tcp dport 22 accept

    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;
  }

  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}
EOF

sudo systemctl enable --now nftables
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

Notice that this configuration intentionally does not open port 18789.

Later, the OpenClaw gateway will bind only to 127.0.0.1, so there is no reason for that port to be reachable from the public internet. This is one of the biggest differences between this guide and many “just make it work” deployment tutorials.

5. Install OpenClaw

5.1 Clone the source and install with Podman

cd /opt
sudo git clone https://github.com/openclaw/openclaw.git
cd /opt/openclaw

sudo ./setup-podman.sh --quadlet

This step does several things:

Creates a dedicated openclaw user
Builds and prepares the container runtime environment
Installs startup scripts
Registers the service as a systemd Quadlet user service

That means OpenClaw does not run directly as root, which gives you a much cleaner privilege boundary for long-term operation.

5.2 Check the OpenClaw service status

sudo systemctl --machine openclaw@ --user status openclaw.service
sudo journalctl --machine openclaw@ --user -u openclaw.service -f

If the service fails to start, look at the logs first instead of reinstalling blindly. Many environment or configuration issues are spelled out clearly in the logs.

5.3 Run the onboarding setup

cd /opt/openclaw
sudo ./scripts/run-openclaw-podman.sh launch setup

This prepares the initial configuration and usually generates a default token in ~openclaw/.openclaw/.env.

5.4 View the generated token

sudo -u openclaw grep '^OPENCLAW_GATEWAY_TOKEN=' /home/openclaw/.openclaw/.env

You will need this token later when you access the Control UI.

6. Write a Secure Baseline Configuration

Now write a conservative baseline config that fits a personal deployment:

sudo -u openclaw tee /home/openclaw/.openclaw/openclaw.json >/dev/null <<'EOF'
{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "port": 18789,
    "controlUi": {
      "enabled": true
    },
    "auth": {
      "mode": "token",
      "token": "${OPENCLAW_GATEWAY_TOKEN}"
    }
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "tools": {
    "profile": "messaging",
    "fs": {
      "workspaceOnly": true
    },
    "deny": [
      "group:runtime",
      "group:fs",
      "group:automation",
      "browser",
      "sessions_spawn"
    ]
  },
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "all",
        "scope": "agent",
        "workspaceAccess": "none"
      }
    }
  }
}
EOF

In plain language, this configuration means:

Listen only on loopback, never on a public address
Require token authentication
Isolate DMs per channel and peer
Start with a conservative tool set and no execution-heavy capabilities
Restrict filesystem access to the workspace
Run every session in a sandbox
Do not grant workspace access to the host by default

For a personal deployment, this is a strong starting point. If you need more capability later, open things up one piece at a time instead of turning everything on up front.

6.1 Tighten permissions on the OpenClaw config directory

sudo chmod 700 /home/openclaw/.openclaw
sudo chmod 600 /home/openclaw/.openclaw/openclaw.json
sudo chown -R openclaw:openclaw /home/openclaw/.openclaw

The ~/.openclaw directory often contains config, credentials, state, and logs. If its permissions are too broad, many of the earlier safeguards become much weaker.

6.2 Restart the service so the new config takes effect

sudo systemctl --machine openclaw@ --user restart openclaw.service
sudo systemctl --machine openclaw@ --user status openclaw.service

At this point, OpenClaw is essentially deployed.

7. Access the Control UI Through an SSH Tunnel

Do not open any new firewall ports. Instead, return to your local machine and run:

export VPS_USER="your_admin_user"
export VPS_HOST="your.server.ip.or.domain"

ssh -N -L 18789:127.0.0.1:18789 "${VPS_USER}@${VPS_HOST}"

Then open this URL in your local browser:

http://127.0.0.1:18789/

Your browser is connecting to your own local 127.0.0.1:18789, and SSH securely forwards that traffic to the OpenClaw gateway on the server.

During the whole process, OpenClaw itself is never exposed directly to the public internet.

That is exactly why we did not open port 18789 earlier.

8. Why Keeping Pairing Enabled Is a Good Idea

After deployment, many people want to connect Telegram, Signal, or other messaging channels right away.

The easiest mistake here is thinking: “To save time, I will just let anyone DM the bot.”

A safer default is to keep pairing enabled.

That means:

When an unknown sender contacts the bot for the first time, they receive a one-time pairing code.
Their messages become actionable only after you manually approve them.

Typical commands look like this:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Or:

openclaw pairing list signal
openclaw pairing approve signal <CODE>

If you later add the bot to group chats, it is also a good idea to keep mention gating enabled so that arbitrary messages do not trigger it.

9. Day-to-Day Operations After Deployment

Once OpenClaw is running, the ongoing maintenance habits matter more than the initial install.

Treat the following commands as part of your regular checklist:

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw secrets audit
openclaw doctor

They cover different layers of inspection:

security audit: finds obvious configuration risks
security audit --deep: runs a more thorough review
security audit --fix: automatically remediates some issues
secrets audit: checks whether keys and sensitive settings are handled properly
doctor: runs a broader health check

If you later change sandbox settings, it is a good idea to run:

openclaw sandbox recreate --all

That ensures the new sandbox policy actually takes effect instead of leaving old container state in place.

10. Common Pitfalls

This section is worth reading carefully, because many problems are not “I do not know how to install it.” They are “It looks fine, but it is not actually safe or stable.”

10.1 Binding directly to `0.0.0.0`

This is the most common mistake and also the most dangerous.

It may feel convenient for remote access, but it expands the attack surface immediately. A safer choice is to keep loopback-only binding and use SSH tunneling or another tightly controlled access layer.

10.2 Allowing port 18789 through the firewall

Even if you think “there is a token anyway,” it is still better not to expose it. Authentication is not a substitute for network boundaries. It is the second door, not the first.

10.3 Enabling every tool capability on day one

Execution tools, filesystem access, automation, and browser capabilities are all high-risk features. The right approach is not “turn everything on and fix it later.” It is “start tight and loosen only what you truly need.”

10.4 Leaving config and key permissions too broad

If other local users can read ~/.openclaw, many of your protections become fragile. Directory permissions matter just as much as service config.

10.5 Skipping follow-up checks

Many deployment guides stop once the service starts. But long-running systems usually fail not because the first install was hard, but because six months later nobody remembers how it was configured, what permissions changed, or whether any audits were ever run.

11. When to Consider Tailscale or a Reverse Proxy

This article intentionally does not start with public domain exposure, because that is not the most conservative first move.

A more sensible order is usually:

Start with SSH tunneling
Then consider Tailscale
Only then consider a public reverse proxy plus extra authentication

In other words, first make the system stable with minimal exposure, then improve convenience gradually.

12. Pre-Launch Checklist

Before you rely on the deployment long term, run through this checklist:

If you still have unchecked items here, it is best to fix them before connecting any live messaging channels.

Closing Thoughts

When you deploy OpenClaw on a cloud server, the real goal is not “make it run as quickly as possible.” The goal is “make it run in a way you can trust for the long term.”

That is why the core theme of this guide stays the same throughout:

Do not rush to expose it publicly
Do not rush to enable high-risk tools
Do not rush to let everyone connect
Tighten the system boundary, access path, and default permissions first

An OpenClaw deployment built this way may look a little conservative, but it is usually much better suited to real-world long-term use.