OpenClaw云服务器部署全攻略：Docker Compose与模型接入详解

搞OpenClaw部署有一阵子了，前前后后在蓝队云的机器上折腾了好几个版本，把容器化部署、模型接入、Control UI调优这些环节都过了一遍。这篇文章不打算讲太多虚的，直接把我在蓝队云云服务器上部署OpenClaw的完整路径、关键配置和踩坑记录写出来，希望能让后面接手的人少走几步弯路。

OpenClaw这个项目，本质上是一个可以接各种大模型能力的个人代理框架，既能跑云端API，也能接本地模型，还能通过适配器接到微信公众号、飞书这类IM平台上。部署这件事看起来就是拉个容器、配一下环境变量，但真上手你会发现，网络环境、内存规划、模型供应商的接口差异、Control UI的启动依赖，每一环都能让你卡上半天。这篇文章适合谁看？正在用蓝队云或者其他国内云服务器部署OpenClaw的运维工程师，以及准备把OpenClaw跑在Linux服务器上但还没动手的人。我会把从服务器选型到日常维护的完整链路都过一遍，尤其是那些只有踩过坑才会意识到的问题，全给你列清楚。

1. 部署前的核心判断：为什么选蓝队云和OpenClaw

1.1 OpenClaw到底是什么，适合谁用

OpenClaw的定位不是那种开箱即用的成品软件，而是一个偏“框架”性质的自动化代理平台。你可以把它理解成一条流水线：输入侧接上微信、飞书、网页对话这类前端，中间层由OpenClaw负责调度任务、维护上下文、调用工具，输出侧再接大模型API或者本地推理服务。这个架构带来的好处是，你不需要自己写一套消息分发和任务管理逻辑，OpenClaw已经帮你把骨架搭好了，你只需要把模型接入、配置好渠道就行。

我刚开始接触的时候也犯过迷糊，拿它当成ChatGPT的平替来用，后来才意识到OpenClaw更适合的场景是“需要长期运行、多渠道接入、并且要保留会话状态”的AI助手类项目。比如你想做一个能挂在自己公众号后台的客服机器人，或者一个能通过飞书机器人触发任务执行的自动化入口，OpenClaw是比裸调API要省事得多的方案。它把会话隔离、工具调用和模型调度都内置了，你只需要关心业务逻辑，不用从零开始造轮子。

但反过来，如果你只是偶尔跑几个Prompt，没有常驻服务需求，那部署OpenClaw确实是杀鸡用牛刀，还得承担服务器成本。所以我一般建议先想清楚用途再动手，OpenClaw的优势在“持续运行+多端集成”，不是一次性的推理服务。

1.2 云服务器规格怎么选，内存和CPU的计算思路

部署OpenClaw之前，先解决一个最现实的问题：服务器买多大。我在这块没有少走弯路，一开始图便宜选了台2C2G的小机器，结果容器起来了没几分钟，内存就被打满，整个服务直接假死，最后只能去控制台强制重启。

对OpenClaw这类常驻型代理服务，内存是最先要保障的资源。跑一个OpenClaw主容器，加上Redis、PostgreSQL这类依赖服务，基础开销就在1.5GB到2GB之间。这还不算模型调用的额外开销，如果你接入的是云端API（比如DeepSeek这类OpenAI兼容接口），模型推理压力不在本地，内存占用还算平稳；但如果你要在服务器上再跑本地模型，比如通过Ollama加载一个7B量化模型，那至少再预留4GB内存，15B以上甚至要32GB起步。

以蓝队云常见的几档配置为例，我实际测下来是这样的：

有一点需要特别说明，OpenClaw本身对CPU的消耗并没有那么夸张，瓶颈主要在内存和磁盘IO。容器频繁写日志、模型上下文增长，都会持续消耗IO，所以我建议数据盘选SSD。蓝队云默认系统盘通常是SSD，不用额外操心，但如果你自己挂载了数据盘，记得确认不是普通HDD，不然日志一多，读写延迟会让你明显感觉到卡顿。

