企业官网建设流程全解析

最近帮人折腾OpenClaw的云端部署，发现一个普遍误区：以为在本地电脑把代码跑起来就算完事。OpenClaw这类打工神器，真正的价值是7x24小时在线干活——你下班了它还在盯着定时任务，你手机关机了它还能给你汇总报告。而要做到这点，把OpenClaw部署到云服务器上几乎是唯一靠谱的方案。这篇就以国内主流云厂商为例，写一份从选服务器、配环境、跑通服务到日常维护的保姆级教程。适合刚接触云计算、想用OpenClaw替代重复劳动的朋友，也适合那些已经把OpenClaw跑在本地但还没迁移上云的人。

1. 为什么非要把OpenClaw放云端，本地跑不行吗

先说个我自己的经历。最早我也图省事，直接在笔记本电脑上用Docker跑OpenClaw，配了几个定时任务：每天早上汇总待办、每两小时巡检一下几个服务的状态。第一天很顺利，第二天早上起来发现任务全断了。查了半天，原因特别蠢——笔记本晚上合盖休眠，进程被杀。

这就是本地部署的硬伤：电脑不能关机、不能睡眠、不能带出门，Wi-Fi断了也不行。你想想，打工神器的卖点就是自动干活，结果它跟着你的作息一起休息，那和手动做有什么区别。

1.1 云端和本地到底差在哪

我做了一张对比表，大家感受一下：

说白了，OpenClaw这种工具，本地跑只是"试用"，云端跑才是"上岗"。特别是它接了大模型能力之后，很多场景是定时触发或者被动响应——你不可能为了等一个定时任务永远不关电脑。

1.2 什么人最适合直接上云

如果你符合下面任意一条，别犹豫，直接按这篇教程上云：

• 想用OpenClaw做定时信息汇总、日报生成、网页内容监控
• 想把OpenClaw的能力暴露给团队其他成员共用
• 正在做个人自动化工作流，希望从手机或另一台电脑随时触发任务
• 本地内存小，跑一个OpenClaw就把开发环境挤没了

这套教程走完之后，你得到的不是一个"能跑"的OpenClaw，而是一个"能一直跑"的OpenClaw。

2. 服务器选型：2核4G够不够，轻量服务器还是云主机

很多人第一步就卡在选配置上。其实OpenClaw本身不是一个吃资源的大胖子——它更像一个调度中枢，真正重的计算都丢给大模型API了。所以服务器的核心任务就是：稳定地跑着一个常驻进程，偶尔处理一下请求。

2.1 配置建议直接抄

我经手的代理商订单比较多，大部分人的需求用下面这个配置就能稳稳扛住：

选轻量应用服务器还是云主机（ECS）？我的建议是：个人用选轻量应用服务器，它自带防火墙规则、镜像市场里也有现成的运行环境，操作门槛低很多。如果你后续要做复杂的网络配置、自定义路由、多服务编排，那就上云主机，灵活性更高。

2.2 购买时最容易忽略的四个细节

• 地域别乱选，就选离你常用网络最近的节点。国内访问国内节点延迟低，如果你有海外业务再说海外节点的事，但注意合规。
• 带宽别贪大。OpenClaw传输的主要是文本和接口请求，5M带宽个人用很宽裕。带宽是长期成本的大头，选大带宽纯属浪费。
• 公网IP一定要有。没有公网IP，你后面访问服务、配置webhook都要绕路，非常痛苦。
• 登录方式建议选密钥对。虽然密码也能用，但云服务器每天被扫描爆破是常态，密钥登录安全得多，后面我会讲具体配置。

2.3 关于代理商和渠道的一点大实话

很多人问我，从代理商买和自己官网买有什么区别。说实话，如果你是自己用一台两台，官网直接买就行；如果是公司采购、要开票、要长期折扣、要代金券规划，代理商渠道的优势才会体现出来——价格弹性、赠费额度、工单响应优先级都不一样。但无论从哪买，服务器本身没有任何区别，别为"代理商定制版"这种说法多花冤枉钱，服务器硬件和系统都是标准化的。

