DEV Community

qing chen
qing chen

Posted on

OpenClaw on DigitalOcean: A No-BS, Security-First Setup Guide

#ai #security #opensource #devops

I tested OpenClaw on a fresh DigitalOcean VPS to see whether it can be installed, configured with DeepSeek, and run safely without exposing the gateway to the public internet.

This is not a glossy "deploy in five minutes" walkthrough, and it is not a benchmark across multiple VPS providers. It is a hands-on setup note from one DigitalOcean Droplet, with the exact configuration, commands, problems, and security warnings I ran into.

Test Server Specs

For this test, I used a DigitalOcean Droplet with the following setup:

  • Provider: DigitalOcean
  • Region: NYC3
  • OS: Ubuntu 24.04 LTS x64
  • CPU/RAM: 2 vCPU / 4 GB RAM
  • Disk: 120 GB NVMe SSD
  • Price shown in the DigitalOcean dashboard: $32/month

DigitalOcean Droplet used for the OpenClaw test

I opted for the 4 GB RAM tier instead of skimping on the 1 GB or 2 GB entry-level Droplets because OpenClaw is not just a static web app. It runs an agent runtime, gateway process, model provider configuration, workspace files, plugins, and local state. A smaller VPS might still work for limited tests, but 4 GB gives you more room before memory-related issues start muddying the results.

Baseline Before Installation

Before installing OpenClaw, the server was almost empty:

  • Memory available: about 3.4 GiB
  • Disk used: about 2.0 GB out of 116 GB
  • Public listeners: SSH on port 22 only

This matters because it gives us a clean baseline. If something starts listening on a public port later, we can tell whether it came from OpenClaw or from the original server image.

Step 1: Connect to the Droplet

I connected as root over SSH:

ssh root@YOUR_SERVER_IP
Enter fullscreen mode Exit fullscreen mode

For a production server, I would normally create a non-root user and harden SSH. For this short test, I kept the setup simple and used the root SSH key created through DigitalOcean.

Step 2: Update the Server

On a fresh Ubuntu Droplet, I first updated the system:

apt update
apt upgrade -y
Enter fullscreen mode Exit fullscreen mode

This pulled a large number of Ubuntu updates and installed a newer kernel. After the update, the server required a reboot. I completed the reboot before continuing, because testing a new install on a half-updated system can create confusing results.

After reboot, the server was running:

Ubuntu 24.04.3 LTS
Linux kernel 6.8.0-117-generic
Enter fullscreen mode Exit fullscreen mode

Step 3: Install Node.js 24

OpenClaw used Node.js in this setup, so I installed Node.js 24 from NodeSource:

curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
Enter fullscreen mode Exit fullscreen mode

The installed versions were:

node v24.15.0
npm 11.12.1
Enter fullscreen mode Exit fullscreen mode

Step 4: Install OpenClaw

I installed OpenClaw using the official installer:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard
Enter fullscreen mode Exit fullscreen mode

The installer detected Linux and installed OpenClaw through npm.

After installation, the version check showed:

openclaw --version
Enter fullscreen mode Exit fullscreen mode

OpenClaw version check in the terminal

The installed version in this test was:

OpenClaw 2026.5.20 (e510042)
Enter fullscreen mode Exit fullscreen mode

Step 5: Run the First Doctor Check

After installation, I ran:

openclaw doctor --non-interactive
Enter fullscreen mode Exit fullscreen mode

At this point, OpenClaw was installed, but it was not fully configured yet. The doctor output reported several missing pieces, including:

  • Gateway mode was not set
  • Gateway authentication was not configured
  • No command owner was configured
  • Session store directory was missing
  • Gateway service was not installed

This is an important beginner note: installing OpenClaw does not mean the agent is ready to use. You still need to configure the model provider, gateway mode, authentication, and runtime behavior.

Step 6: Configure DeepSeek

For this test, I used DeepSeek as the model provider because it is a low-cost way to verify that OpenClaw can actually make a model call.

I ran:

openclaw onboard --install-daemon
Enter fullscreen mode Exit fullscreen mode

During onboarding, I selected:

  • Setup mode: QuickStart
  • Model provider: DeepSeek
  • Default model: deepseek-v4-flash
  • Skills configuration: skipped for now
  • Hatch mode: Terminal

I entered the DeepSeek API key interactively. Word of advice: never broadcast your API keys in screenshots, public logs, chat messages, or random Discord threads.

After onboarding, OpenClaw created a local gateway and configured DeepSeek as the default model provider.

Step 7: Check the Gateway Exposure

The most important safety check was whether OpenClaw exposed anything to the public internet.

I checked open ports with:

ss -tulpn
Enter fullscreen mode Exit fullscreen mode

The result after onboarding:

  • SSH was listening publicly on port 22
  • OpenClaw gateway was listening on 127.0.0.1:18789
  • OpenClaw also used 127.0.0.1:18791
  • No OpenClaw gateway port was exposed on 0.0.0.0

That is the safe outcome for a beginner VPS test. The gateway was running locally on the server, but it was not directly reachable from the public internet.

Do not expose 18789 publicly unless you fully understand OpenClaw gateway authentication, token handling, network access, and command permissions.

Step 8: Run Doctor Again

After onboarding and a permission fix, I ran:

openclaw doctor --non-interactive
Enter fullscreen mode Exit fullscreen mode

OpenClaw doctor output, first part

OpenClaw doctor output, second part

