🚀 Getting Started

Follow these steps to get your instance running as a Droplet on DigitalOcean (DO).

1. Deploy the Droplet

Deploy the OpenClaw 1-Click App from the DigitalOcean Marketplace.
Wait for the droplet to finish provisioning.
Note: The DO dashboard may say “ready” before the SSH service is actually available.

2. Connect via SSH

Access your droplet using the terminal:

ssh root@your-droplet-ip

If SSH fails initially, wait 60 seconds and retry.
A welcome message will appear upon successful login.

3. Interactive Configuration

Follow the automated setup flow:

LLM Provider: Choose DigitalOcean Serverless Inference, OpenRouter, OpenAI, or Anthropic.
API Key: Paste your provider’s API key when prompted.
The openclaw service will restart automatically to apply changes.
Dashboard Pairing: Follow instructions to open the Dashboard and pair with it.

Once pairing is complete, the dashboard will no longer show any errors and will show "connected". You should verify you can chat with the agent.

4. Manual Configuration (Optional)

If you need to update settings, edit the environment file directly:

# Edit configuration
nano /opt/openclaw.env

# Restart service to apply changes
systemctl restart openclaw

This file manages AI providers, gateway settings, and messaging channels.

5. Verify Installation

Launch the Terminal UI (TUI) to confirm the service and LLM are functioning:

/opt/openclaw-tui.sh

6. Access the Web Dashboard

Copy the Dashboard URL provided in the login welcome message.
Open the URL in your browser to verify the web interface loads.

7.Proceed to configure messaging channels (Telegram, Discord, WhatsApp, etc.)

Setting up WhatsApp as a Channel

Run /opt/openclaw-cli.sh channels add
Go through the onboarding process in the CLI to add a channel. Select WhatsApp.
Eventually you’ll be presented with a QR code to scan. Scan the QR code with your phone in WhatsApp to pair.
Go through the pairing process on your phone.

Setting up Telegram as a Channel

Start the channel setup flow by running /opt/openclaw-cli.sh channels add.
Go through the onboarding prompts in the CLI and select Telegram as the channel. 1. The CLI will pause and wait for a Telegram bot token.
Open Telegram and start a chat with @BotFather.
Create a new bot by typing /newbot and follow the prompts: 1. Choose a display name
1. Choose a unique bot username (must end in bot)
Once the bot is created: 1. BotFather will confirm creation
1. You’ll receive a bot token
2. You’ll also receive a deep link like https://t.me/your_bot_name
Copy the bot token and paste it back into the waiting CLI prompt to complete the channel setup.
Open the deep link to start a chat with your new bot. 1. You’ll see a message like Clawdbot: access not configured
1. This is expected.
Copy your Telegram user ID from the message.
Open the OpenClaw Gateway Dashboard (URL shown when you SSH’d into the droplet).
Add your Telegram user ID to the allow list in the dashboard.
Return to Telegram and send a message to the bot to confirm it’s working.

🛠 Troubleshooting & Commands

Task	Command
Check Service Status	`systemctl status openclaw`
View Live Logs	`journalctl -u openclaw -f`
Edit Environment	`nano /opt/openclaw.env`
Start TUI	`/opt/openclaw-tui.sh`