3. 环境准备：从SSH登录到装好运行环境

服务器到手后第一件事不是急着部署OpenClaw，而是把基础环境收拾利索。这个阶段做扎实了，后面能少踩一半的坑。

3.1 用SSH密钥登录，不要再用密码

打开本地终端，先生成一对密钥：

ssh-keygen -t ed25519 -C "openclaw-server"

一路回车即可，默认会生成在~/.ssh/目录下。然后把公钥传到服务器上：

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@你的服务器公网IP

如果是第一次登录，它会提示输入root密码。传完之后测试一下：

ssh root@你的服务器公网IP

如果不需要密码就能进去，说明密钥登录已经生效。此时建议修改ssh配置文件，禁用密码登录：

sudo vim /etc/ssh/sshd_config

找到PasswordAuthentication，改成：

PasswordAuthentication no

然后重启ssh服务：

sudo systemctl restart sshd

做了这一步，服务器被暴力破解的风险直接下降一个数量级。注意：在确认密钥能登录之前，千万别关密码登录，不然把自己锁在外面就尴尬了。

3.2 系统更新和基础工具

登录之后，先把系统更新到最新：

sudo apt update && sudo apt upgrade -y

我用的是Ubuntu 22.04 LTS作为示例，Debian系的操作基本一致。接着装基础工具：

sudo apt install -y git curl wget vim ufw build-essential

有些云厂商的镜像默认很精简，连git都没有，这步不能省。

3.3 安装Docker和Docker Compose

OpenClaw的部署方式我最推荐Docker Compose，理由后面细说。装Docker官方推荐的方式是走软件源：

curl -fsSL https://get.docker.com | bash -s docker

国内服务器如果下载慢，可以配置镜像加速器，这个云厂商控制台一般都有指引，照着填就行。装完启动服务：

sudo systemctl enable --now docker

确认是否成功：

sudo docker run --rm hello-world

看到Hello from Docker!就说明成了。还要检查一下Compose插件是否装好：

docker compose version

没有的话单独装一下：

sudo apt install -y docker-compose-plugin

3.4 配置防火墙：先开22，再开80和443

我用ufw做防火墙管理，规则很简单：

sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable

注意：如果你后面要用容器端口（比如8080），不要直接放行8080，而是让Docker映射到指定端口后，再在云厂商控制台的安全组里放行。云厂商的"安全组"是外层的，服务器里ufw是内层的，两层都要设置对，否则会出现"端口明明开着却连不上"的假象，后面踩坑实录会详细讲。

4. OpenClaw部署全流程：拉取代码、配置密钥、启动服务

环境准备好之后，开始正式部署。我在这一步会讲两套方案：Docker Compose方式（推荐）和直接Python运行方式（备用），你选一种就行。

4.1 准备项目目录

先把OpenClaw放在一个规范的位置，不要随便丢在root家目录。我习惯的布局是这样的：

sudo mkdir -p /opt/openclaw sudo chown -R $USER:$USER /opt/openclaw cd /opt/openclaw

用普通用户操作，别用root直接跑服务，后面权限和权限粒度都更好控制。

4.2 拉取项目代码

从项目的官方代码仓库拉取最新版本：

git clone <OpenClaw项目的仓库地址> .

如果已经有旧版本，可以先pull一下再继续。拉到之后看看目录结构，通常会有.env.example文件，复制一份作为真实配置：

cp .env.example .env vim .env

4.3 配置环境变量：API密钥和密钥类信息必须放这里

这个.env文件非常重要。OpenClaw要接大模型服务才能干活，你需要准备好对应服务商的API Key，填到配置里。典型配置项长这样：

OPENCLAW_API_KEY=你的访问口令 LLM_API_KEY=你的大模型服务商密钥 LLM_BASE_URL=https://api.你的服务商.com/v1 LLM_MODEL=你的模型名称 TZ=Asia/Shanghai

