Hermes Agent Docker 部署：用官方 compose 文件跑通 Gateway 与仪表盘

为什么 Docker 路线值得考虑

官方仓库自带 Dockerfile 和 docker-compose.yml，镜像里把 Python 3.13、Node 22、ripgrep、ffmpeg、git 和 Playwright 浏览器全部预装好，宿主机只需要 Docker 本身。它适合两类人：服务器上不想污染系统环境的，以及本机依赖冲突反复装不好的。

一条命令拉起：compose 的默认拓扑

git clone https://github.com/NousResearch/hermes-agent.git
cd hermes-agent
HERMES_UID=$(id -u) HERMES_GID=$(id -g) docker compose up -d

compose 定义了两个服务：gateway 容器以 `gateway run` 前台模式承载消息入口，dashboard 容器提供 Web 仪表盘。HERMES_UID 和 HERMES_GID 把容器内用户重映射成宿主机用户，保证挂载目录里新建的文件在宿主机上仍然可读写——这是很多容器部署忽略的文件归属问题，官方直接在启动钩子里处理掉了。

数据全部落在宿主机的 ~/.hermes

两个容器都把宿主机 ~/.hermes 挂载到容器内 /opt/data。这意味着三件事：备份容器部署等于备份 ~/.hermes 一个目录；容器删了重建，配置、密钥、会话历史和记忆都还在；直接在宿主机上改 ~/.hermes/config.yaml 和 ~/.hermes/.env 同样生效。

仪表盘只绑 127.0.0.1，远程访问走 SSH 隧道

dashboard 服务默认只监听本机回环地址，因为它保存着 API Key。远程查看的正确方式是 SSH 隧道：

ssh -L 9119:localhost:9119 user@your-vps

官方注释明确警告：不要用 --insecure --host 0.0.0.0 把它暴露到局域网或公网。同理，OpenAI 兼容 API server 默认关闭，只有同时设置 API_SERVER_HOST 和 API_SERVER_KEY 两个环境变量才会启用。

进程监管交给 s6-overlay

容器的 PID 1 是 s6-overlay 的 /init，它负责权限重映射、初始化脚本和进程监管：主进程、dashboard、各 profile 的 gateway 都在监管树里，僵尸进程也由它回收。如果要自定义 entrypoint，必须把 /init 保留在命令链第一位，否则初始化全部跳过，gateway 无法正常工作。配合 restart: unless-stopped，宿主机重启后整套服务自动拉起。

Windows 宿主机

仓库里另有 docker-compose.windows.yml，Windows 上跑 Docker Desktop 的用户用它替换默认 compose 文件即可，不需要自己改 volume 路径写法。

还没有真实场景？可以先领取 [Free Starter 模板包](/free-template-pack)，从低风险只读任务开始试跑。