1.3 系统镜像与初始化设置

服务器配置确定之后，下一个选择是系统镜像。我在蓝队云控制台创建实例时，第一反应选了最新的Ubuntu 24.04，图它软件包新。后来发现，OpenClaw的部署脚本和依赖对Ubuntu 22.04 LTS的兼容性反而更稳定，24.04在某些依赖编译环节会踩CMake版本和Python版本的坑。如果你是新手，我建议直接选Ubuntu 22.04 LTS，省心。

系统装好之后，第一件事不是急着装OpenClaw，而是先做三件初始化工作。第一，新建一个非root用户，OpenClaw的容器运行不要用root身份，万一容器被打穿，root权限的后果会很严重。第二，把SSH登录改成密钥方式，密码登录能关就关。第三，更新系统包并装好基础工具，curl、wget、git、vim这些是后面一定会用到的。这三步看着不起眼，但直接影响后面部署的稳定性和安全性。

还有一个小细节，蓝队云控制台的安全组默认是只放行22端口和ICMP的。你后面要开放Web端口给Control UI访问，记得提前在安全组里加规则，不然容器端口映射得再好，外部也连不上。这个我在后面避坑部分会专门展开。

2. 部署方案选型：为什么我最终选了Docker Compose

2.1 三种常见部署方式对比

OpenClaw的部署方式，市面上常见的有三种：直接二进制运行、一键脚本、Docker Compose。这三种我都试过，简单说一下各自的适用场景。

直接二进制运行，就是把OpenClaw发布的可执行文件下载到服务器上，装好运行时依赖，然后直接跑进程。这种方式的好处是资源占用低，没有容器层，适合配置比较低的机器。但坏处也很明显，依赖管理非常痛苦，Python版本、Node版本、系统库版本有一个不对就起不来，升级还容易把环境搞坏。我个人不太推荐，除非你服务器内存实在紧张到跑不动容器。

一键脚本部署，是官方提供的一个安装脚本，自动拉取依赖、建目录、起服务。速度确实快，点点键盘就能跑起来，但对网络环境要求高，中途很容易因为某个包拉不下来直接报错，而且脚本不会给你完整的配置解释，出了问题不好排查。适合本地测试或临时体验，不太适合生产环境长期用。

最后是Docker Compose，也是我最终选用的方案。原因有几个：第一个是依赖隔离做得好，PostgreSQL、Redis、OpenClaw主服务各跑各的容器，互不干扰；第二个是升级方便，拉一个新镜像重新up一下就行，不用动系统环境；第三个是配置集中管理，所有的环境变量、端口映射、数据卷都在一个docker-compose.yml里，换服务器可以直接把这个文件搬过去。当然，代价就是需要多留一点磁盘和内存空间，但对现在的服务器配置来说，这点开销完全可以接受。

2.2 目录规划与数据卷设计

选好Docker Compose之后，我建议先把目录结构规划清楚。这一步看着简单，但直接关系到后面的备份和迁移。我用的是这样一个目录布局：

bash复制/opt/openclaw/
├── docker-compose.yml
├── .env
├── data/
│   ├── postgres/
│   └── openclaw/
└── logs/

所有配置文件放在顶层，数据目录单独挂出来，日志统一收集。这样做的核心好处是，备份的时候只要打包data目录和环境变量文件，换服务器直接还原就行，不需要关心容器内部的状态。

数据卷的设计也是这个思路。在docker-compose.yml里，我会把PostgreSQL的数据目录、OpenClaw的会话存储目录、日志目录都映射到宿主机，这样即使容器被删掉重建，数据和会话记录也不会丢。这块我一开始没当回事，后来有一次手滑执行了docker compose down -v，把卷也删了，所有会话历史全没了，从那以后我再也没用-v参数清理过。

2.3 模型接入路径：云端API还是本地模型