两个"密钥"的含义完全不同，别搞混了：

• OPENCLAW_API_KEY是你访问OpenClaw自己接口时的口令，等于给这个打工神器加一道门禁。
• LLM_API_KEY是OpenClaw去调用大模型时用的凭证，这串要是泄露了，别人能拿你的额度刷爆账单。

所以，几个安全习惯从第一天就要养成：.env文件不要提交到git仓库；.env的权限设为600；不要在任何客户端或截图里暴露真实的密钥值。

4.4 Docker Compose方式启动（推荐）

在项目根目录一般会有docker-compose.yml文件，如果没有就自己建一个。典型的做法是把OpenClaw主服务和一个轻量级数据库服务编排在一起。我只写核心框架：

version: "3.8" services: openclaw: image: <OpenClaw项目提供的镜像地址> container_name: openclaw restart: unless-stopped env_file: - .env ports: - "8080:8080" volumes: - ./data:/app/data - ./logs:/app/logs

检查一下端口映射：左边是宿主机端口，右边是容器内端口。如果你服务器8080被别的程序占了，就改成8081:8080，但记住你改了哪个端口，后面防火墙和安全组要一致。

启动服务：

docker compose up -d

看日志确认启动状态：

docker compose logs -f --tail 100

等日志稳定后，用健康检查接口验证：

curl http://localhost:8080/health

返回正常状态码就说明跑起来了。

4.5 systemd方式托管（备用方案）

如果你不想用Docker，直接用Python跑OpenClaw也可以。先建虚拟环境：

python3 -m venv venv source venv/bin/activate pip install -r requirements.txt

然后配置一个systemd服务，让它开机自启、崩溃自动重启。创建/etc/systemd/system/openclaw.service：

[Unit] Description=OpenClaw Service After=network-online.target Wants=network-online.target [Service] User=你的用户名 WorkingDirectory=/opt/openclaw ExecStart=/opt/openclaw/venv/bin/python /opt/openclaw/main.py Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

启动并设置开机自启：

sudo systemctl daemon-reload sudo systemctl enable --now openclaw

为什么我更推荐Docker Compose？因为升级、回滚、迁移都方便。docker compose up -d一条命令重建整个堆栈，日志有统一的查看方式，数据目录也隔离得清楚。systemd方式更轻量，但升级时依赖管理容易出问题。个人选择是：单机简单场景用systemd，想省心用Docker，各有各的好。

5. 把打工神器调到顺手：核心配置与任务编排

服务跑起来只是第一步。真正让它变成"打工神器"，靠的是后面的配置和任务编排。

5.1 理解配置文件的逻辑

OpenClaw的配置文件一般是一个config.yaml或者网页管理界面。核心就两件事：告诉它"你能调哪些能力"、"你按什么规则干活"。

我自己的配置一般包含这么几块：

5.2 接入大模型服务的参数调优

假设你选了一家主流大模型服务商，在.env里配置好之后，模型调用的参数也会影响打工效果。下面是我试出来的通用推荐值：

如果你的任务涉及代码生成和处理JSON，temperature可以再降一点；如果是闲聊类的任务，才需要调高。

5.3 定时任务：别只写cron，要先验证再上线

定时任务是打工神器最香的能力。我常用几个cron例子：

• 每天早上9点生成待办清单：0 9 * * *
• 每周五下午5点生成周报初稿：0 17 * * 5
• 每小时检查一次指定网页内容变化：0 * * * *
• 每十分钟汇总一次IM群里的关键词消息：*/10 * * * *

在正式启用前，建议先手动执行一遍任务，确认它能拿到数据、调用模型、推送消息。如果手动执行都失败，挂到cron上只会更糟。

5.4 把结果推给谁：配置Webhook通知

OpenClaw干完活，怎么把结果送到你手上？最实用的方式是配置办公IM的群机器人Webhook。在群里加一个自定义机器人，拿到Webhook地址，填到OpenClaw的通知配置里。这样任务执行完，报告直接推到群里，手机上就能看。

