Deployment Overview

Deployment Options at a Glance

OpenClaw is a Python package — it runs wherever Python 3.10+ runs. Choose your deployment method based on your team size, reliability requirements, and operational overhead tolerance:

Production Architecture

A production-ready OpenClaw deployment is more than just the agent process. The following components work together to provide reliability, observability, and security:

• OpenClaw daemon — the agent runtime, accepts tasks via REST API or message queue and executes them asynchronously
• Task queue — Redis or RabbitMQ for async task dispatch, retry logic, and workload distribution across multiple workers
• Cache layer — Redis for LLM response caching; reduces API costs and latency for repeated or similar queries
• Secrets manager — HashiCorp Vault, AWS Secrets Manager, or Doppler for storing API keys outside of config files and environment variables
• Database — SQLite works for development; PostgreSQL is recommended for production conversation history and audit logs
• Observability stack — Prometheus + Grafana for metrics, or a managed APM like Datadog or New Relic
• Reverse proxy — Nginx or Caddy in front of the OpenClaw API for TLS termination, rate limiting, and request logging

Internet → [Nginx / Caddy (TLS)] → [OpenClaw API]
                                         ↓
                              [Task Queue (Redis)]
                                    ↓          ↓
                           [Worker 1]    [Worker 2]
                               ↓               ↓
                   [Cache (Redis)]    [Database (PostgreSQL)]
                               ↓
                   [LLM Provider APIs]

Minimum System Requirements

OpenClaw is lightweight — you don't need a powerful server for most workloads. The main resource consumers are the task queue (Redis) and any local models you run:

Pre-Deployment Checklist

Before deploying to production, verify each of these items. Skipping any of them is the most common cause of production incidents:

Core Environment Variables

These environment variables must be set in every deployment environment. Never hardcode them in your config files:

# Required — at least one LLM provider key
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...

# Required in production
OPENCLAW_ENV=production
OPENCLAW_SECRET_KEY=your-32-byte-random-secret

# Optional but recommended
REDIS_URL=redis://redis:6379/0
DATABASE_URL=postgresql://user:pass@db:5432/openclaw
OPENCLAW_LOG_LEVEL=INFO

See the complete reference at All Environment Variables.

Recommended Deployment Workflow

A simple but effective workflow for deploying OpenClaw changes to production:

1. Build and test locally with docker compose up and run your test suite
2. Push to a staging environment — an identical replica of production with test data
3. Run smoke tests on staging: a handful of representative agent tasks that cover critical paths
4. Deploy to production using a rolling update (zero downtime) — one instance at a time
5. Monitor the first 30 minutes after deploy: watch error rates, latency, and cache hit ratios
6. Keep the previous image tagged so you can roll back in under 2 minutes if needed

Deployment Option Comparison

Choosing the right deployment target depends on your organization's existing infrastructure, expertise, compliance requirements, and operational capacity. Docker Compose on a single VM is the simplest path for small teams with a single agent at low traffic. Kubernetes suits organizations that already operate Kubernetes clusters and need fine-grained resource management across many services. Cloud-managed services (ECS, Cloud Run, Container Apps) are the best default for most new deployments — they eliminate infrastructure management overhead while providing production-grade reliability, scaling, and security integration with the cloud provider's IAM and secrets systems.

Consider your team's operational expertise honestly. A Kubernetes deployment that no one on the team knows how to debug in production is worse than a simpler Docker deployment that your team manages confidently. Operational complexity should match your team's capabilities — deploy the simplest approach that meets your reliability and scaling requirements, and only add complexity when you have a clear, quantified need for it. The most reliable production system is the one your team understands well enough to maintain and troubleshoot.