OpenClaw本身不产模型，它需要你提供一个可调用的模型服务。这个选择会直接影响服务器配制方案，也会影响部署复杂度。

如果你接的是云端API，比如DeepSeek、OpenAI兼容接口或者其他商业大模型服务，OpenClaw那边只需要配置API地址、API Key和模型名称。这种方式部署最简单，服务器也不需要太高配置，内存够跑框架本身就行。我个人的建议是，第一轮部署先用云端API把整个链路跑通，验证OpenClaw本身没有问题，再考虑本地模型。

本地模型的部署路径就复杂不少。你想在服务器上用Ollama跑一个7B模型，需要先装Ollama，再拉模型文件，然后把OpenClaw的模型配置指向Ollama的本地地址。这一步对服务器性能的要求会直线上升，而且不同的量化精度、上下文长度都会影响模型的响应速度和稳定性。如果你是非机器学习方向的运维工程师，我建议初期不要选本地模型，先把OpenClaw的整体流程跑顺，之后再研究模型本地化的事。

3. 实操部署：从裸机到OpenClaw跑通的完整记录

3.1 系统基础环境与Docker安装

我以Ubuntu 22.04 LTS为例，把完整操作过程写下来。

先更新系统，然后安装必要工具：

bash复制sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget git vim ufw

然后安装Docker和Docker Compose插件。这里我推荐用官方脚本，但国内服务器直接访问官方源可能会很慢，我一般先配置阿里云的Docker镜像源，再装Docker，速度会快很多：

bash复制curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun

装完之后，启动Docker并设置开机自启：

bash复制sudo systemctl enable --now docker
sudo systemctl status docker

最后确认Docker Compose插件可用：

bash复制docker compose version

看到版本号输出就算装好了。这里有一个很容易踩的坑，就是老教程会让你用docker-compose（带横杠）这个独立二进制，新版本Docker推荐的是docker compose（带空格）插件。两者的命令语法差别不大，但如果你在服务器上两个都没有，直接装插件版就行，别去装老版的独立二进制了。

3.2 编写OpenClaw的docker-compose.yml

OpenClaw的完整依赖包括三块：PostgreSQL用来存会话和用户数据，Redis用来做缓存和任务队列，OpenClaw主服务负责核心逻辑。我没有用官方自带的一体化镜像，而是拆开部署，这样每个组件的日志和资源占用都看得清。

一个可用的docker-compose.yml大致长这样：

yaml复制version: "3.8"

services:
  postgres:
    image: postgres:15-alpine
    container_name: openclaw-postgres
    restart: always
    environment:
      POSTGRES_DB: openclaw
      POSTGRES_USER: openclaw
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    networks:
      - openclaw-net

  redis:
    image: redis:7-alpine
    container_name: openclaw-redis
    restart: always
    command: redis-server --appendonly yes
    volumes:
      - ./data/redis:/data
    networks:
      - openclaw-net

  openclaw:
    image: ${OPENCLAW_IMAGE:-openclaw/openclaw:latest}
    container_name: openclaw-main
    restart: always
    depends_on:
      - postgres
      - redis
    ports:
      - "8080:8080"
    env_file:
      - .env
    environment:
      DATABASE_URL: postgresql://openclaw:${POSTGRES_PASSWORD}@postgres:5432/openclaw
      REDIS_URL: redis://redis:6379
    volumes:
      - ./data/openclaw:/data
      - ./logs:/logs
    networks:
      - openclaw-net

networks:
  openclaw-net:
    driver: bridge

这个文件里，我特意用了.env文件来管理所有敏感配置，而不是直接把密码和API Key写死在yaml里。这样有一个实际好处：docker-compose.yml本身是可以提交到Git仓库的，但.env要加进.gitignore，密钥不会泄露。

PostgreSQL和Redis都挂载了数据卷，容器重建后数据不会丢。主服务的端口映射，我这里先用8080，如果你服务器上已经有程序占用了，可以改成8081之类的端口，但要记得同步改安全组规则。

