Back to Blog

How to Set Up OpenClaw for Business With Docker, Channels, and Security Hardening

February 13, 2026•11 min read•Team 400

The official OpenClaw getting-started guide will have you up and running in about ten minutes. That's genuinely impressive. It's also nowhere near ready for business use.

The gap between "it works on my laptop" and "it's safe to connect to our company Slack" is significant. You need proper container isolation, HTTPS termination, credential management, and a deployment that won't lose its state when you restart the server.

This guide covers that gap. We'll walk through a production-grade Docker deployment, connect messaging channels, and apply the security hardening that most tutorials leave out entirely.

Prerequisites

Before you start, make sure you have:

A server or VPS. Any Linux box with at least 2GB of RAM will do. Ubuntu 22.04 or later is the simplest path. A $12/month Hetzner or DigitalOcean droplet works fine for small teams. If you're running this on a corporate network behind a firewall, confirm that outbound HTTPS is allowed and that your IT team is across the deployment.

Docker and Docker Compose. Install Docker Engine (not Docker Desktop) on your server. You'll want Compose V2, which ships with recent Docker versions. Verify with:

docker --version
docker compose version

A domain name. You'll need this for HTTPS. Something like openclaw.yourcompany.com.au pointed at your server's IP. A DNS A record is all you need.

API keys for your LLM provider. OpenClaw doesn't include its own model. You'll need an API key from OpenAI, Anthropic, Google, or whichever provider you're using. Have this ready before you start.

A messaging platform with admin access. If you're connecting Slack, Teams, or WhatsApp, you'll need the ability to create bot accounts and configure webhooks. For most organisations, this means talking to your IT admin first.

Docker Deployment

The Base docker-compose Setup

Create a directory for your deployment:

mkdir -p /opt/openclaw && cd /opt/openclaw

Here's a starting docker-compose.yml. We'll harden it in later sections.

version: "3.8"

services:
  openclaw:
    image: openclaw/openclaw:latest
    container_name: openclaw
    restart: unless-stopped
    ports:
      - "127.0.0.1:3100:3100"
    volumes:
      - openclaw_data:/app/data
    env_file:
      - .env
    mem_limit: 1g
    pids_limit: 256

  openclaw-gateway:
    image: openclaw/gateway:latest
    container_name: openclaw-gateway
    restart: unless-stopped
    ports:
      - "127.0.0.1:3200:3200"
    env_file:
      - .env
    depends_on:
      - openclaw
    mem_limit: 512m
    pids_limit: 128

volumes:
  openclaw_data:

Bind to 127.0.0.1, Not 0.0.0.0

Notice the port binding: 127.0.0.1:3100:3100. This is critical.

The default in many guides is 3100:3100, which Docker interprets as 0.0.0.0:3100:3100. That exposes the port to every network interface on your server, including the public internet. Docker also bypasses ufw and iptables rules in most configurations, so your firewall won't save you.

Always bind to 127.0.0.1 and put a reverse proxy in front. We'll set that up shortly.

Volume Configuration

The named volume openclaw_data stores conversation history, configuration, and installed skills. Without it, you lose everything on container restart.

If you prefer bind mounts for easier backup:

volumes:
  - ./data:/app/data

Make sure the directory exists and has correct permissions:

mkdir -p ./data
chown -R 1000:1000 ./data

Back up this directory regularly. A simple cron job with rsync or rclone to an S3-compatible bucket is enough for most teams.

Environment Variables

Create a .env file in the same directory:

# LLM Provider
LLM_PROVIDER=anthropic
LLM_API_KEY=sk-ant-your-key-here

# OpenClaw Settings
OPENCLAW_SECRET=generate-a-random-64-char-string
OPENCLAW_URL=https://openclaw.yourcompany.com.au
GATEWAY_AUTH_TOKEN=another-random-string

# Admin
[email protected]

Generate proper random strings:

openssl rand -hex 32

Set file permissions so only root can read the env file:

chmod 600 .env

Bring it up:

docker compose up -d
docker compose logs -f

At this point, OpenClaw should be accessible on http://127.0.0.1:3100. Only from the server itself, which is exactly what we want.

Channel Configuration

How Channels Work

OpenClaw uses a gateway service to connect with messaging platforms. The gateway receives incoming messages from platforms like Slack or Teams, passes them to the OpenClaw core for processing, and sends responses back.

Each channel has its own authentication flow and webhook setup. The gateway handles the protocol differences so that OpenClaw's core doesn't need to know whether a message came from Slack, Teams, or WhatsApp.

You configure channels through the OpenClaw admin panel or via environment variables. We recommend environment variables for production since they're easier to version-control and reproduce.

Setting Up Slack

Slack is the most straightforward channel to configure. Here's the process:

1. Create a Slack App. Go to api.slack.com/apps and create a new app from scratch. Choose the workspace you want to connect.

2. Configure Bot Token Scopes. Under OAuth & Permissions, add these bot token scopes:

  • chat:write- send messages
  • app_mentions:read- respond when mentioned
  • im:history- read DM history
  • im:read- access DM channels
  • channels:history- read channel messages (if you want the bot in public channels)

3. Enable Event Subscriptions. Under Event Subscriptions, set the request URL to:

https://openclaw.yourcompany.com.au/gateway/slack/events

Subscribe to these bot events:

  • app_mention
  • message.im

4. Install to Workspace. Click "Install to Workspace" and copy the Bot User OAuth Token (starts with xoxb-).

5. Add to your .env:

SLACK_BOT_TOKEN=xoxb-your-token
SLACK_SIGNING_SECRET=your-signing-secret

Restart the gateway container and test by sending a DM to your bot.

Setting Up Microsoft Teams

Teams is more involved because of the Azure Bot Framework layer.

1. Register a Bot in Azure. Go to the Azure Portal and create a new Bot Channels Registration resource. You'll get an App ID and App Secret.

2. Configure the messaging endpoint:

https://openclaw.yourcompany.com.au/gateway/teams/messages

3. Enable the Teams channel in the Azure Bot configuration.

4. Add to your .env:

TEAMS_APP_ID=your-azure-app-id
TEAMS_APP_SECRET=your-azure-app-secret

5. Create a Teams app package with a manifest file and upload it to your organisation's Teams admin centre. Your Teams administrator will need to approve the app for distribution within the organisation.

Teams setup is fiddly. Budget an afternoon for it, especially if you don't have direct access to Azure AD and the Teams admin centre.

WhatsApp via the Business API

WhatsApp requires a Meta Business account and access to the WhatsApp Business API. This is the official API, not any unofficial libraries.

1. Set up a Meta Business Account and create a WhatsApp Business App in the Meta Developer portal.

2. Configure a webhook pointing to:

https://openclaw.yourcompany.com.au/gateway/whatsapp/webhook

3. Subscribe to the messages webhook field.

4. Add to your .env:

WHATSAPP_ACCESS_TOKEN=your-meta-access-token
WHATSAPP_PHONE_NUMBER_ID=your-phone-number-id
WHATSAPP_VERIFY_TOKEN=a-random-verification-string

WhatsApp has strict rate limits and template message requirements for outbound messaging. For business use, you'll likely need to go through Meta's business verification process, which can take a few weeks.

Other Channels

OpenClaw's gateway also supports:

  • Telegram- straightforward BotFather setup. Good for internal team bots.
  • Discord- similar to Slack in complexity. Works well for community-facing agents.
  • Signal- requires the Signal CLI bridge. More complex but offers strong privacy.
  • Google Chat- requires a Google Workspace account with API access.

You can run multiple channels simultaneously. The gateway routes messages from each platform to the same OpenClaw core, so your agent behaves consistently regardless of where users reach it.

Security Hardening

This is the section most guides skip, and it's the section that matters most for business use. If you want a deeper look at the risks, we've written a separate piece on OpenClaw security risks for business.

Reverse Proxy with HTTPS

Never expose OpenClaw directly to the internet. Put a reverse proxy in front.

Caddy is the simplest option because it handles TLS certificates automatically:

# Caddyfile
openclaw.yourcompany.com.au {
    reverse_proxy /gateway/* localhost:3200
    reverse_proxy /* localhost:3100
}

Install Caddy and start it:

sudo apt install -y caddy
sudo cp Caddyfile /etc/caddy/Caddyfile
sudo systemctl restart caddy

Caddy will automatically obtain and renew Let's Encrypt certificates.

If you prefer Nginx, you'll need to manage certificates yourself with certbot:

server {
    listen 443 ssl;
    server_name openclaw.yourcompany.com.au;

    ssl_certificate /etc/letsencrypt/live/openclaw.yourcompany.com.au/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/openclaw.yourcompany.com.au/privkey.pem;

    location /gateway/ {
        proxy_pass http://127.0.0.1:3200;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        proxy_pass http://127.0.0.1:3100;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Authentication Hardening

Change the default admin password immediately after first login. Use a strong, unique password or configure SSO if your OpenClaw edition supports it.

Restrict admin panel access to your office IP range using your reverse proxy:

location /admin {
    allow 203.0.113.0/24;  # Your office IP range
    deny all;
    proxy_pass http://127.0.0.1:3100;
}

If your team works remotely, put the admin panel behind a VPN or use an identity-aware proxy like Cloudflare Access or Tailscale.

Docker Sandbox Settings

The docker-compose.yml above already includes mem_limit and pids_limit. Here are additional hardening options:

services:
  openclaw:
    # ... existing config ...
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp:size=100M
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

These settings prevent privilege escalation, make the filesystem read-only (except for mounted volumes and tmpfs), and drop all Linux capabilities except the minimum needed.

Network Isolation for Sandboxed Tasks

If your OpenClaw agent runs code or interacts with external tools, isolate it from your internal network:

networks:
  openclaw_internal:
    driver: bridge
    internal: true
  openclaw_external:
    driver: bridge

services:
  openclaw:
    networks:
      - openclaw_internal
      - openclaw_external

  openclaw-sandbox:
    networks:
      - openclaw_internal
    # No access to openclaw_external

The sandbox container can talk to the OpenClaw core but has no route to the internet or your internal network. This limits the damage if an agent skill behaves unexpectedly or maliciously.

Credential Rotation

Set a calendar reminder to rotate your keys quarterly:

  • LLM API keys
  • OPENCLAW_SECRET
  • GATEWAY_AUTH_TOKEN
  • Channel-specific tokens (Slack bot token, Teams app secret, etc.)

Automate this where possible. Most LLM providers let you generate new keys without invalidating old ones immediately, so you can rotate without downtime.

If all this feels like a lot of work to get right, it is. This is exactly the kind of thing we handle as part of a professionally managed OpenClaw deployment, where we take care of the infrastructure, monitoring, and ongoing security maintenance.

Skill Installation

Skills are what make OpenClaw useful beyond basic conversation. They give your agent the ability to search databases, create tickets, generate reports, and interact with business tools.

Installing from ClawHub

You can install skills through the admin GUI or via the CLI:

docker exec openclaw openclaw-cli skill install clawhub/jira-integration
docker exec openclaw openclaw-cli skill install clawhub/google-sheets
docker exec openclaw openclaw-cli skill install clawhub/pdf-reader

The GUI is more convenient for browsing available skills, but the CLI is better for reproducible deployments. We recommend keeping a list of installed skills in a script so you can rebuild from scratch if needed.

Review Skill Code Before Installing

This is important. ClawHub is a community repository. Anyone can publish skills, and the review process is limited.

Before installing any skill, review the source code. Look for:

  • Outbound network calls to unexpected domains
  • Credential access beyond what the skill should need
  • Shell command execution or filesystem writes outside expected paths
  • Obfuscated code or minified sections that are hard to audit

We've covered this topic in detail in our guide on OpenClaw skills and ClawHub security. If you're installing skills for a business deployment, that post is worth reading before you proceed.

Pin your skills to specific versions rather than tracking latest. This prevents a supply chain attack where a compromised skill update is pulled in automatically.

docker exec openclaw openclaw-cli skill install clawhub/[email protected]

Testing Your Deployment

Before you hand this to your team, test it properly.

Basic connectivity. Open https://openclaw.yourcompany.com.au in a browser. You should see the OpenClaw web interface over HTTPS with a valid certificate.

Admin access. Log in with your admin credentials. Check that all configuration is present and correct.

Channel tests. Send a message to your bot in each connected channel. Verify that:

  • The bot receives the message
  • It generates a response using your LLM provider
  • The response appears back in the channel within a reasonable time

Security checks:

# Confirm ports aren't exposed publicly
nmap -p 3100,3200 your-server-ip
# Both should show as filtered or closed

# Confirm HTTPS is working
curl -I https://openclaw.yourcompany.com.au

# Check container resource limits
docker stats --no-stream

Failure testing. Restart the server and confirm OpenClaw comes back up automatically with its data intact. Temporarily revoke your LLM API key and check that the error message to users is sensible and doesn't leak credentials.

Load testing. If you expect more than a handful of concurrent users, send a burst of messages and watch resource usage with docker stats. Scale up your server or add resource limits accordingly.

What Comes Next

At this point, you've got a production-grade OpenClaw deployment with proper security, connected to your messaging platforms, and ready for your team to use.

The real work starts now. You'll need to:

  • Define agent behaviour through system prompts and skill configuration. What should the agent do? What should it refuse to do?
  • Set up monitoring so you know when things break. At a minimum, monitor container health, LLM API errors, and response latency.
  • Establish a review process for new skills before they're installed in production.
  • Plan for updates. OpenClaw releases frequently. Test updates in a staging environment before rolling them out.

If you're weighing up whether to build your own custom agent instead of using OpenClaw, we've compared the two approaches in OpenClaw vs custom AI agents.

For teams that want OpenClaw running in production without managing the infrastructure themselves, we offer our managed OpenClaw service. We handle the deployment, security, monitoring, and updates so your team can focus on configuring the agent for your actual business needs.

Got questions about deploying OpenClaw for your organisation? Get in touch and we'll point you in the right direction.