DEV Community: Kenneth Phang

Should You Run Your AI Assistant Inside Docker? I Researched It So You Do Not Have To

Kenneth Phang — Thu, 05 Mar 2026 04:47:56 +0000

I run OpenClaw — an open-source AI assistant that connects to WhatsApp, Telegram, and Discord with full system access (shell, files, browser, voice). It currently runs directly on the host with Docker sandbox containers for tool isolation.

I spent a week researching whether to move the entire gateway into Docker. Here is what I found — and why I decided not to.

The Three Options

Option A: Host-Based (Current)

Gateway runs on the host as a systemd service. Sandbox containers handle tool execution.

┌──────────────────────────────────────┐
│              HOST                     │
│  ┌────────────────────────────────┐  │
│  │  OpenClaw Gateway (systemd)   │  │
│  │  - WhatsApp connection        │  │
│  │  - Telegram bot               │  │
│  │  - API keys in ~/.openclaw    │  │
│  └──────────┬─────────────────────┘  │
│             │ Docker socket          │
│             ▼                        │
│  ┌────────────────────────────────┐  │
│  │  Sandbox Containers           │  │
│  │  - Tool execution only        │  │
│  │  - Filesystem isolation       │  │
│  └────────────────────────────────┘  │
└──────────────────────────────────────┘

Option B: Full Docker

Everything in Docker — gateway, tools, sandbox.

Option C: Hybrid

Gateway in Docker, sandbox as sibling containers via Docker socket.

Option C sounded like the sweet spot. It is not. Here is why.

The Docker Socket Paradox

This is the core problem that killed Option C for me.

OpenClaw needs to spawn Docker containers for sandboxed tool execution. If the gateway is inside Docker, it needs access to the Docker daemon. The standard approach: mount /var/run/docker.sock.

But mounting the Docker socket gives the container root-equivalent access to the entire host.

An attacker (or a rogue AI prompt injection) could:

Create a privileged container mounting / (host root filesystem)
Read /etc/shadow, SSH keys, every API key on the server
Spawn cryptomining containers
Delete all containers, volumes, and images

Even a read-only mount does not help — the Docker API is still fully writable through the socket.

Goal:     Isolate gateway from host for security
Requires: Docker socket to spawn sandbox containers
Result:   Docker socket gives root access to host
Net:      Security improvement = 0

You containerize for security, then hand back all the access via the socket. It is like locking your front door but leaving the key under the mat.

Mitigations Exist But Add Complexity

Docker socket proxy restricts which API endpoints are accessible. But it adds another container to manage, must be carefully configured, and still allows container creation (which is the attack vector).

Sysbox runtime allows nested containers without socket mount or privileged mode. But it requires host-level installation and is not widely supported.

Podman is daemonless and rootless. But OpenClaw sandbox currently assumes Docker.

WhatsApp Pairing Breaks in Docker

OpenClaw uses the Baileys library (WhatsApp Web protocol). Pairing requires a QR code scan from your phone. Inside Docker:

Session data must be volume-mounted. If the volume mapping breaks on restart, you re-pair.
Docker NAT layer adds latency to WebSocket connections.
I already see frequent gateway disconnects (HTTP 499, 428, 503) on the host. Docker networking would make this worse.
Container restart without proper volume persistence = lost WhatsApp session = manual re-pair.

Workarounds exist (noVNC for QR display, phone number OTP pairing) but they add fragility to something that currently just works.

Networking Gets Complicated Fast

The gateway needs outbound access to:

WhatsApp servers (WebSocket)
Telegram API
Anthropic, OpenAI, Google APIs
npm registry

Plus:

Health check endpoint on port 18789
Inter-container communication with sandbox containers
DNS resolution (flaky inside Docker)
Tailscale VPN needs --cap-add NET_ADMIN and /dev/net/tun

Every layer of Docker networking adds 1-2ms latency and a potential failure point.

Persistent State is a Minefield

Everything in ~/.openclaw/ needs volume mounts:

volumes:
  - ./config:/home/openclaw/.openclaw
  - ./workspace:/home/openclaw/.openclaw/workspace
  - ./media:/home/openclaw/.openclaw/media
  - /var/run/docker.sock:/var/run/docker.sock

Risks:

UID/GID mismatches between host user and container user
Volume corruption if the container crashes mid-write
Backup complexity increases (Docker volumes vs simple tar)
File ownership conflicts when accessing workspace from both host and container
Media files (voice messages, images) need careful permission handling

Debugging Gets Painful

Task	Host	Docker
View logs	`journalctl --user -u openclaw-gateway`	`docker logs openclaw-gateway`
Restart	`systemctl --user restart openclaw-gateway`	`docker restart openclaw-gateway`
Shell	Direct SSH	`docker exec -it openclaw-gateway bash`
Edit config	`vim ~/.openclaw/openclaw.json`	Edit volume or exec in
Install plugin	`openclaw plugins install ...`	Exec in + restart container

You lose systemd watchdog, journald integration, and the ability to just SSH in and fix things.

The Sandbox-in-Sandbox Problem

OpenClaw spawns Docker containers for tool isolation. If the gateway is also in Docker:

Docker-in-Docker (DinD): Needs --privileged flag, which defeats all security benefits. Storage driver conflicts (overlay2 inside overlay2). Known stability issues.
Sibling containers via socket: Returns to the Docker socket paradox (root access).
Sysbox: True nested containers without privilege escalation. But limited platform support and not tested with OpenClaw.

Performance Overhead (Minor But Real)

Container startup: ~1-3s overhead per sandbox spawn
Network NAT: ~1-2ms per request
Memory: ~50-100MB for container runtime
Disk I/O through overlay2: 5-15% slower for writes
TTS audio processing and browser screenshots slightly slower

It Would Require a Major Rewrite

I built clawmacdo — a Rust CLI that deploys OpenClaw to DigitalOcean and Tencent Cloud via 16 SSH-based provisioning steps. Moving to Docker means:

Replace Steps 9-15 with docker compose up
Build and publish a gateway Docker image
Rewrite backup/restore for Docker volumes
Change Web UI progress streaming from SSH to Docker log tailing
Re-test the Tencent Cloud integration I just finished

Estimated effort: 2-3 weeks. For questionable security improvement.

The Scorecard

Issue	Severity	Mitigatable?
Docker socket = root access	CRITICAL	Partial (proxy)
WhatsApp pairing breaks	HIGH	Yes (fragile)
Sandbox-in-sandbox	HIGH	Partial
clawmacdo rewrite	HIGH (effort)	Yes but expensive
Networking complexity	MEDIUM-HIGH	Yes
State management	MEDIUM	Yes (volumes)
Debugging harder	MEDIUM	Yes (tooling)
Performance overhead	LOW	Negligible

My Decision: Stay on Host

Short-term: Keep the host-based architecture. Harden with allowlists, workspace-only file access, and group policies. This provides better security ROI than containerization.

Medium-term: Watch for OpenClaw Podman support (rootless sandboxing) and Sysbox maturity.

Long-term: Revisit when rootless container runtimes are natively supported and WhatsApp Business API replaces QR-based pairing.

The right answer is not always the most technically sophisticated one. Sometimes keeping it simple is the engineering decision.

Full Research Doc

The complete analysis with architecture diagrams is on GitHub:

DEPLOYMENT_ARCHITECTURE_RESEARCH.md

And the CLI itself:

github.com/kenken64/clawmacdo — star it if you found this useful!

The best deployment architecture is the one where adding Docker does not accidentally give root access to the thing you are trying to isolate. 🦞🔒

How I Added Multi-Cloud Support to My Rust CLI — DigitalOcean + Tencent Cloud in One Tool

Kenneth Phang — Thu, 05 Mar 2026 04:37:06 +0000