重要提示： 第一次启动前，记得先把.env文件准备好，否则容器会因为缺少必填环境变量直接启动失败。我后面会专门写.env的配置方法。

3.3 配置模型接入与认证信息

先把.env文件建出来，核心配置项如下：

bash复制# OpenClaw 基础配置
OPENCLAW_API_KEY=你的自定义令牌
OPENCLAW_WEB_PORT=8080

# 数据库配置
POSTGRES_PASSWORD=一个足够复杂的密码

# 模型配置，以DeepSeek的OpenAI兼容接口为例
MODEL_PROVIDER=openai
MODEL_API_BASE=https://api.deepseek.com/v1
MODEL_API_KEY=你的DeepSeek API Key
MODEL_NAME=deepseek-chat

这里有一个关键点，OpenClaw对“Model Provider”这个字段的判断比较严格。如果你用的是OpenAI官方接口，那MODEL_PROVIDER直接写openai；如果你用的是DeepSeek这类兼容OpenAI格式的第三方接口，虽然接口格式一致，但有些版本会把MODEL_API_BASE拼接到默认路径后面，导致请求地址变成https://api.deepseek.com/v1/v1/chat/completions这种重复路径，直接报404。我在部署时遇到的就是这个情况，解决办法是把MODEL_API_BASE写成https://api.deepseek.com，不带/v1后缀，让OpenClaw自己去拼标准路径。

另外，OpenClaw本身也有一个认证令牌的概念，也就是OPENCLAW_API_KEY，这个是用来保护OpenClaw自己暴露出来的接口的。如果你要把Control UI暴露到公网，这个令牌一定要设置，而且要设置得足够长足够随机。不然任何知道端口的人都能直接访问你的管理界面，后果很严重。

3.4 启动服务与验证

配置都准备好了之后，第一次启动的完整命令是：

bash复制cd /opt/openclaw
docker compose up -d

启动后不要急着看Web界面，先确认所有容器都处于正常运行状态：

bash复制docker compose ps

这个命令会列出所有容器的状态。正常情况应该是三个容器都是Up状态。如果postgres容器反复重启，多半是数据卷权限或者密码配置问题，看日志是最直接的排查方式：

bash复制docker compose logs postgres
docker compose logs openclaw

OpenClaw主服务启动完成后，日志里会出现监听地址和端口，像这样：

bash复制INFO  Server listening on http://0.0.0.0:8080

到这一步，OpenClaw的骨架就算跑起来了。但离真正能用还差最后一步：把Control UI也启动起来。我后面会在避坑部分专门讲Control UI起不来的几种情况。

4. 避坑实录：我踩过的五个关键坑

4.1 内存不足导致容器反复OOM

这是我最开始用2C2G小机器时遇到的最大问题。现象很典型，容器启动后一两分钟还行，一旦有新会话接入，内存飙升，进程被系统OOM Killer杀掉，容器自动重启，然后再杀掉，反复循环。

排查方法很简单，执行free -h看内存占用，再用docker stats看每个容器的实时占用情况。我当时的瓶颈就是redis和postgres本身就要占掉600MB左右，OpenClaw主进程启动就要500MB以上，2G内存根本转不开。

解决办法就两个方向，要么加内存，要么精简组件。我是直接升到了4G内存，然后把redis的持久化策略改成了RDB快照模式而不是AOF，减少内存占用。如果你手头机器已经买了不能退，可以先停掉postgres，改用SQLite模式试跑一下，但只建议测试用，长期跑还是得正经用数据库。

4.2 模型配置格式错误，agent failed before reply

这个报错信息我印象太深了，因为它是字面意义上的“起不来”：OpenClaw接收消息后，Agent直接回复失败，错误提示是agent failed before reply: unknown model: deepseek-chat。当时我第一反应是模型名字写错了，但检查了半天，确认DeepSeek的模型名就是deepseek-chat，没写错。