```

Security Configuration

Resources

Support

For issues and questions:

OpenClaw on DigitalOcean – FAQ

Common questions from people setting up OpenClaw using the one-click droplet.

"It's stuck in a sandbox and can't run commands. It's basically just a chat agent now."

This is the most common issue after a fresh install. OpenClaw is working – but it's locked down to the point where it can't actually do anything useful.

By default, OpenClaw runs in a restricted sandbox mode. It can't make network calls, can't run shell commands, and can't write to most directories. That's a safe default, but it means the agent can only chat. It can't execute skills, call APIs, or interact with anything outside itself.

To fix this, you need to set three execution policies. SSH into your droplet and run these as root:

/opt/openclaw-cli.sh config set tools.exec.host gateway
/opt/openclaw-cli.sh config set tools.exec.ask off
/opt/openclaw-cli.sh config set tools.exec.security full

Then restart the service:

systemctl restart openclaw

Here's what each one does:

tools.exec.host gateway – Tells OpenClaw to route commands through its gateway process. On a VPS there's no terminal window open, so without this, commands have nowhere to run. They'll either fail or hang.
tools.exec.ask off – Disables the "are you sure?" approval prompts. On a local machine those are fine – you see the prompt and approve it. On a headless server, nobody's there to approve anything, so commands just hang forever waiting.
tools.exec.security full – Gives OpenClaw the highest execution tier within its sandbox. This is the big one. Without it, the agent can't make network calls, run shell commands, or do much beyond generating text. This does not give it root access – the openclaw user still can't touch system files or escalate privileges.

After setting all three and restarting, OpenClaw should go from "just a chatbot" to actually being able to run skills and execute commands.

To verify your settings are correct:

/opt/openclaw-cli.sh config list | grep tools.exec

You're looking for host: gateway, ask: off, and security: full.

"It's too expensive."

DigitalOcean now supports multiple ways to run OpenClaw. One-click droplets start as low as $12/month, and you can also deploy on App Platform. You don't need a large instance to get started.

"How do I add this to an existing droplet? The official one-liner crashed my terminal."

The one-click droplet is for new installs only – it's not something you can add to an existing server. The Marketplace image provisions a fresh droplet with everything preconfigured (the openclaw user, the gateway, the sandbox, Homebrew, etc.). Trying to run the install script on an existing droplet with its own packages, users, and config is likely why it crashed.

If you want OpenClaw, spin up a new droplet from the Marketplace listing. It takes a few clicks and you'll have a clean, working setup.

"How can I update it to the latest version?"

The short version – if you're on a one-click droplet (v2.3 or later), run /opt/update-openclaw.sh as root.

"I'm getting a 'permission denied public key' error."

This is usually an API key issue, not an SSH key issue. Try generating a new model access key, or switch to a different inference provider. If the key is invalid or expired, OpenClaw can surface misleading error messages.

"Everything worked until the TUI started, but my bot doesn't respond to messages."

This can happen for a couple of reasons. First, try sending another message – sometimes the first one is slow and needs a second nudge to get going. If it still doesn't respond, check your API key. An invalid or expired key will cause the agent to silently do nothing. Verify the key is correct in /opt/openclaw.env and restart the service (systemctl restart openclaw as root).

"Can I configure another provider like OpenRouter after install by editing the JSON config?"

Same answer as above – not officially supported yet, but likely coming. OpenClaw has been adding support for custom providers, so this may become possible through the config.

"It can't access the internet." / "Can I safely let it access the internet for research?"

By default, the sandbox blocks outbound network access. That's the safe default, but it means the agent can't call APIs, fetch web pages, or do much beyond generating text.

Yes, you can safely unlock this. That's what the tools.exec.security full setting is for. It unlocks network access, shell commands, and other capabilities the agent needs to actually be useful.

It's safe on a dedicated droplet because the openclaw user is still sandboxed. It can't touch system files, can't escalate to root, and can't modify its own environment config. You're loosening restrictions inside the sandbox, not removing the sandbox itself.

See the sandbox and execution policies answer above for the full setup steps.

"My skill installed but isn't doing anything."

Check these in order:

Are the required environment variables in /opt/openclaw.env?
Are the execution policies set correctly? Run /opt/openclaw-cli.sh config list | grep tools.exec as root to verify.
Did you restart the service after making changes? systemctl restart openclaw as root.

"I get 'permission denied' when editing `/opt/openclaw.env`."

That's expected. You're probably logged in as openclaw. Run exit to get back to root, then edit the file.

"I changed the env file but nothing changed."

You need to restart the service. Run systemctl restart openclaw as root. The env file is only read at startup.

"My skill fails silently – no errors, no output."

This is almost always the tools.exec.security setting. At lower tiers, OpenClaw will quietly block operations without telling you. Set it to full as root and restart.

"Commands seem to hang forever."

Two likely causes. If tools.exec.host isn't set to gateway, execution has nowhere to run on a headless VPS. If tools.exec.ask isn't set to off, commands are waiting for approval that nobody can give. Set both and restart.

"Which user should I be for what?"

Installing skills, running tools → openclaw
Editing env vars, setting policies, restarting the service → root

"Everything worked until the TUI started, but my bot doesn't respond to messages."

This can happen for a couple of reasons. First, try sending another message – sometimes the first one is slow and needs a second nudge to get going. If it still doesn't respond, check your API key. An invalid or expired key will cause the agent to silently do nothing. Verify the key is correct in /opt/openclaw.env and restart the service (systemctl restart openclaw as root).

"It can't access the internet. It's running completely lobotomized."

Same issue as above. By default, the sandbox blocks outbound network access. The fix is the same – set the three execution policies (especially tools.exec.security full) and restart the service. See the previous answer for the full steps.

The security full setting is the one that unlocks network access. Without it, OpenClaw can't call APIs, fetch URLs, or reach any external service. It's not a bug – it's the default security posture. But on a dedicated droplet where you control what's installed, full is the right setting.

"Which user should I be for what?"

Installing skills, running tools → openclaw
Editing env vars, setting policies, restarting the service → root

Testing the OpenClaw 1-Click Control UI (origin + pairing)

Use these checks on a fresh or re-provisioned Droplet after the first-login wizard (or after editing config manually).

Public IP matches browser URL (avoids origin not allowed):

curl -fsS http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address
   jq -r '.gateway.controlUi.allowedOrigins[]?' /home/openclaw/.openclaw/openclaw.json

You should see https://&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;that-public-ip&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt; in allowedOrigins. Open the Control UI at exactly that URL.

Caddy proxies to the gateway:

systemctl is-active caddy openclaw
   curl -skI "https://$(curl -fsS http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)/" | head -5

Pairing after "pairing required": In the browser, paste the gateway token and click Connect. Then on the Droplet:

sudo /opt/openclaw-approve-ui-pairing.sh

Refresh the browser. For debugging:

TOKEN=$(grep '^OPENCLAW_GATEWAY_TOKEN=' /opt/openclaw.env | cut -d= -f2-)
   sudo /opt/openclaw-cli.sh devices list --token="$TOKEN"

--

License

OpenClaw is open source software licensed under the MIT License.

Storage

Staff Picks