The updated doctor output looked much better than the first install-only check, but it still reported several useful warnings:

  • No command owner was configured
  • OAuth credentials directory was not present because no messaging channel was active
  • openclaw.json contained a plaintext gateway auth token
  • Some optional skills were not usable because their requirements were missing

For this test, those warnings were acceptable because I was only testing local terminal use. If you plan to connect Telegram, WhatsApp, Slack, or another messaging channel, you should configure a command owner and review the security warnings carefully.

I also fixed the .openclaw directory permission:

chmod 700 /root/.openclaw
Enter fullscreen mode Exit fullscreen mode

Step 9: Run a DeepSeek Smoke Test

The first non-interactive test I tried was:

openclaw chat --local --message "Reply with exactly: OpenClaw DeepSeek smoke test OK"
Enter fullscreen mode Exit fullscreen mode

That opened the local terminal UI, but it did not work well as a clean non-interactive smoke test in this environment.

The command that worked was:

openclaw agent \
  --local \
  --json \
  --session-id smoke-test-2 \
  --message "Reply with exactly: OpenClaw DeepSeek smoke test OK" \
  --timeout 90
Enter fullscreen mode Exit fullscreen mode

The response was exactly:

OpenClaw DeepSeek smoke test OK
Enter fullscreen mode Exit fullscreen mode

DeepSeek smoke test result, first part

DeepSeek smoke test result, second part

The JSON output confirmed:

  • Provider: deepseek
  • Model: deepseek-v4-flash
  • Result: success
  • Fallback used: false
  • Runner: embedded
  • Output text: OpenClaw DeepSeek smoke test OK

This confirms that the setup was not just installed. OpenClaw successfully called DeepSeek and completed a real agent response.

Resource Usage After Setup

After OpenClaw was installed, DeepSeek was configured, and the local gateway was running, the server still had enough room:

  • Total memory: about 3.8 GiB
  • Used memory after configuration: about 705 MiB
  • Available memory: about 3.1 GiB
  • Disk used: about 3.4 GB out of 116 GB

This does not prove that 4 GB RAM is enough for every OpenClaw workload. It only shows that the basic install, local gateway, and one short DeepSeek smoke test fit comfortably on this 4 GB DigitalOcean Droplet.

For longer tasks, browser automation, more plugins, or multiple users, you may need more memory.

Security Notes

Here are the main safety lessons from this test:

1. Do not expose the gateway publicly

In this setup, OpenClaw listened on loopback only:

127.0.0.1:18789
127.0.0.1:18791
Enter fullscreen mode Exit fullscreen mode

That is much safer than binding it to the public interface.

2. Treat the gateway token as sensitive

OpenClaw doctor warned that gateway.auth.token was stored as plaintext in openclaw.json.

For a short local test, this is manageable. For a long-running server, you should review OpenClaw's secrets workflow:

openclaw secrets configure
openclaw secrets audit --check
Enter fullscreen mode Exit fullscreen mode

3. Configure a command owner before connecting chat channels

The doctor output warned that no command owner was configured. If you connect OpenClaw to Telegram, WhatsApp, Slack, or another external channel, you should configure who is allowed to run privileged commands.

4. Keep screenshots clean

Before publishing screenshots, redact:

  • Public IP addresses
  • Private IP addresses
  • API keys
  • Tokens
  • Session secrets
  • Any login source IPs

Problems I Ran Into

The installation did work, but there were a few beginner traps:

The system update took longer than the OpenClaw install

The fresh Ubuntu image had many updates. The update and reboot were a real part of the setup time.

Install does not equal ready-to-use

After installation, openclaw doctor still showed missing gateway and auth configuration. You need onboarding or manual configuration.

openclaw chat --local --message was not the best smoke test

It opened a terminal UI instead of giving me a clean command-line result. For a scriptable smoke test, openclaw agent --local --json --session-id ... --message ... worked better.

Security warnings are real, not cosmetic

The doctor warnings around command owner and plaintext token are worth mentioning in any beginner tutorial. They are exactly the sort of thing that low-effort setup guides often skip.

Final Verdict

OpenClaw can be installed and run on a DigitalOcean Ubuntu 24.04 VPS with 2 vCPU and 4 GB RAM.

In this test:

  • The official installer worked
  • DeepSeek configuration worked
  • The local gateway started successfully
  • The gateway stayed on loopback and was not exposed publicly
  • A non-interactive DeepSeek smoke test succeeded

To be clear, this is far from a "one-click, set-it-and-forget-it" experience. You still need to understand:

  • Server updates and reboot
  • Node.js installation
  • Model provider configuration
  • Gateway exposure
  • Token handling
  • Command owner setup
  • Which warnings can be ignored for a local test and which should be fixed before public use

For a first safe test, a 4 GB VPS is a reasonable starting point. I would avoid the smallest 1 GB Droplet for OpenClaw unless you are only experimenting and expect to hit limits quickly.

Next Steps

The next things I would test are:

  • Running the same setup on a cheaper 2 GB VPS
  • Comparing DigitalOcean with Hostinger or Hetzner
  • Configuring OpenClaw as a proper service
  • Moving gateway secrets out of plaintext config
  • Connecting a messaging channel with a command owner configured
  • Testing a real task instead of a simple smoke test

For now, this first DigitalOcean test proves the basic path: OpenClaw installs, DeepSeek works, and the gateway can stay local-only.

Top comments (0)