这一步有两个容易踩的细节：

• Webhook地址要填完整的URL，有些平台要求拼接关键词，漏了会推送失败。
• 推送内容别太长，IM机器人有消息长度限制，几千字的报告截断前先做个摘要。

5.5 公网访问的安全底线

如果OpenClaw的Web界面要暴露在公网上，最低限度要做三件事：

• 启用认证：给Web界面配一个强密码或API Key，禁止无认证访问。
• 限制来源：在安全组里把8080端口的来源IP限制到你的办公IP。宁可多配置几步，也不要全公网开放。
• 不要裸奔HTTP：有域名的话做一层HTTPS。证书申请可以用免费的证书工具，配置很简单，但能避免数据在传输途中被窥探。

我自己在给客户部署时，凡是涉及API Key存储的任务，一律要求启用密钥管理，至少也要把.env的权限锁死。打工神器越能干，被拿到权限的后果越严重，这句话记住就够。

6. 部署后绕不开的维护：日志、备份、升级与监控

很多教程在"服务跑起来"就结束，但真实的生产环境里，维护才是大头。OpenClaw跑一两天没问题，跑一两个月就什么奇怪问题都能遇到。

6.1 看日志是第一个技能

无论用Docker还是systemd，日志都是排障的第一现场。

Docker方式：

docker logs -f --tail 200 openclaw

systemd方式：

journalctl -u openclaw -f -n 200

看到报错不要慌，先看关键词。最常出现的三类：

• 调用大模型超时/限流：检查API额度、模型名是否有效。
• 任务执行报错：看是权限问题还是数据格式问题，多半是配置没配对。
• 内存被kill：dmesg | grep -i oom一看便知，下面会讲swap方案。

6.2 数据备份：别等丢数据才后悔

OpenClaw跑久了，里面会积累任务历史、会话记录、配置偏好。这些数据比你想象的值钱。至少备份两个东西：.env配置文件和data目录里的数据。

我每天凌晨3点自动打包备份到独立目录：

tar -czf /backups/openclaw-$(date +\%Y\%m\%d).tar.gz -C /opt/openclaw data .env

用crontab挂上：

0 3 * * * tar -czf /backups/openclaw-$(date +\%Y\%m\%d).tar.gz -C /opt/openclaw data .env

保留最近7天的备份就够，再久远的意义不大。真出问题的时候，能找回前一天的就是救命稻草。

6.3 升级的正确姿势

OpenClaw迭代速度不慢，不建议天天追最新版，但也不要几个月不升。我的升级流程：

cd /opt/openclaw docker compose down git pull docker compose build --pull docker compose up -d

等一下，这里有个细节：docker compose down会停掉服务，数据目录如果做了volume映射就不会丢。升级之前务必先备份数据，然后看一眼更新日志——有些版本改动配置文件格式，不兼容的字段会导致启动失败。

万一启动失败怎么回滚？如果你用的是镜像版本，把旧镜像的tag重新指定即可。所以我会在升级前记录当前镜像tag：

docker compose images

把这个输出存下来，回滚时改回来就行。

6.4 最简单的资源监控

不需要上什么重量级监控系统。个人服务器，我每周偶尔看一眼基础指标就够了：

uptime free -h df -h docker stats --no-stream

uptime看负载，free -h看内存，df -h看磁盘，docker stats看容器实际占用。如果看到内存长期在80%以上，可以考虑加swap或升级配置。磁盘尽量不要超过70%，日志文件是隐藏的磁盘杀手，定时清一下：