My open-source Rust CLI, clawmacdo, originally only supported DigitalOcean. Last week, I added full Tencent Cloud support — and I want to share how I designed the multi-cloud architecture, implemented TC3-HMAC-SHA256 signing in Rust, and kept the provisioning pipeline provider-agnostic.

The Goal

One CLI that deploys an AI assistant stack to any cloud provider:

# DigitalOcean (existing)
clawmacdo deploy --provider=digitalocean --do-token=xxx

# Tencent Cloud (new!)
clawmacdo deploy --provider=tencent --tencent-secret-id=xxx --tencent-secret-key=xxx

Same 16-step automated deployment. Same result. Different cloud.

The Architecture: CloudProvider Trait

The key insight was that only the infrastructure layer changes per provider. The SSH provisioning pipeline (install Node.js, configure OpenClaw, start the gateway) is identical — it just needs an IP address to SSH into.

So I created a CloudProvider trait:

#[async_trait]
pub trait CloudProvider: Send + Sync {
    async fn upload_ssh_key(&self, name: &str, public_key: &str) -> Result<KeyInfo>;
    async fn delete_ssh_key(&self, key_id: &str) -> Result<()>;
    async fn create_instance(&self, params: CreateInstanceParams) -> Result<InstanceInfo>;
    async fn wait_for_active(&self, instance_id: &str, timeout: u64) -> Result<InstanceInfo>;
    async fn delete_instance(&self, instance_id: &str) -> Result<()>;
    async fn list_instances(&self, tag: &str) -> Result<Vec<InstanceInfo>>;
}

Both DoClient and TencentClient implement this trait. The deploy command just dispatches:

pub async fn run(params: DeployParams) -> Result<DeployRecord> {
    match resolve_provider(&params.provider)? {
        CloudProviderType::DigitalOcean => run_do(params).await,
        CloudProviderType::Tencent => run_tencent(params).await,
    }
}

Steps 1-4 are provider-specific (create keys, create instance). Steps 5-16 are shared (SSH in, provision, start gateway). Clean separation.

Implementing TC3-HMAC-SHA256 in Rust

Tencent Cloud uses a custom request signing scheme called TC3-HMAC-SHA256. Every API request must be signed with a 4-layer HMAC chain. Here is how it works:

Date Key:    HMAC-SHA256("TC3" + SecretKey, date)
Service Key: HMAC-SHA256(dateKey, service)
Signing Key: HMAC-SHA256(serviceKey, "tc3_request")
Signature:   HMAC-SHA256(signingKey, stringToSign)

In Rust, using the hmac and sha2 crates:

use hmac::{Hmac, Mac};
use sha2::{Digest, Sha256};

type HmacSha256 = Hmac<Sha256>;

fn hmac_sha256(key: &[u8], data: &[u8]) -> Vec<u8> {
    let mut mac = HmacSha256::new_from_slice(key).expect("key");
    mac.update(data);
    mac.finalize().into_bytes().to_vec()
}

// Build the 4-layer signing key
let secret_date = hmac_sha256(
    format!("TC3{}", secret_key).as_bytes(),
    date.as_bytes(),
);
let secret_service = hmac_sha256(&secret_date, service.as_bytes());
let secret_signing = hmac_sha256(&secret_service, b"tc3_request");
let signature = hex::encode(
    hmac_sha256(&secret_signing, string_to_sign.as_bytes())
);

The Authorization header then looks like:

TC3-HMAC-SHA256 Credential=AKIDxxx/2026-03-05/cvm/tc3_request,
SignedHeaders=content-type;host, Signature=abc123...

This was the trickiest part — getting the canonical request format exactly right. One extra newline or wrong header order and the signature fails silently.

Tencent Cloud API Surface

I implemented these Tencent Cloud APIs:

CVM (Cloud Virtual Machine):

RunInstances — Create instances with cloud-init, SSH keys, tags
DescribeInstances — Poll status, get public IP, list by tag
TerminateInstances — Destroy instances

KeyPair:

ImportKeyPair — Upload SSH public key
DeleteKeyPairs — Cleanup
DescribeKeyPairs — List for destroy cleanup

VPC (Security Groups):

CreateSecurityGroup — Firewall rules
CreateSecurityGroupPolicies — SSH (22) + HTTP (80) + HTTPS (443) ingress
DeleteSecurityGroup — Cleanup on destroy

Resource Mapping

Here is how DigitalOcean and Tencent Cloud concepts map:

Concept	DigitalOcean	Tencent Cloud
Compute	Droplet	CVM Instance
Auth	Bearer token	TC3-HMAC-SHA256
Region	sgp1	ap-singapore
Size	s-2vcpu-4gb	S5.MEDIUM4
SSH Keys	Account SSH Keys	KeyPair API
Firewall	Cloud Firewall	Security Groups (VPC)
Tags	Droplet tags	Instance tags
User data	cloud-init	cloud-init (base64)
Image	ubuntu-24-04-x64	img-487zeit5

One gotcha: Tencent Cloud requires user data to be base64-encoded, while DigitalOcean accepts it as plain text. Small difference, easy to miss.

Web UI: Dynamic Provider Switching

The web UI (built with Axum + SSE) now has a provider dropdown that dynamically swaps:

Credential fields — DO Token vs Tencent SecretId/SecretKey
Region options — sgp1/nyc1/lon1 vs ap-singapore/ap-hongkong/ap-tokyo
Instance sizes — s-2vcpu-4gb vs S5.MEDIUM4

All powered by a single toggleProvider() JavaScript function that rewrites the form fields on change. The SSE progress streaming works identically for both providers.

CLI Changes

Every command now accepts --provider:

# Deploy
clawmacdo deploy --provider=tencent \\
  --tencent-secret-id=AKIDxxx \\
  --tencent-secret-key=xxx \\
  --anthropic-key=sk-ant-xxx

# Status
clawmacdo status --provider=tencent \\
  --tencent-secret-id=AKIDxxx \\
  --tencent-secret-key=xxx

# Destroy
clawmacdo destroy --provider=tencent \\
  --tencent-secret-id=AKIDxxx \\
  --tencent-secret-key=xxx \\
  --name=openclaw-abc12345

# Migrate (cross-cloud supported!)
clawmacdo migrate --provider=tencent \\
  --source-ip=1.2.3.4 \\
  --source-key=~/.ssh/id_ed25519 \\
  --tencent-secret-id=AKIDxxx \\
  --tencent-secret-key=xxx

Backward compatible — --provider defaults to digitalocean.

What I Learned

Trait-based abstraction pays off. Adding a new provider was mostly about implementing the trait — the deploy pipeline barely changed.
TC3 signing is fiddly. The canonical request must have headers in exact alphabetical order, with exact newlines. Debug by comparing your canonical request string byte-by-byte with Tencent is documentation examples.
Security groups are mandatory on Tencent. Unlike DO where droplets are accessible by default, Tencent blocks all inbound traffic unless you create a security group. Forgetting this means SSH will time out and you will have no idea why.
Base64 user data. Tencent requires base64-encoded cloud-init. DO takes raw text. Easy to miss, hard to debug (cloud-init silently fails).
The provisioning pipeline is the real value. 80% of the deploy work (install Node, configure OpenClaw, set up systemd, start gateway) happens over SSH and is completely provider-agnostic. The cloud API is just the bootstrap.

What is Next

AWS support — EC2 + SigV4 signing (same trait pattern)
Hetzner Cloud — Popular in Europe, simple API
Live testing on Tencent — Waiting for account approval
Docker-based deployment option — Research complete, staying host-based for now

Try It

The tencent branch is live:

git clone https://github.com/kenken64/clawmacdo.git
cd clawmacdo
git checkout tencent
cargo build --release

Or grab a binary from Releases (main branch, tencent coming soon).

Star the repo if this is useful: github.com/kenken64/clawmacdo

The best multi-cloud tool is the one where adding a new provider is just implementing a trait. 🦞🦀

