把 OpenClaw 的官方部署文档翻完一遍后我反正是被劝退过一次。架构图画了六七个组件一会儿要消息队列、一会儿要高可用数据库光是部署文档里的前置依赖就能列出一整页。但实际用起来自己做一个内部工具或者给一个小团队用根本不需要这么重的底座。这篇文章就是我在 AWS 上实际把 OpenClaw 简化部署完之后的记录。我会告诉你一个更直接的路线一台 EC2、一个 S3 桶、一个最小权限的 IAM 角色再配上一份 systemd 服务配置就可以把 OpenClaw 跑起来并长期维护。这套方案没有砍掉安全步骤只是把高可用、自动扩展、托管数据库这些“生产环境增强项”暂时放到一边让第一次接触的人能在一个下午内把东西操作起来并且知道出了问题该去哪里查。1. 这个简化版不是偷工减料先搞清楚 OpenClaw 在 AWS 上到底需要什么1.1 OpenClaw 的组件和运行依赖OpenClaw 本身是一个开源的服务端组件核心做的事情可以理解为“把任务收拢、调度、执行再把结果推出去”。它的运行通常由三部分配合完成负责接收任务与暴露接口的主进程、负责真正跑脚本或命令的执行器、负责保存元数据和运行记录的状态存储。在官方默认的完整架构里这三部分可能被拆到不同机器上中间再用消息队列解耦。但简化部署时完全可以跑在同一台 EC2 上主进程同执行器之间通过本机回环网络通信状态存储使用本地 SQLite 文件日志走系统自带的 journald 或 logrotate。这样不仅减少了一半的组件排障时也不需要跳好几台机器去查日志。基础运行依赖其实很低。OpenClaw 是编译好的静态二进制依赖于 Linux 内核的基本能力不需要预先安装数据库、不需要单独装 PHP 或 Node.js 之类的东西。我曾经在一台 1 核 1GB 内存的机器上跑过一段时间日常占用大概在几百 MB 内存CPU 也主要是集中在执行任务的瞬间。所以选型门槛比想象中低很多。1.2 简化版与完整版的差距在哪里我把完整版和简化版的关键差异总结成下面这张表方便你判断自己到底需要哪一层。对比项完整部署方案本文的简化版节点数量多节点负载均衡单台 EC2调度依赖分布式消息队列应用内调度 systemd数据库PostgreSQL 独立实例本地 SQLite外部入口ALB / CDN / API Gateway弹性 IP 直连端口备份策略跨区域复制 自动恢复演练每日 S3 定时同步适用场景正式产品、多人团队、SLA 要求高内部工具、小团队、个人项目这不是“功能上偷工减料”而是用更简单的组件替代了复杂组件。SQLite 在低并发、单写多读的场景下稳定性足够好systemd 对进程守护和自动重启的支持也完全够用。只要你不追求多节点同时执行任务这套方案能覆盖绝大多数使用场景。2. 动手之前的四步准备账号、权限、网络和选型2.1 一个最小可用的 IAM 策略不要给服务器绑管理密钥在 AWS 上部署应用时最常被忽略但影响最大的是权限设计。很多人图省事直接给 EC2 关联一个 AdministratorAccess 角色或者干脆在服务器里保存一个永不过期的访问密钥。这两种做法都属于给自己埋雷。简化版的做法是创建一个专门的角色只授权访问备份所需的 S3 桶。在 EC2 控制台创建实例时把这个角色挂到实例上。OpenClaw 运行时通过实例配置文件自动获取临时凭证去读写对象存储不会在服务器里存任何长期密钥。下面是一条最小范围的 IAM 策略只需要给你自己的桶授权{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ s3:ListBucket, s3:GetObject, s3:PutObject, s3:DeleteObject ], Resource: [ arn:aws:s3:::your-openclaw-backup-bucket, arn:aws:s3:::your-openclaw-backup-bucket/* ] } ] }这里唯一需要改的是桶名后面备份脚本也会用到它。不要为这个角色额外加上 ec2:* 的权限备份任务不需要它。如果你的 EC2 已经启动并且之前没有绑定角色不需要重建实例。在控制台选中实例找到“操作”里的“修改 IAM 角色”选项把角色加上即可。这个动作不会中断实例也不会影响已运行的服务。2.2 地域和实例规格怎么选地域选择优先考虑“离 OpenClaw 的主要调用方近”。如果这个服务是给你自己写的小工具用的你日常在哪个区域管理资源就选哪个区域如果它是给某个业务系统做任务调度的那就选业务系统所在的区域。跨地域调用虽然也能跑通但网络延迟会体现在每一次任务提交和执行状态回传上没必要为了省钱跨半个地球。规格方面我建议从 t3.micro 或 t3.small 起步。t3.micro 是 1 核 1GB适合每天几百次小任务t3.small 是 1 核 2GB适合任务频繁一点或脚本稍微吃内存的场景。这类实例有 CPU 积分机制如果长期满负荷跑性能会受限。所以如果业务是那种每天都有大量定时任务且持续输出的请直接选计算型或通用型系列别贪便宜。存储卷建议用 gp3并且把根卷容量从默认值调大至少给到 40GB。OpenClaw 的运行日志、执行产物、临时文件加起来会比你想象中涨得快根卷太小会导致后面频繁清日志。gp3 的单价不高多出来的成本几乎可以忽略省下的是后续磁盘告警的运维时间。2.3 安全组一条 SSH、一条应用端口、一条健康检查足够了安全组是 AWS 上的实例防火墙配错了最常见的表现就是“服务明明在跑外面却访问不到”。简化版只需要几条入站规则。协议/端口来源用途TCP 22你本地的固定 IP 或小型办公网段SSH 管理TCP 8080调用方所在的网段或安全组OpenClaw API 端口TCP 8080你自己的跳板机 IP健康检查与排查注意不要把 TCP 22 开放给 0.0.0.0/0。我之前见过有人把 SSH 端口全放开结果实例被扫描爆破这是完全可以通过安全组规避的风险。如果你的入口 IP 不固定更推荐的方式是通过 IAM 配合会话管理功能登录这样甚至可以不开 22 端口。出站规则保持默认即可也就是允许全部出站。如果你们公司有严格的出站管控至少保证实例能访问 S3 的 HTTPS 端点以及 NTP 的时间同步端口否则备份和时间同步都会出问题。2.4 存储避开数据库“看似省事实际麻烦”的坑在简化部署里我特意没有使用 AWS 的托管关系型数据库。原因不是它不好而是对于单节点运行的 OpenClaw数据库实例本身成了一个额外的运维对象。你需要维护连接数、处理备份、关注版本升级而这些对一个小规模应用来说负担太重。OpenClaw 的状态存储用本地 SQLite 文件就够了。SQLite 在低并发下表现很出色单写多读的模式也正是 OpenClaw 调度引擎的场景。它会锁住写入但 OpenClaw 本身在简化模式下就是单节点运行多个执行器本机并发写入时SQLite 的锁策略完全能扛住。为了避免未来需要替换实例时数据丢失我会把 OpenClaw 的数据目录单独放到一块 EBS 数据卷上而不是用根卷。这样即使实例发生故障你也可以把数据卷从旧实例解绑并挂到新实例上数据立刻就能恢复。实际操作中如果只是个人测试单独数据卷不是必选项但你想让服务能长治久安地跑下去这一条非常值得做。3. 从空机器到 OpenClaw 跑起来完整部署步骤3.1 用用户数据脚本和环境变量固定配置防止重启之后傻眼我习惯在创建 EC2 实例时就把初始化工作写成用户数据脚本而不是等机器起来后再手工敲命令。这样做的最大好处是以后想复制一套新环境时只需要重放这份脚本生成过程可复现不会出现“上次我少装了什么导致服务起不来”的情况。下面这份脚本的思路是更新系统包、创建专用用户、准备目录、写入 OpenClaw 的配置文件。下载链接可以用你实际部署包的发布地址替换。#!/bin/bash set -euo pipefail # 更新系统 export DEBIAN_FRONTENDnoninteractive apt-get update -y apt-get install -y curl unzip rsync logrotate chrony # 创建目录和用户 useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw mkdir -p /opt/openclaw/bin mkdir -p /opt/openclaw/data mkdir -p /opt/openclaw/logs # 下载 OpenClaw替换为实际发布的下载地址 curl -fsSL https://example.com/openclaw/latest/openclaw-x86_64.tar.gz \ -o /tmp/openclaw.tar.gz tar -xzf /tmp/openclaw.tar.gz -C /opt/openclaw/bin chown -R openclaw:openclaw /opt/openclaw # 写入环境变量 cat /opt/openclaw/env.conf EOF OPENCLAW_HOME/opt/openclaw OPENCLAW_DATA_DIR/opt/openclaw/data OPENCLAW_LISTEN_ADDR0.0.0.0:8080 OPENCLAW_BACKUP_BUCKETyour-openclaw-backup-bucket OPENCLAW_AWS_REGIONap-southeast-1 EOF chown openclaw:openclaw /opt/openclaw/env.conf有几个细节容易踩坑。第一不要在用户数据脚本里写入任何长期密钥比如数据库密码或 API Token。你的 IAM 角色已经解决了云资源访问问题应用自身的密钥应该在启动后通过 secret 管理工具或手动安全注入。第二脚本里设置的监听地址是 0.0.0.0实际对外暴露范围还要靠前面安全组卡位安全组才是真正的边界。3.2 把 OpenClaw 作为 systemd 服务跑起来而不是挂在终端里不要用 nohup 或直接在当前终端里启动 OpenClaw。一旦你的 SSH 会话断开进程就可能收到挂断信号退出。正确的做法是交给 systemd 管理让它负责开机自启、崩溃拉起和标准输出去向。在/etc/systemd/system/openclaw.service写入[Unit] DescriptionOpenClaw Service Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Useropenclaw Groupopenclaw EnvironmentFile/opt/openclaw/env.conf ExecStart/opt/openclaw/bin/openclaw serve Restartalways RestartSec5 ExecReload/bin/kill -HUP $MAINPID [Install] WantedBymulti-user.target写完后的启用命令是systemctl daemon-reload systemctl enable --now openclaw systemctl status openclaw这里的关键逻辑是 Restartalways。如果 OpenClaw 因为某个任务脚本导致进程崩溃systemd 会在 5 秒后自动拉起。你可以通过一种方式模拟测试直接杀掉进程再观察状态正常情况下它会自动恢复。这一步对后期稳定性非常重要。为什么不在这套部署里引入容器因为 OpenClaw 是单一静态二进制依赖很少systemd 加环境配置文件已经是可复现方案。容器引擎会引入镜像升级、网络模式、数据卷挂载等额外概念对只跑一个应用的简化版来说收益并不明显。当然这不是说容器方案不好而是从维护成本角度它能等以后规模变大了再使用。3.3 通过 AWS 的弹性 IP 还是内网入口如果你的 OpenClaw 对外提供 API对外入口有两种选择弹性 IP 或内网 DNS。我建议用弹性 IP 弹性 IP 绑定的方式先解决“IP 会变”的问题。EC2 公网 IP 在实例停止再启动后会更换如果你把它写进了调用方配置停一次实例就要改一次配置文件。弹性 IP 能够固定这个地址绑定到实例上以后即使重启实例IP 也不会变。使用时注意弹性 IP 只在绑定到运行中实例时免费如果你开了实例但忘了绑定或绑定的实例处于停止状态会收取少量费用。如果你的调用方全部都在同一个 VPC 或专线网络内那么别使用公网入口直接用内网 IP 或内网 DNS 更安全。安全组里也不用为 8080 端口放开公网来源来源可以直接填 VPC 网段。等到需要跨环境调用的场景出现再考虑公网入口原则是别把自己的管理服务盲目暴露到公网。3.4 配置日志轮转和定时备份到 S3OpenClaw 跑起来之后第一件不能省的事是日志轮转。默认情况下系统日志会一直增长几个月后磁盘被占满服务就可能开始出现各种诡异问题。在/etc/logrotate.d/openclaw写一份配置/opt/openclaw/logs/*.log { weekly rotate 4 compress delaycompress missingok notifempty copytruncate }这份配置的意思是每周切一次日志保留四份旧日志压缩保存。copytruncate对 OpenClaw 这种持续写入的进程很关键它先复制文件内容再清空原文件不需要重启服务也不会丢失正在写的日志。备份走 S3 是所有步骤里性价比最高的一步。在 cron 里放一条任务10 2 * * * aws s3 sync /opt/openclaw/data s3://your-openclaw-backup-bucket/backups/$(date \\%F)/ --delete注意脚本里的 IAM 权限和 AWS CLI 配置如果你用实例角色机器的 CLI 不需要执行aws configureSDK 和 CLI 会自动从实例元数据服务获取临时密钥。备份策略有一个容易被忽略的细节定期备份不等于可以恢复。我习惯每两周手动从备份数据启动一个临时实例验证备份数据能否真正被读取并恢复避免某天发现备份文件一直是坏的。4. 部署验证和日常维护里的高频翻车点4.1 验证 OpenClaw 真的“活”了健康检查、日志和测试任务部署完成后不要急着把地址发给同事。先把健康检查接口摸一下。OpenClaw 通常会提供一个健康检查端点可以这样验证curl -fsS http://127.0.0.1:8080/healthz如果服务正常这个命令会返回一个 JSON 或纯文本的状态信息比如{status:ok}。如果连接失败先确认进程存在systemctl status openclaw journalctl -u openclaw -n 50 --no-pagerjournalctl 能看到服务启动时打出的日志。如果服务没有正常启动多半是环境变量文件没读对、二进制文件没执行权限、或者监听端口被占用。健康检查通过后创建一个最小测试任务。OpenClaw 的 API 通常支持提交一个简单命令任务比如echo hello。提交后观察任务状态和返回结果确认执行器能正常工作。这里的经验是测试任务要用真实的业务脚本而不是永远只跑 echo。把脚本逻辑、日志位置、环境变量都一并验证一遍才能提前发现权限缺失或路径写死的问题。4.2 安全组改坏了连不上一个恢复实例连接的经验我早期在调整安全组时动手改错过一次不小心删掉了 SSH 的入站规则实例直接失联。当时第一反应是惊慌担心需要销毁重建。实际 AWS 给了足够的恢复余地。正确的恢复步骤是打开实例控制台先停止实例。停止不会影响 EBS 数据卷只是操作系统会关机然后在实例详情页进入“网络”或“安全”标签找到修改安全组的入口添加回原来的 SSH 规则重新启动实例后SSH 就恢复了。这个过程的要点是安全组属于实例的网络属性可以直接修改不需要进入系统内部。所以即使你把 SSH 规则设置错误只要还有控制台权限就能把规则改回来。反过来如果你发现自己没有控制台权限或 IAM 权限不够那就真的需要找管理员了。因此在日常操作中给运维账号保留修改安全组的权限其实也是应急链路的一部分。4.3 磁盘耗尽、系统时间偏移和小文件太多这些“慢刀子”问题翻车最频繁的不是服务本身而是一些看似不相关的底层问题。磁盘耗尽是我遇到最多的情况。OpenClaw 执行任务时会产生很多临时输出如果不定期清理日积月累很容易占满根卷。判断方式有两个命令一个看空间一个看索引节点df -h df -idf -h显示磁盘剩余空间df -i显示的是 inode 占用。inode 是什么意思你可以粗略理解为文件系统里记录每个文件元数据的索引槽位。如果文件数量特别多即使磁盘空间还有剩余inode 用完了也会报“No space left on device”。OpenClaw 如果产生大量小文件很容易触发这个问题。我的建议是临时目录和任务产物目录尽量挂一个定时清理任务。系统时间偏移是一个隐蔽问题。EC2 默认使用时间同步服务但有些自定义 AMI 会关闭时间同步时间一旦漂移OpenClaw 的任务调度时间会变得不准确。确认办法是查看当前时间再跟标准时间对比。配置 systemd 的 chrony 服务并设为开机自启这是几分钟就能解决的事。5. 简化版跑稳之后再往前走低成本升级路径5.1 添加备用节点让我可以睡个好觉当单节点跑了一段时间后你会开始担心“万一实例挂了怎么办”。其实低成本的高可用思路不需要一开始就上负载均衡器而是可以准备一台备用节点。备份策略还是沿用前面的 S3 同步然后在另一台 EC2 上部署一套相同的 OpenClaw 环境。备用节点平时不接收公网请求只是定时从备份中同步数据。当主力节点出现故障时你只需要把 DNS 记录切到备用节点的 IP。注意在 DNS 里把 TTL 调低比如 60 秒这样切换生效会比较快。这种方案的优点是不需要引入负载均衡器和共享文件系统日常成本只有备用节点的付费费用。如果你需要在故障时尽快切换备用节点不要停止让它保持运行只是不对外接入流量。5.2 数据库替换成托管数据库存储换成 EFS 或 S3如果团队后续开始使用多个节点或者需要同时处理大量任务SQLite 会成为瓶颈。这时候再考虑把 SQLite 替换成 PostgreSQL 之类的数据库。OpenClaw 通常支持通过环境变量直接切换数据库连接比如OPENCLAW_DATABASE_URLpostgresql://openclaw:密码数据库主机:5432/openclaw配置变更之后要执行一次数据迁移命令把 SQLite 里的历史数据导入新数据库。替换数据库这一步建议在维护窗口期进行提前做一次完整备份迁移完成后立刻跑一遍关键测试任务。当多节点需要共享执行产物或配置文件时可以把数据目录迁移到 EFS。EFS 能让多台实例同时挂载同一个文件系统避免了每个节点各自一份数据带来的不一致。不过要注意如果数据库还在简化版单写模式下运行共享文件加上数据库同时访问的场景务必先经过测试不能拍脑袋上线。5.3 先别急着引入 CloudFront 或 API 网关很多人一看到“生产环境”立刻想把 CloudFront、API 网关、WAF 全部加上。我的建议是这个阶段先别动。OpenClaw 本身就是内部任务调度流量模式是低频 API 加定时任务并不是高并发网站。直连弹性 IP 在没有流量入口防护的场景下并不会成为性能瓶颈相反每多一层网关就多一层配置和故障排查的复杂度。如果你确实有安全方面的需求比如这个 API 要被外部调用建议先做两件事改用 HTTPS让前端的 ALB 终止 SSL 证书再通过安全组限制来源 IP。这两件事成本低、效果好而且不会引入新的服务端组件。等业务规模真的大到需要限流、地域封禁、缓存加速时再引入网关也完全不迟。6. 用了一个多月后我想给同样部署的人说的三句话第一句不要因为官方文档架构图复杂就以为自己的部署不够完整。简化部署也是一种架构选择只要边界清晰该有的安全组、IAM、日志轮转、定时备份一项不少它就是一个可靠的生产方案。第二句定时任务最可怕的不是任务失败而是任务失败后没人知道。我后来给 OpenClaw 配了一个外部监控每五分钟探测一次健康检查接口连续失败三次就向团队发通知。这一条比任何技术优化都让人安心。第三句备份和恢复演练永远不要在事故当天第一次做。我吃过一次亏备份脚本每天都在执行S3 里的文件看起来也都在但真正尝试用这些文件恢复时才发现有一个子目录一直没权限读取。后来我把“从备份恢复”也加进了每月的运维清单再也没在这种事上踩过第二次。这套部署路线不是银弹但如果你也打算在 AWS 上把 OpenClaw 跑起来而且业务规模暂时不需要多云和集群编排它至少能帮你避开我走过的那些弯路。