后来翻日志才发现，问题不在模型名字，而在MODEL_API_BASE的路径拼接。OpenClaw在发起请求时，会把API Base、API路径、模型名拼在一起，如果API Base带了多余的路径后缀，最终请求的URL就是错的，模型服务根本收不到请求，返回给OpenClaw的报错也被误解析成“unknown model”。

这事的教训是：报错信息指向的不一定是真正的问题根源。看到“unknown model”、“invalid model”这类错误，先去抓OpenClaw容器的实际出站请求日志，看看请求URL到底是什么。我后来直接用curl模拟了一次API调用，请求能通，才确认问题出在路径拼接上。

4.3 Control UI did not start

OpenClaw的Control UI是一个Web管理界面，可以用来查看会话、调整配置、管理渠道绑定。但我在部署时遇到过一次很典型的报错：control ui did not start，而且是在OpenClaw主服务已经正常启动之后才报的。

排查了很久发现，Control UI默认需要访问一个本地的静态资源目录，如果数据卷没挂载或者目录权限不正确，UI进程会被跳过。解决办法分两步，第一步确认.env里Control UI相关的开关有没有打开，有些版本默认不启用；第二步确认./data/openclaw目录有可写权限，容器内的用户需要能在这个目录下创建文件。

如果你在日志里看到control ui did not start，但主服务已经起来了，先别急着删容器。逐个检查环境变量和数据卷权限，大概率是这两个地方的问题。还有一个小概率事件是端口冲突，对照docker-compose.yml里的端口配置看一下就行。

4.4 端口映射正常但外部访问不通

这个问题非常隐蔽，因为它不在容器层面，而发生在云平台的安全组层面。我当时在蓝队云的控制台上开放了8080端口的安全组规则，安全组也显示已生效，但在家访问服务器IP:8080，就是死活连不上。

排查思路是这样一条线走下来的：先在服务器本地用curl http://127.0.0.1:8080测，能通，说明容器和服务都正常；再用ss -tlnp | grep 8080确认监听地址，发现监听的是0.0.0.0:8080，说明服务对公网开放了；最后查防火墙，发现本机ufw虽然状态是inactive，但Docker的iptables规则可能被之前的清理命令动过，导致端口转发没生效。

最终的解决办法是重启Docker服务，让它重新生成一遍iptables规则，问题立即消失。如果你也遇到类似情况，我建议按“容器内部 -> 服务器本机 -> 防火墙 -> 云平台安全组”这条链路从里到外排查，保证每一步都通，问题自然能定位到具体位置。

4.5 容器重建后配置丢了大半

最后这个坑算是给我长了教训。有一次升级OpenClaw镜像，我执行了docker compose up -d，结果因为docker-compose.yml里漏写了几个环境变量，容器起来了但功能缺失，我之前在Control UI里做的一些配置也好像回到了默认状态。

后来仔细看文档才明白，OpenClaw有一层配置是存在自己的数据卷里的，环境变量只是起覆盖作用。如果数据卷没挂对，环境变量再全也会丢。所以我现在维护OpenClaw，第一原则就是：docker-compose.yml、.env、data/目录三者必须放在同一个父目录下，每次升级前先备份整个目录，再执行pull和up操作。这样即使升级翻车，也随时可以回滚到上一个可用版本。

5. 常见问题排查与日常运维要点

5.1 排错思维：先看日志，再动手重启

OpenClaw的日志输出量不小，尤其在你接入多渠道之后，每天会产生大量对话记录和调试信息。日志管理不当，磁盘很快就会满。我见过不少部署OpenClaw的朋友，容器跑着跑着突然整个服务不可用，ssh进去执行df -h才发现根目录已经100%。

我个人的日志策略是这样的：在docker-compose.yml里加入日志驱动大小限制，防止单个容器无限写日志：