truncate -s 0 /opt/openclaw/logs/*.log

7. 踩坑实录：先别急着找客服，看看这几个常见问题

这一节全是实战中反复遇到的坑，不少是"重装系统都解决不了"的隐蔽问题。

7.1 端口明明映射了，公网却访问不了

症状：容器已启动，curl localhost:8080正常，但从外部浏览器打不开。

排查链路：先查服务器内ufw状态：

sudo ufw status verbose

看看8080是不是被deny了。再用云厂商控制台查安全组规则——很多新手只设了服务器内防火墙，忘记在控制台的"安全组"里放行对应端口。

这个坑的本质是：云服务器的网络流量会先过安全组，再到操作系统防火墙，最后才到容器。三层链路各管各的，任何一层没放行，外部都进不来。正确做法是：先设安全组放行，再设ufw，两边保持一致。我一般把容器端口不直接暴露，而是通过反向代理走80/443，这样安全组只需要放行80和443，端口管理简单很多。

7.2 进程无缘无故被杀

症状：OpenClaw跑了一天突然挂掉，docker ps里看不到容器，日志也没报错。

多半是内存不足。OpenClaw常驻进程本身不重，但Docker和日志叠加后，2G内存很容易告急。系统OOM killer会优先杀常驻进程。

两个解法：

• 加swap文件，给内存兜底。4G内存的机器开2G swap比较合理：

sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

要永久生效，在/etc/fstab里加一行：

/swapfile none swap sw 0 0

• 限制Docker容器内存，别让它吃光宿主资源。在compose文件里加：

mem_limit: 1g

容器内存超了会被重启而不是拖垮整个服务器，长期跑更稳。

7.3 定时任务时间不对，晚了8个小时

症状：设置了早上9点的任务，结果下午5点才执行。

原因几乎总是时区问题。云服务器默认时区是UTC，容器里更是如此。你写0 9 * * *，它按UTC执行，对应国内时间就是下午5点。

解决方案：

• 宿主机设置时区：sudo timedatectl set-timezone Asia/Shanghai
• 容器设置时区：在.env里加TZ=Asia/Shanghai
• 如果compose里的镜像不支持TZ变量，就在compose的environment里显式注入。

验证是否生效：

date docker exec openclaw date

两个时间一致就对了。

7.4 docker命令要加sudo，很烦怎么办

把当前用户加入docker组：

sudo usermod -aG docker $USER

然后退出重进shell，或者newgrp docker。注意：加入docker组等同于给了这个用户接近root的权限，所以只建议在个人服务器上这么操作。

7.5 配置改错了，启动直接失败

改配置文件时永远先备份：

cp config.yaml config.yaml.bak

启动失败时不要慌，先查配置是否有语法错误：

docker compose config --quiet

这条命令会校验compose文件的合法性。如果错误出在OpenClaw自身的配置文件，通常日志里会明确提示哪一行、哪个字段出了问题。改回来，用备份还原，再启动就好。我吃过几次亏之后养成的习惯：每次改配置，先备份，再运行，再观察日志，改完顺手记一笔变更说明，这个习惯能省很多时间。

7.6 升级后老配置失效

版本迭代时配置字段改名是最常见的情况。升级前先看更新日志；升级后如果启动失败，优先检查是否有配置迁移工具——很多项目提供了migrate命令或者一键转换脚本，运行一遍能省掉手工猜字段的麻烦。实在没有，就用老版本镜像先回滚，把自己从焦虑里捞出来。

最后再分享一个实用小技巧

部署OpenClaw跑通只是起点。我现在的做法是：在服务器上挂一个极简的定期巡检脚本，检查OpenClaw容器是否正常、磁盘是否告急、任务是否有异常报错，一旦发现问题就推送到群里。这套机制和OpenClaw本身的自动化理念是一脉相承的——让工具之间互相盯着，而不是人肉盯着工具。

我的体会是，一个打工神器能不能真正解放你，不在于功能的多少，而在于你敢不敢把"最重要的事情"交给它，并且给了它足够的兜底。今天这份保姆级教程，已经帮你把云上部署的最关键路径走完了；后续你可以根据自己的场景，慢慢把更多任务交给它。折腾的过程会踩坑，但每解决一个坑，这台服务器就变得更"懂事"一分。