Deploying OpenClaw to production means taking the Gateway from your local machine to reliable, monitored infrastructure. OpenClaw supports multiple deployment targets: Docker containers, VPS instances, Kubernetes clusters, and platform-as-a-service providers like Fly.io and Railway. The key to a solid production deployment is the combination of a process manager, a reverse proxy with TLS, health checks, and monitoring. OpenClaw is a single process by design, which makes deployment simple compared to distributed systems.
Master openclaw production deployment
Take the OpenClaw for Production & Advanced Use course with hands-on lessons and challenges.
This docker-compose file runs the Gateway with the config file mounted read-only and agent data persisted in a Docker volume. Environment variables pass secrets without committing them. The health check ensures Docker restarts the container if the Gateway becomes unresponsive. The 'unless-stopped' restart policy handles crashes and system reboots.
Caddy is the simplest reverse proxy for production because it auto-provisions TLS certificates from Let's Encrypt. The pm2 process manager keeps the Gateway running and auto-starts it on system reboots. This two-command setup (pm2 + Caddy) is production-ready for most small-to-medium deployments.
This Kubernetes deployment runs a single Gateway replica with liveness and readiness probes. Secrets are injected from a Kubernetes Secret. The configuration comes from a ConfigMap, and agent data is persisted via a PersistentVolumeClaim. Note: replicas is set to 1 because the Gateway is a single-process architecture.
Fly.io provides a simple deployment path with automatic TLS, persistent volumes, and health checks. The mounted volume persists agent data across deploys. Fly.io also supports other regions (lhr, nrt) for latency optimization. Set secrets with `fly secrets set ANTHROPIC_API_KEY=sk-ant-...`.
These commands provide complete visibility into a running Gateway. The /health endpoint returns JSON that monitoring tools (Datadog, Prometheus, UptimeRobot) can consume. Filter logs by type to quickly find errors, automation results, or security events.
Running the Gateway without a process manager in production, causing it to stop when the SSH session closes or after a crash
Always use pm2, systemd, Docker restart policies, or Kubernetes for production. The Gateway must restart automatically on crashes and persist across reboots.
Exposing the Gateway port directly to the internet without a reverse proxy, missing TLS encryption and rate limiting
Place Nginx, Caddy, or a cloud load balancer in front of the Gateway. This provides TLS termination, rate limiting, and protection against direct attacks on the Gateway port.
Setting Kubernetes replicas to more than 1, expecting horizontal scaling, when the Gateway is a single-process architecture
OpenClaw runs as a single process. Multiple replicas would create independent gateways with separate sessions and state. For high availability, use liveness probes and auto-restart instead of multiple replicas.
Not persisting the agents directory across deploys, losing all session history, memory, and bootstrap files on container recreation
Mount the agents directory as a persistent volume (Docker volume, PVC, Fly.io mount). This directory contains irreplaceable data: MEMORY.md, session history, and SOUL.md files.
Deploying OpenClaw to production requires a process manager (pm2, Docker, Kubernetes), a reverse proxy with TLS (Caddy, Nginx), health checks, and persistent storage for agent data. Docker is recommended for most teams. The Gateway is a single-process architecture -- do not scale with replicas. Persist the agents directory across deploys. Set up external monitoring on the /health endpoint. Use separate staging and production configurations.
Interactive lessons and challenges on Stanza, practice in VS Code, Cursor, or the web.
Interactive lessons and challenges, right in your code editor.
Check the free courses. No credit card.