yaml复制logging:
  driver: "json-file"
  options:
    max-size: "50m"
    max-file: "5"

并且用logrotate对宿主机上的日志目录做轮转。加了限制之后，单容器最多占250MB日志空间，对磁盘压力就能控制住了。这步虽然不起眼，但在长期运维中非常关键。

还有一点，OpenClaw容器输出的日志默认是打进Docker的日志驱动，不会写入我挂载的logs目录。所以如果你想用docker compose logs -f openclaw实时看日志，这是没问题的；但如果你想保留日志文件做分析，需要额外配置日志采集，或者用TLSP之类的工具。我在生产环境就是直接靠docker compose logs查，够用，不额外做采集。

5.2 开放接口的安全维护

OpenClaw跑起来之后，你会暴露两个端口：一是OpenClaw本身的HTTP接口，二是PostgreSQL和Redis这些内部组件的端口。对外只需要暴露OpenClaw的Web端口，数据库端口和Redis端口一定不要暴露到公网，否则等于把数据裸奔在互联网上。

我在蓝队云安全组里只放行了Web端口和SSH端口。Redis和PostgreSQL的端口只允许内网访问，靠docker网络隔离就够了。还有一点，如果你的OpenClaw服务要长期对公网开放，建议在Web服务外层套一层Nginx做反向代理，配上SSL证书，不要直接用裸IP加端口给用户用。这样既安全，也方便以后做域名绑定和HTTPS访问。

5.3 常用运维命令整理

最后把日常维护用得最多的命令整理成一个速查表，方便直接抄作业：

这里有一个小建议：日常维护中，能用docker compose restart解决的，就别用docker compose down再加up -d。down会把容器删掉，如果数据卷挂载有问题，会导致数据丢失的风险。我已经看到过不少人因为养成“不干净不痛快”习惯，把好好的环境删没了。

5.4 定期备份与恢复

最后聊一下备份的事。OpenClaw的核心数据就三块：PostgreSQL里存的用户和会话、data目录下存的配置缓存、.env里的密钥和模型配置。

我用的备份方案是一个简单的脚本，每天凌晨打包关键目录和数据库导出文件：

bash复制#!/bin/bash
BACKUP_DIR=/opt/backups/openclaw
mkdir -p $BACKUP_DIR
docker compose exec -T postgres pg_dump -U openclaw openclaw > $BACKUP_DIR/openclaw_$(date +%F).sql
tar czf $BACKUP_DIR/openclaw_data_$(date +%F).tar.gz -C /opt/openclaw data .env docker-compose.yml --exclude=logs

配合crontab每天凌晨执行，再定期把备份文件下载到本地或同步到对象存储。恢复的时候，先按原目录结构把docker-compose.yml和.env放好，再导入数据库备份，最后启动服务就行。

6. 写在最后的几条运维心得

OpenClaw部署这件事，说难不算难，说简单也不简单。它最大的特点就是“链路长”，从服务器选型、系统初始化，到容器编排、模型接入、网络安全，每一层都有各自的问题，而你作为一个运维，需要把这条链路全部穿透。这恰恰是云服务器部署这类工作最有意思的地方——你不是在配一个应用，而是在搭一套能持续运转的小型基础设施。

我自己的体会是，别一上来就追求最完整的配置，而是先用最简单的云端API方案，把OpenClaw从启动到对话跑通，再逐步加数据库、加多渠道、加本地模型。每加一层，就验证一次，出了问题也容易定位。这个过程走顺之后，你对OpenClaw的整个架构理解，会比任何教程都深刻。

最后再分享一个小细节，OpenClaw容器的时区默认是UTC，这会导致日志时间和我们本地时间相差8个小时。我当时排查一个定时任务问题，对着日志时间怎么都对不上，后来才意识到是时区差。解决办法是在docker-compose.yml的环境变量里加上TZ=Asia/Shanghai，之后日志时间就正常了。这种小坑，遇到一次之后就会记得很牢。