I Reverse-Engineered My Own Rust CLI — Here is the Full Architecture of a 16-Step Cloud Deployer

Kenneth Phang — Wed, 04 Mar 2026 07:35:09 +0000

Most deployment tools are black boxes. You run a command, cross your fingers, and hope it works.

I wanted something different. I built clawmacdo — a Rust CLI that deploys a full AI assistant stack to DigitalOcean in one command. And today, I am going to crack it open and show you exactly how it works inside.

This is the full architecture, data flow, and design decisions behind a real-world Rust CLI that provisions cloud servers, SSHs into them, installs software, and streams live progress to a web UI.

The 30-Second Pitch

One command:

clawmacdo deploy --do-token=xxx --anthropic-key=xxx

16 automated steps later, you have a fully configured AI assistant running on a DigitalOcean droplet with WhatsApp, Telegram, Claude, GPT, and Gemini — all wired up and ready to go.

But HOW does it actually work?

The Architecture: 5 Layers

┌─────────────────────────────────────────┐
│  Layer 1: CLI + Web UI Orchestration    │
│  (Clap CLI + Axum web server + SSE)     │
├─────────────────────────────────────────┤
│  Layer 2: Infrastructure APIs           │
│  (DigitalOcean REST + SSH/SCP)          │
├─────────────────────────────────────────┤
│  Layer 3: Provisioning Pipeline         │
│  (6 ordered modules, each idempotent)   │
├─────────────────────────────────────────┤
│  Layer 4: Config + State Persistence    │
│  (DeployRecord JSON + .env + systemd)   │
├─────────────────────────────────────────┤
│  Layer 5: Progress + Error Surfaces     │
│  (Terminal UI + SSE streaming + typed    │
│   errors with actionable diagnostics)   │
└─────────────────────────────────────────┘

Let me walk through each one.

Layer 1: Dual Interface — CLI and Web UI

clawmacdo works two ways:

CLI mode — for terminal lovers:

clawmacdo deploy --do-token=xxx
clawmacdo backup
clawmacdo status
clawmacdo destroy --name=my-droplet
clawmacdo migrate --source-ip=1.2.3.4

Web UI mode — for everyone else:

clawmacdo serve

This spins up an Axum web server with a full UI. You fill in a form, hit deploy, and watch real-time progress via Server-Sent Events (SSE).

Browser ──POST /api/deploy──▶ Axum
Browser ──GET /api/deploy/{id}/events──▶ SSE stream
                                         │
                              tokio::spawn(deploy task)
                                         │
                              SSH into droplet ──▶ provision
                                         │
                              emit progress events ──▶ Browser

The web deploy runs in a tokio background task with a progress channel. The SSE endpoint reads from that channel and streams events to the browser in real-time. Terminal markers (DEPLOY_COMPLETE / DEPLOY_ERROR) signal the end state.

This pattern — async task + channel + SSE — is surprisingly clean in Rust with tokio + Axum.

Layer 2: Infrastructure as Code (Without the YAML)

No Terraform. No Pulumi. No CloudFormation. Just direct API calls.

DoClient wraps the DigitalOcean REST API via reqwest:

Create/delete droplets
Manage SSH keys
Poll for droplet status
Tag-based resource tracking

SSH utilities use ssh2 (libssh2 bindings):

Key generation (Ed25519)
Remote command execution
SCP file transfers
Readiness polling (wait for cloud-init + SSH)

Why no Terraform? Because clawmacdo needs to react to each step. It is not declaring desired state — it is orchestrating a sequence where each step depends on the previous one. SSH readiness polling, cloud-init sentinel files, health checks — these are imperative, not declarative.

Layer 3: The Provisioning Pipeline (The Heart)

This is where the magic happens. Six ordered modules, each handling one concern:

1. User Provisioning

Creates a dedicated openclaw system user
Sets up shell environment and sudo scope
Enables systemd lingering (so user services survive logout)
Migrates restored backup from root to the openclaw user

2. Firewall Hardening

Configures fail2ban for brute-force protection
Sets up unattended-upgrades for automatic security patches
Hardens UFW rules
Adds DOCKER-USER iptables isolation rules

3. Docker Setup

Writes optimized /etc/docker/daemon.json
Adds openclaw user to docker group
Restarts Docker daemon

4. Node.js + AI CLIs

Configures pnpm global directories
Installs Claude Code (Anthropic), Codex (OpenAI), Gemini CLI (Google)
Verifies and symlinks all binaries

5. OpenClaw Installation

Creates .openclaw directory structure
Writes .env with all API keys and messaging config
Installs OpenClaw globally via npm
Normalizes extension hardlinks

6. Tailscale (Optional)

Installs Tailscale for private networking
Runs tailscale up with auth key if provided

Each module is idempotent — you can re-run provisioning without breaking things. This matters when debugging partial failures.

Layer 4: State That Actually Makes Sense

Three locations, three purposes:

Local machine (~/.clawmacdo/):

~/.clawmacdo/
├── backups/     # Timestamped .tar.gz archives
├── keys/        # Generated SSH private keys
└── deploys/     # DeployRecord JSON files

DeployRecord captures everything about a deployment:

{
  "id": "abc123",
  "droplet_id": 555085163,
  "hostname": "openclaw-b0c825bf",
  "ip_address": "178.128.222.239",
  "region": "sgp1",
  "size": "s-2vcpu-4gb",
  "ssh_key_path": "~/.clawmacdo/keys/abc123",
  "backup_restored": true,
  "timestamp": "2026-03-01T10:00:00Z"
}

Remote droplet:

.env — runtime secrets
openclaw.json — channel/model/plugin config
systemd user service — gateway lifecycle

Layer 5: Errors That Help You Fix Things

This is where most deployment tools fail. Something breaks and you get Error: deployment failed.

clawmacdo takes a different approach:

Typed errors via a custom error enum — every failure mode has a specific type
No auto-destroy on failure — if step 12 fails, your droplet survives. You get SSH debug info so you can fix it manually
SSH/cloud-init timeouts include diagnostic output — not just "timed out" but actual logs
Gateway validation checks both systemd state AND the /health endpoint
Web UI streams progress incrementally — you see exactly which step failed

This is a deliberate design choice: a half-deployed server you can debug is better than a destroyed server you cannot.

The Full 16-Step Deploy Flow

1.  Resolve params + defaults
2.  Generate SSH keypair locally
3.  Upload public key to DigitalOcean
4.  Create droplet with cloud-init
5.  Poll until droplet is active
6.  Wait for SSH + cloud-init sentinel
7.  SCP backup to droplet (if selected)
8.  Restore backup on droplet
9.  Create openclaw user + permissions
10. Harden firewall (UFW + fail2ban)
11. Configure Docker
12. Install Node.js + AI CLIs
13. Install + configure OpenClaw
14. Optional: Tailscale setup
15. Start gateway + health check
16. Configure model failover + save DeployRecord

Each step reports progress. Each step can fail gracefully. Each step builds on the last.

Bonus: Post-Deploy Lifecycle

Deployment is not the end. clawmacdo also handles:

whatsapp-repair — fixes WhatsApp channel issues post-deploy (updates OpenClaw, normalizes config, restarts gateway, probes login capability)
migrate — SSHs into an existing droplet, backs up remotely, deploys a new one, restores
destroy — cleans up everything (droplet + SSH keys on DO + local keys)
status — lists all your openclaw-tagged droplets

What I Learned Building This

Rust + tokio + Axum is a killer stack for CLI-with-web-UI tools. The type system catches so many deployment bugs at compile time.
SSH operations are messy. Cloud-init takes variable time, SSH daemons need polling, and libssh2 has quirks. Build robust retry/wait logic.
Never auto-destroy on failure. Leave the server running so people can debug. Print SSH commands they can copy-paste.
Stream progress, do not batch it. Whether terminal or web, people want to see what is happening NOW.
Idempotent provisioning modules save your sanity. When step 11 fails, you want to re-run from step 11, not step 1.

