存储大脑：
Synology NAS OpenClaw 设置
/** 将智能带到数据所在的地方。 */
如果您有 4 盘位以上的 Synology（DS923+ 或 DS1522+），您就拥有一台常开的 AMD Ryzen 服务器。直接在 NAS 上运行 OpenClaw 意味着通过本地卷挂载读取您的 PB 级 PDF 和文档时零延迟。
1. 必须升级内存
大多数 Synology NAS 出厂只有 4GB 或 8GB ECC RAM，仅够运行 DSM 本身。升级内存是必须的。
- 购买兼容的无缓冲 ECC DDR4 SODIMM 内存（例如 2×16GB 镁光或金士顿）。
- 关闭 NAS，取出硬盘托架，在主板插槽上安装新内存。
- 开机并在 DSM 控制面板 → 信息中心中验证新的 32GB 容量。
2. 设置 Container Manager
- 在 DSM 中打开套件中心。
- 搜索并安装 Container Manager（原 Docker）。
- 在 /volume1/docker 内创建名为 openclaw 的子文件夹。
- 在 openclaw 内创建两个子文件夹：data 和 ollama_models。
3. 部署 Compose 项目
在 Container Manager 中新建一个 Project 来编排 OpenClaw 和 Ollama。
Synology 防火墙注意事项
绝对不要通过路由器端口转发将 3000 端口直接暴露到公网。始终使用深度身份验证的反向代理（Cloudflare Zero Trust Tunnels 或 Tailscale）来远程访问 OpenClaw。
先查你的型号，别的都往后
Synology 不是一个统一平台。入门级 ARM 机型和 x86 Plus 系列之间的差距，就是「这件事很直接」和「这件事做不了」的差距，而且没有任何配置能弥补它。
| 你的机器 | Container Manager | 对本文意味着什么 |
|---|---|---|
| x86_64（Plus、XS，以及多数 DS-x20+ 及更新型号） | 可用 | compose 能用，本文按原样适用。 |
| 较新 DSM 上的部分 ARMv8 机型 | 可用 | 能跑，但这些是低功耗 CPU。预期只跑网关，模型放在别处。 |
| 较老的入门 ARM 机型（J 系列等） | 不可用 | 装不了 Container Manager。本页所有内容都帮不上忙，见文末的替代方案。 |
Synology 在这件事上是有变化的——一些以前跑不了容器的 ARMv8 机型，在当前 DSM 上已经可以了。请在实机的套件中心里查，而不是相信你在某个论坛帖子里找到的兼容性列表，也包括本文这张表。
先搞清楚这台硬件到底能给你什么
NAS 是为了把字节从硬盘搬出去而设计的，不是为了做算术。即使是受支持的 x86 机型，CPU 通常也是一颗低 TDP 的芯片，还要和 DSM 自己的索引、快照，以及你已经跑着的一堆东西共享。在围绕它做规划之前，先弄清楚真正空闲的有多少。
# SSH into the NAS and find out what you are actually working with:
uname -m # x86_64 → Container Manager is available
# aarch64 → depends on the model; check Package Center
nproc # how many cores you have to share
free -h # how much RAM is left after DSM takes its share如果 `free -h` 显示在 DSM 和你现有容器之后已经所剩无几，那再塞一个语言模型进去不会有好结果。网关本身很轻，本地模型不是。
# Package Center → search "Container Manager" # If it does not appear, your unit cannot run it. Stop here and # read the alternative at the bottom of this page.
这是一个二值答案，而它决定了这个项目余下的一切。唯一可靠的验证方式是在实机的套件中心里搜一下。
写 compose，以及那个会静默失败的 CPU 限制
有两个细节决定了容器是「能用」还是「半残」。两个都是群晖特有的，而且从 OpenClaw 的文档里都看不出来。
services:
openclaw:
image: ghcr.io/openclaw/openclaw:latest
restart: unless-stopped
volumes:
# Mount state as a DIRECTORY. Never as a single file.
- /volume1/docker/openclaw:/home/node/.openclaw
- /volume1/docker/openclaw/workspace:/home/node/.openclaw/workspace
ports:
# Bound to loopback: reach it over the NAS's own VPN or an SSH
# tunnel, never by opening 18789 on the router.
- "127.0.0.1:18789:18789"文档明确要求网关状态必须挂成目录而不是单个文件。关于端口绑定：NAS 往往是一个家庭里唯一一台已经做过端口转发的机器，这恰恰使它成为最不该随手暴露 Agent 端点的地方。
# This will NOT work on a Synology kernel: # # deploy: # resources: # limits: # cpus: "1.5" # # You get: "NanoCPUs can not be set, as your kernel does not support # CPU CFS scheduler or the cgroup is not mounted" # # Use Container Manager's CPU priority (low/mid/high) instead. # It is a priority, not a cap — a busy container will still take # whatever is idle.
群晖的内核没有编入 CPU CFS 调度器的 cgroup，所以 compose 里限制 CPU 的标准写法会直接报错失败。可用的替代是 Container Manager 里的 CPU 优先级设置，而它是一个调度提示而不是上限——繁忙的容器仍然会吃掉空闲算力。
什么时候 NAS 是错的宿主
- ✗你想让模型也跑在 NAS 上。除非那是一台内存确实有富余的高端 x86 机型，否则让它去调用跑在别处的模型。
- ✗你的机器装不了 Container Manager。把网关跑在树莓派或小主机上，再让它通过 SMB 挂载 NAS 的共享——存储的好处照拿，不用跟平台硬碰。
- ✗你依赖这台 NAS 做备份，希望它别被打扰。一个对备份目标有写权限的 Agent 是个糟糕的结构，无论它表现得多好。
- ✗你原本指望限制它的 CPU 以免影响 DSM。这个控制并不以你预期的形式存在，所以要预留出「容器偶尔会和 NAS 的本职工作抢资源」的余地。