Deploying OpenClaw at Enterprise Scale

Deploying OpenClaw at enterprise scale means running it reliably for multiple users, locking down access controls, managing skills centrally, and integrating with your existing security stack. OpenClaw's local-first architecture is a strength here — there's no SaaS vendor controlling your data — but it also means you're responsible for the infrastructure. This guide walks through a production-ready deployment.

Architecture Overview#

At enterprise scale, you're typically looking at one of two patterns:

Pattern A: Central server, browser-based access. A single VPS or on-prem server runs the OpenClaw gateway. Users access it through the web UI at localhost:3100 (proxied behind your auth layer). All data lives on that server.

Pattern B: Per-user installs, shared skills. Each team member runs their own DenchClaw instance on their workstation. Skills and configurations are managed via a shared Git repository that all instances pull from.

Pattern A is simpler to govern. Pattern B gives each user full data isolation. Most enterprise teams start with Pattern A and migrate to Pattern B if data isolation becomes a hard requirement.

Step 1: Provision the Server#

For Pattern A, you'll want a dedicated server with:

• CPU: 4+ cores (agent tasks are CPU-intensive)
• RAM: 8GB minimum, 16GB recommended (DuckDB + model inference)
• Storage: 100GB+ SSD (audit logs and DuckDB grow over time)
• OS: Ubuntu 22.04 LTS or Debian 12

Install the prerequisites:

# Node.js 22+
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt-get install -y nodejs
 
# Install DenchClaw
npx denchclaw
 
# Verify gateway starts
openclaw gateway status

Step 2: Configure the Gateway for Production#

The OpenClaw gateway runs on port 19001 by default. For production, you want it behind a reverse proxy with TLS.

Nginx configuration#

server {
    listen 443 ssl;
    server_name openclaw.yourcompany.com;
 
    ssl_certificate /etc/letsencrypt/live/openclaw.yourcompany.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openclaw.yourcompany.com/privkey.pem;
 
    location / {
        proxy_pass http://localhost:19001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_cache_bypass $http_upgrade;
    }
 
    location /frontend {
        proxy_pass http://localhost:3100;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
    }
}

Run as a systemd service#

Don't run the gateway in a screen session. Use systemd:

# /etc/systemd/system/openclaw.service
[Unit]
Description=OpenClaw Gateway
After=network.target
 
[Service]
Type=simple
User=openclaw
WorkingDirectory=/home/openclaw
ExecStart=/usr/bin/npx openclaw gateway start
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal
Environment=NODE_ENV=production
 
[Install]
WantedBy=multi-user.target

sudo systemctl enable openclaw
sudo systemctl start openclaw
sudo systemctl status openclaw

Step 3: Access Controls#

OpenClaw doesn't ship with a built-in multi-user auth system (the local-first model assumes a single owner by default). For enterprise deployments, layer auth in front of the gateway.

Option A: OAuth2 Proxy#

Put the gateway behind an OAuth2 proxy that authenticates against your identity provider (Okta, Google Workspace, Azure AD):

# Install oauth2-proxy
wget https://github.com/oauth2-proxy/oauth2-proxy/releases/download/v7.6.0/oauth2-proxy-v7.6.0.linux-amd64.tar.gz
tar xvf oauth2-proxy-*.tar.gz
 
# Configure for Google OAuth
./oauth2-proxy \
  --provider=google \
  --email-domain=yourcompany.com \
  --upstream=http://localhost:19001 \
  --cookie-secret=$(openssl rand -base64 32) \
  --client-id=YOUR_CLIENT_ID \
  --client-secret=YOUR_CLIENT_SECRET

Option B: Tailscale#

For teams already on Tailscale, this is the simplest option. The gateway only listens on the Tailscale interface:

# Bind gateway to Tailscale IP only
OPENCLAW_BIND_HOST=$(tailscale ip -4) openclaw gateway start

Team members access it via http://100.x.x.x:19001. No public exposure, no TLS setup, no extra auth layer. Tailscale handles identity.

Option C: VPN + Firewall#

If you run a corporate VPN, firewall the gateway to only allow connections from the VPN subnet:

sudo ufw allow from 10.0.0.0/8 to any port 19001
sudo ufw deny 19001

Step 4: Skills Governance#

Skills are markdown files that tell the agent how to use specific tools. In an enterprise context, you want centralized control over which skills are deployed.

Centralized skill repository#

Create a Git repo for your skills:

enterprise-openclaw-skills/
├── crm/
│   └── SKILL.md
├── jira-integration/
│   └── SKILL.md
├── salesforce-sync/
│   └── SKILL.md
└── approved-skills.json

Have all instances pull from this repo on startup:

# In your startup script
git -C ~/.openclaw-dench/workspace/skills pull origin main

Skill approval workflow#

Before adding a new skill to the repo, require a review. Skills can instruct the agent to call external APIs, write files, or send messages — so they're effectively code. Treat them that way in your review process.

An approved-skills.json manifest makes it easy to audit what's deployed:

{
  "approved": ["crm", "jira-integration", "salesforce-sync"],
  "pending_review": ["slack-integration"],
  "rejected": ["arbitrary-exec"]
}