Try It Yourself

The entire codebase is open source:

github.com/kenken64/clawmacdo

Download a pre-built binary from Releases — available for Windows, Linux, and macOS (Apple Silicon).

If this kind of systems architecture content interests you, drop a star on the repo and follow for more deep dives.

The best deployment tool is not the one with the most features — it is the one that tells you exactly what went wrong when things break. 🦞🦀

Watch: Deploying an AI Assistant to DigitalOcean in 16 Steps with clawmacdo

Kenneth Phang — Wed, 04 Mar 2026 05:08:46 +0000

I recently recorded a quick demo showing how clawmacdo deploys a full AI assistant stack to DigitalOcean — from zero to a running WhatsApp/Telegram bot in minutes.

🎬 Watch the demo on YouTube

What You Just Saw

The entire deployment flow, start to finish:

Step 1: Enter Your Credentials

You provide your API keys once:

DigitalOcean personal access token (to provision the droplet)
Anthropic API key (Claude as your primary AI model)
OpenAI API key (GPT as failover)
Gemini API key (Google as second failover)

clawmacdo deploy \
  --do-token=dop_v1_xxx \
  --anthropic-key=sk-ant-xxx \
  --openai-key=sk-xxx \
  --gemini-key=AIzaSy...

Step 2: Configure Server Settings

Pick your region, droplet size, and messaging channels. clawmacdo handles the rest.

Step 3: Automated 16-Step Deployment

Once you hit deploy, clawmacdo runs through 16 automated steps:

Generate SSH keypair
Upload public key to DigitalOcean
Create Ubuntu 24.04 droplet
Wait for droplet to boot
SSH into the droplet
Install Node.js 24
Install OpenClaw globally
Install Claude Code (Anthropic coding agent)
Install Codex (OpenAI coding agent)
Install Gemini CLI (Google coding agent)
Configure .env with all API keys
Set up OpenClaw config (openclaw.json)
Configure model failover chain (Anthropic to OpenAI to Google)
Set up systemd service
Start the OpenClaw gateway
Verify everything is running

All of this happens automatically. No SSH-ing in manually. No copy-pasting configs. No debugging cloud-init scripts.

Step 4: Post-Deploy Setup

Once the deployment finishes, you get:

Connection details — IP address, SSH command
Telegram pairing — Connect your Telegram bot instantly
Docker fixes — Automatic container optimization if needed
WhatsApp QR code — Scan with your phone to link WhatsApp

The demo ends with a QR code appearing — scan it, and your AI assistant is live on WhatsApp. That fast.

Why This Matters

Setting up an AI assistant manually takes 30+ minutes of tedious work:

Provisioning servers
Installing dependencies
Configuring API keys
Setting up messaging channels
Debugging what went wrong

With clawmacdo, it takes one command. And because it is written in Rust, it is a single binary with zero runtime dependencies.

What is OpenClaw?

OpenClaw is an open-source AI assistant platform. Think of it as your personal Jarvis:

Multi-channel — WhatsApp, Telegram, Discord, Slack, Signal, iMessage
Multi-model — Claude, GPT, Gemini with automatic failover
Full access — Browser control, voice calls, file management, shell access, smart home
Self-hosted — Your data stays on your server

Get Started

Download clawmacdo from the Releases page
Get a DigitalOcean API token
Get API keys from Anthropic, OpenAI, and/or Google
Run clawmacdo deploy and watch the magic happen

I Built a Rust CLI to Deploy AI Assistants to DigitalOcean in One Command

Kenneth Phang — Tue, 03 Mar 2026 11:50:50 +0000

The Problem

If you use OpenClaw — the open-source AI assistant framework that connects Claude, GPT, and Gemini to WhatsApp, Telegram, Discord, and more — you know the pain of deploying it to a cloud server.

You need to:

Provision a VPS
Install Node.js, OpenClaw, coding agents (Claude Code, Codex, Gemini CLI)
Copy over your config, API keys, and messaging credentials
Configure model failover
Start the gateway
And if you want to migrate between servers? Do it all again.

I got tired of doing this manually, so I built clawmacdo — a Rust CLI that handles the entire lifecycle in one command.

What is clawmacdo?

clawmacdo is a Rust CLI tool for deploying and migrating OpenClaw instances on DigitalOcean.

Features at a Glance

Command	What it does
`backup`	Archives your `~/.openclaw/` config into a timestamped `.tar.gz`
`deploy`	1-click deploy: provisions DO droplet, installs everything, restores config
`migrate`	DO-to-DO migration: backup source → deploy new → restore
`destroy`	Tears down a droplet + cleans up SSH keys
`status`	Lists all your OpenClaw-tagged droplets with IPs
`list-backups`	Shows local backup archives

One-Click Deploy

Here is the magic. One command to go from zero to a fully running AI assistant in the cloud:

clawmacdo deploy \\
  --do-token=dop_v1_xxx \\
  --anthropic-key=sk-ant-xxx \\
  --openai-key=sk-xxx \\
  --gemini-key=AIzaSy... \\
  --whatsapp-phone-number=15551234567 \\
  --telegram-bot-token=123456789:AA...

This single command:

Generates SSH keys for secure access
Provisions a DigitalOcean droplet (Ubuntu 24.04, Singapore region)
Installs Node 24 + OpenClaw via cloud-init
Installs Claude Code, Codex, and Gemini CLI as coding agents
Restores your config from a local backup
Configures .env with all your API keys and messaging tokens
Starts the gateway and sets up model failover (Anthropic → OpenAI → Google)
Verifies everything is running and gives you the IP

The whole process takes about 3-5 minutes.

Server-to-Server Migration

Need to move your assistant to a bigger droplet? Or just want a fresh start?

clawmacdo migrate \\
  --source-ip=164.90.xxx.xxx \\
  --do-token=dop_v1_xxx

This SSHs into your source droplet, backs up the config remotely, deploys a fresh droplet, and restores everything. Zero downtime migration.

Why Rust?

Single binary — no runtime dependencies, no node_modules, no Python virtualenvs
Cross-platform — pre-built binaries for Windows, Linux, and macOS (Apple Silicon)
Fast — startup is instant, SSH operations use native libssh2
Reliable — strong typing catches config errors at compile time

Quick Start

Install from release binary

Download the latest binary for your platform from Releases:

Platform	File
Windows x86_64	`clawmacdo-windows-amd64.zip`
Linux x86_64	`clawmacdo-linux-amd64.tar.gz`
macOS Apple Silicon	`clawmacdo-darwin-arm64.tar.gz`

Build from source

git clone https://github.com/kenken64/clawmacdo.git
cd clawmacdo
cargo build --release

Check your deployed instances

clawmacdo status --do-token=dop_v1_xxx

The Bigger Picture: OpenClaw

If you have not heard of OpenClaw, it is an open-source framework that turns LLMs into personal AI assistants connected to your real communication channels:

WhatsApp, Telegram, Discord, Slack, iMessage — your AI responds in your actual chats
Multi-model — Claude, GPT, Gemini with automatic failover
Tool use — file access, web browsing, code execution, voice calls
Skills system — extensible plugins for chess, weather, coding, and more
Self-hosted — your data stays on your server

clawmacdo makes deploying OpenClaw to the cloud as easy as deploying a static site.

Contributing

The project is open source and contributions are welcome! Whether it is:

Supporting other cloud providers (AWS, GCP, Hetzner)
Adding new deployment targets (Docker, Kubernetes)
Improving the migration workflow
Bug fixes and documentation

Check out the repo: github.com/kenken64/clawmacdo

⭐ If this is useful to you, a star on GitHub helps others discover it!

Built with 🦀 Rust and ❤️ for the OpenClaw community.