Step 5: Environment and Secrets Management#

Never put API keys or credentials directly in skill files or agent prompts. Use environment variables:

# /etc/openclaw/env.conf (mode 600, owned by openclaw user)
OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...
JIRA_API_TOKEN=...

Reference these in skill files as $ENV_VAR_NAME. The agent runtime resolves them at execution time without ever logging the values.

For secrets at scale, integrate with your existing secrets manager:

# Pull secrets from AWS Secrets Manager at startup
aws secretsmanager get-secret-value \
  --secret-id openclaw/production \
  --query SecretString \
  --output text | jq -r 'to_entries[] | "\(.key)=\(.value)"' \
  > /etc/openclaw/env.conf

Step 6: Audit Logging at Scale#

See OpenClaw Audit Logs for the full logging guide. At enterprise scale, add:

Centralized log aggregation#

# Ship JSONL logs to your ELK stack
filebeat -e -c /etc/filebeat/openclaw-filebeat.yml

Sample Filebeat config:

filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /home/openclaw/.openclaw-dench/workspace/.openclaw/logs/*.jsonl
    json.keys_under_root: true
    json.add_error_key: true
 
output.elasticsearch:
  hosts: ["https://elasticsearch.yourcompany.com:9200"]
  index: "openclaw-audit-%{+yyyy.MM.dd}"

Alerting on sensitive actions#

Set up alerts when the agent performs external writes (emails sent, webhooks fired, records updated):

# Simple Slack alert on external actions
tail -F *.jsonl | jq -c 'select(.external == true)' | while read line; do
  curl -X POST $SLACK_WEBHOOK_URL \
    -H 'Content-type: application/json' \
    -d "{\"text\": \"AI agent external action: $(echo $line | jq -r .tool)\"}"
done

Step 7: Backup and Disaster Recovery#

DenchClaw's entire state is in two places:

1. ~/.openclaw-dench/workspace/ — skills, configs, documents
2. ~/.openclaw-dench/workspace/workspace.duckdb — the CRM database

Back both up daily:

#!/bin/bash
# /etc/cron.daily/openclaw-backup
BACKUP_DATE=$(date +%Y-%m-%d)
BACKUP_DIR=/backups/openclaw
 
# Backup workspace
tar czf $BACKUP_DIR/workspace-$BACKUP_DATE.tar.gz \
  ~/.openclaw-dench/workspace/ \
  --exclude='.openclaw/logs'
 
# Backup DuckDB
cp ~/.openclaw-dench/workspace/workspace.duckdb \
  $BACKUP_DIR/workspace-$BACKUP_DATE.duckdb
 
# Upload to S3
aws s3 sync $BACKUP_DIR s3://your-backup-bucket/openclaw/
 
# Retain 30 days
find $BACKUP_DIR -mtime +30 -delete

Step 8: Monitoring and Health Checks#

Gateway health endpoint#

The gateway exposes a health endpoint at http://localhost:19001/health. Add it to your monitoring:

# Nagios/Icinga check
check_http -H localhost -p 19001 -u /health -e "OK"

Resource monitoring#

Agent sessions are CPU and memory intensive. Monitor:

# Add to Prometheus node exporter custom metrics
cat /proc/$(pgrep -f "openclaw gateway")/status | grep VmRSS

Set alerts if the gateway process exceeds 4GB RSS — that's usually a sign of a stuck session.

Common Enterprise Pitfalls#

Pitfall 1: Running the gateway as root. Don't. Create a dedicated openclaw system user with minimal permissions.

Pitfall 2: Forgetting log rotation. JSONL logs grow indefinitely. The default has no rotation. Set up logrotate on day one.

Pitfall 3: Shared API keys across teams. Give each team or department its own API key for external services. When something breaks, you'll know which team's workflow caused it.

Pitfall 4: No staging environment. Before deploying new skills to production, test them in a staging instance. Skills can call external APIs, so mistakes can have real effects.

Pitfall 5: Treating skills like config. Skills are instructions that execute code. Review them with the same rigor you'd apply to a shell script.

FAQ#

Q: Can multiple users share one DenchClaw instance simultaneously? A: The gateway is designed for single-user-at-a-time operation. For concurrent multi-user access, deploy separate instances per user or team, or use Pattern B (per-user installs with shared skills).

Q: Does DenchClaw support SSO? A: Not natively — SSO is handled at the infrastructure layer via an OAuth2 proxy or VPN as described above.

Q: How do I push skill updates to all instances? A: Use a centralized Git repo for skills and have each instance pull on startup (or via a cron job). This is the standard approach for Pattern B deployments.

Q: What's the recommended database backup frequency? A: Daily for most teams. If your CRM data changes frequently, consider hourly backups of just the DuckDB file.

Q: Can I run DenchClaw on Kubernetes? A: Yes, but it requires mounting the workspace directory as a persistent volume. The agent process is stateful — it needs the workspace to persist between pod restarts. A StatefulSet with a PVC is the right pattern.

For the full picture on what DenchClaw is and how to get started, check those links first if you're new to the platform.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →