Hermes WebUI 多容器部署:一条命令跑通聊天加监控【免费下载链接】hermes-webuiHermes WebUI: The best way to use Hermes Agent from the web or from your phone!项目地址: https://gitcode.com/GitHub_Trending/he/hermes-webuiHermes WebUI 是 Hermes Agent 的浏览器端界面,把 Agent 从终端和 IM 延伸到网页与手机。默认单容器配置只覆盖聊天场景;当你想要独立监控面板、或希望定时任务在离线时照常触发,Hermes WebUI 多容器部署是更完整的形态。本文带你用仓库自带的三容器 Compose 文件一次拉起 Agent、WebUI、Dashboard,跑通访问并掌握日常调整。为什么选三容器这套方案仓库里有三个 Compose 文件,单容器最省事,三容器最完整,差异集中在故障域和定时任务两点:方案聊天离线定时任务监控面板单容器docker-compose.yml支持需另行常驻 gateway无两容器docker-compose.two-container.yml支持支持无三容器docker-compose.three-container.yml支持支持独立 Dashboard,端口 9119Dashboard 是独立容器独立端口,监控卡了单独重启,不会拖垮聊天。gateway 以独立守护进程运行,cron 任务离线时照样触发并投递结果。资源上限按容器切分:Agent 限 4G 内存 / 2 核,Dashboard 仅 512M / 0.5 核,互不抢占。部署前检查这 5 件事Docker Engine 20.10——验证:docker --versionDocker Compose v2——验证:docker compose version(带 compose 子命令的插件形态)至少 4GB 可用内存——Agent 容器上限就是 4G,验证:free -h至少 10GB 可用磁盘——要放两个镜像和两个数据卷,验证:df -h .端口 8787 / 9119 / 8642 空闲——验证:ss -tlnp | grep -E 8787|9119|8642,无输出即正常整套 Hermes WebUI docker compose 配置都在仓库根目录,确认上面 5 条后就可以开拉了。跑通 Hermes WebUI 多容器部署最小环境先克隆仓库,Compose 文件、启动脚本都在根目录:git clone https://gitcode.com/GitHub_Trending/he/hermes-webui cd hermes-webui这一步只是取配置,真正的运行体是三个公开镜像。然后指定三容器文件启动:docker compose -f docker-compose.three-container.yml up -d docker compose -f docker-compose.three-container.yml ps首次运行会拉取hermes-agent和hermes-webui两个镜像,耗时取决于网速;ps里三个服务最终都应显示 Up。接着探一下 WebUI 是否真的活着:curl -s http://127.0.0.1:8787/health返回正常的状态 JSON 即代表接口就绪。浏览器打开 http://localhost:8787 进入聊天,http://localhost:9119 进入监控。默认界面是三栏布局:左侧会话列表、中间聊天区、右侧工作区文件树:理清三个容器之间的依赖与数据流三个容器都在hermes-net这个 bridge 网络里,服务名可以直接当主机名互访:hermes-agent:执行gateway run,gateway API 监听 8642(默认仅绑定回环),负责 CLI、IM 接入和 cron 调度,是另外两个服务的数据源。hermes-webui:聊天界面,端口 8787,depends_on: hermes-agent。聊天本身在 WebUI 容器内进程内执行,但健康探测和定时任务面板会通过HERMES_API_URLhttp://hermes-agent:8642去够 gateway。hermes-dashboard:复用 Agent 镜像执行dashboard --insecure,端口 9119,depends_on: hermes-agent,通过GATEWAY_HEALTH_URLhttp://hermes-agent:8642拉取健康与会话数据。数据全部落在两个命名卷里,这是理解整套部署的关键:hermes-home:配置、会话、技能、记忆,三个容器共享挂载,是唯一的状态持久化位置,备份只备它。hermes-agent-src:首次up时从 Agent 镜像的/opt/hermes初始化,以只读方式挂进 WebUI 容器,只用于启动时安装 Agent 的 Python 依赖。Dashboard 服务的关键接线只有几行,能说明它和另外两个容器的关系:hermes-dashboard: image: nousresearch/hermes-agent:latest command: dashboard --host 0.0.0.0 --insecure ports: - ${HERMES_DASHBOARD_BIND:-127.0.0.1}:9119:9119 environment: - GATEWAY_HEALTH_URLhttp://hermes-agent:8642 depends_on: - hermes-agent也就是说 Dashboard 自己不落业务数据,读的是和 Agent 同一个 hermes-home,再向 gateway 要实时指标。打开 9119 端口,你能看到 CPU、内存、磁盘的实时资源快照:按需调整:三个常见自定义场景所有调整的节奏都一样:改.env或 compose 里的宿主路径,再up -d --force-recreate让容器重建生效。如果你不满意默认工作目录。WebUI 默认挂${HOME}/workspace,换成你自己的项目目录即可:echo HERMES_WORKSPACE$HOME/my-projects .env docker compose -f docker-compose.three-container.yml up -d --force-recreate重建后刷新页面,右侧工作区面板列出的就是新目录下的文件,支持在线预览、编辑和下载:如果文件权限乱了(尤其 macOS)。容器默认按 UID 1000 运行,而 macOS 用户 UID 从 501 起,写出的文件你在宿主机上可能读不了。把真实 UID/GID 写进.env:echo UID$(id -u) .env echo GID$(id -g) .env docker compose -f docker-compose.three-container.yml up -d --force-recreate如果要开放 gateway API 或远程访问。8642 端口只在设置了API_SERVER_KEY(至少 16 位)时才会打开;对外暴露 WebUI 时建议同时加访问密码:echo API_SERVER_KEY$(openssl rand -hex 16) .env echo HERMES_WEBUI_PASSWORDchange-me-strong .env docker compose -f docker-compose.three-container.yml up -d --force-recreate生效后 WebUI 的 Tasks/系统状态面板才会显示 gateway 在线;端口若要绑到 0.0.0.0,请配合反向代理或隧道做一层鉴权。出问题了这样排查现象:WebUI 提示 Hermes agent is not responding 或 gateway 不可达。原因:API_SERVER_KEY没设置或不足 16 位,8642 端口根本没打开。操作:按上一节写入 key 并重建容器,再确认宿主机上 8642 有监听。现象:容器启动即崩,日志里是PermissionError/permission denied。原因:宿主机 UID 和容器内 UID 不一致,常见于绑定挂载场景。操作:id -u查出宿主 UID,写入.env的UID/GID后重建;改用命名卷(默认)通常可绕开。现象:.env: permission denied(对应 issue #1389)。原因:WebUI 的凭据权限检查强制 0600,旧文件读不了。操作:在.env里加HERMES_SKIP_CHMOD1后重建。现象:容器起不来,报port is already allocated。原因:宿主 8787 / 9119 / 8642 被别的进程占用。操作:改 compose 文件ports里冒号左侧的宿主端口,容器侧端口保持不动。日常维护速查操作命令说明看日志docker logs hermes-agent(webui / dashboard 同理)排查启动与运行时错误全部停止docker compose -f docker-compose.three-container.yml down只停容器,数据卷保留升级镜像down→docker volume rm hermes-webui_hermes-agent-src→pull→up -d必须删 agent-src 卷,否则旧源码被原样复用备份数据见下方命令全部状态都在 hermes-home 卷里备份把共享卷打包出来,还原时反向挂载即可:docker run --rm -v hermes-webui_hermes-home:/source -v $(pwd):/backup alpine \ tar -czf /backup/hermes-backup.tar.gz -C /source .卷名前缀取决于 compose 项目名(默认就是目录名hermes-webui),不确定时先docker volume ls看一眼。进一步阅读docs/docker.md——官方 Docker 参考:三种 Compose 的完整对比、失败模式表和绑定挂载迁移步骤。ARCHITECTURE.md——后端/前端布局与状态目录结构,想弄清数据落在哪时看它。docs/troubleshooting.md——常见报错现象与对应修复的清单。docker-compose.two-container.yml——不带监控面板的变体,只需聊天加定时任务时对照参考。【免费下载链接】hermes-webuiHermes WebUI: The best way to use Hermes Agent from the web or from your phone!项目地址: https://gitcode.com/GitHub_Trending/he/hermes-webui创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hermes WebUI 多容器部署:一条命令跑通聊天加监控
Hermes WebUI 多容器部署:一条命令跑通聊天加监控【免费下载链接】hermes-webuiHermes WebUI: The best way to use Hermes Agent from the web or from your phone!项目地址: https://gitcode.com/GitHub_Trending/he/hermes-webuiHermes WebUI 是 Hermes Agent 的浏览器端界面,把 Agent 从终端和 IM 延伸到网页与手机。默认单容器配置只覆盖聊天场景;当你想要独立监控面板、或希望定时任务在离线时照常触发,Hermes WebUI 多容器部署是更完整的形态。本文带你用仓库自带的三容器 Compose 文件一次拉起 Agent、WebUI、Dashboard,跑通访问并掌握日常调整。为什么选三容器这套方案仓库里有三个 Compose 文件,单容器最省事,三容器最完整,差异集中在故障域和定时任务两点:方案聊天离线定时任务监控面板单容器docker-compose.yml支持需另行常驻 gateway无两容器docker-compose.two-container.yml支持支持无三容器docker-compose.three-container.yml支持支持独立 Dashboard,端口 9119Dashboard 是独立容器独立端口,监控卡了单独重启,不会拖垮聊天。gateway 以独立守护进程运行,cron 任务离线时照样触发并投递结果。资源上限按容器切分:Agent 限 4G 内存 / 2 核,Dashboard 仅 512M / 0.5 核,互不抢占。部署前检查这 5 件事Docker Engine 20.10——验证:docker --versionDocker Compose v2——验证:docker compose version(带 compose 子命令的插件形态)至少 4GB 可用内存——Agent 容器上限就是 4G,验证:free -h至少 10GB 可用磁盘——要放两个镜像和两个数据卷,验证:df -h .端口 8787 / 9119 / 8642 空闲——验证:ss -tlnp | grep -E 8787|9119|8642,无输出即正常整套 Hermes WebUI docker compose 配置都在仓库根目录,确认上面 5 条后就可以开拉了。跑通 Hermes WebUI 多容器部署最小环境先克隆仓库,Compose 文件、启动脚本都在根目录:git clone https://gitcode.com/GitHub_Trending/he/hermes-webui cd hermes-webui这一步只是取配置,真正的运行体是三个公开镜像。然后指定三容器文件启动:docker compose -f docker-compose.three-container.yml up -d docker compose -f docker-compose.three-container.yml ps首次运行会拉取hermes-agent和hermes-webui两个镜像,耗时取决于网速;ps里三个服务最终都应显示 Up。接着探一下 WebUI 是否真的活着:curl -s http://127.0.0.1:8787/health返回正常的状态 JSON 即代表接口就绪。浏览器打开 http://localhost:8787 进入聊天,http://localhost:9119 进入监控。默认界面是三栏布局:左侧会话列表、中间聊天区、右侧工作区文件树:理清三个容器之间的依赖与数据流三个容器都在hermes-net这个 bridge 网络里,服务名可以直接当主机名互访:hermes-agent:执行gateway run,gateway API 监听 8642(默认仅绑定回环),负责 CLI、IM 接入和 cron 调度,是另外两个服务的数据源。hermes-webui:聊天界面,端口 8787,depends_on: hermes-agent。聊天本身在 WebUI 容器内进程内执行,但健康探测和定时任务面板会通过HERMES_API_URLhttp://hermes-agent:8642去够 gateway。hermes-dashboard:复用 Agent 镜像执行dashboard --insecure,端口 9119,depends_on: hermes-agent,通过GATEWAY_HEALTH_URLhttp://hermes-agent:8642拉取健康与会话数据。数据全部落在两个命名卷里,这是理解整套部署的关键:hermes-home:配置、会话、技能、记忆,三个容器共享挂载,是唯一的状态持久化位置,备份只备它。hermes-agent-src:首次up时从 Agent 镜像的/opt/hermes初始化,以只读方式挂进 WebUI 容器,只用于启动时安装 Agent 的 Python 依赖。Dashboard 服务的关键接线只有几行,能说明它和另外两个容器的关系:hermes-dashboard: image: nousresearch/hermes-agent:latest command: dashboard --host 0.0.0.0 --insecure ports: - ${HERMES_DASHBOARD_BIND:-127.0.0.1}:9119:9119 environment: - GATEWAY_HEALTH_URLhttp://hermes-agent:8642 depends_on: - hermes-agent也就是说 Dashboard 自己不落业务数据,读的是和 Agent 同一个 hermes-home,再向 gateway 要实时指标。打开 9119 端口,你能看到 CPU、内存、磁盘的实时资源快照:按需调整:三个常见自定义场景所有调整的节奏都一样:改.env或 compose 里的宿主路径,再up -d --force-recreate让容器重建生效。如果你不满意默认工作目录。WebUI 默认挂${HOME}/workspace,换成你自己的项目目录即可:echo HERMES_WORKSPACE$HOME/my-projects .env docker compose -f docker-compose.three-container.yml up -d --force-recreate重建后刷新页面,右侧工作区面板列出的就是新目录下的文件,支持在线预览、编辑和下载:如果文件权限乱了(尤其 macOS)。容器默认按 UID 1000 运行,而 macOS 用户 UID 从 501 起,写出的文件你在宿主机上可能读不了。把真实 UID/GID 写进.env:echo UID$(id -u) .env echo GID$(id -g) .env docker compose -f docker-compose.three-container.yml up -d --force-recreate如果要开放 gateway API 或远程访问。8642 端口只在设置了API_SERVER_KEY(至少 16 位)时才会打开;对外暴露 WebUI 时建议同时加访问密码:echo API_SERVER_KEY$(openssl rand -hex 16) .env echo HERMES_WEBUI_PASSWORDchange-me-strong .env docker compose -f docker-compose.three-container.yml up -d --force-recreate生效后 WebUI 的 Tasks/系统状态面板才会显示 gateway 在线;端口若要绑到 0.0.0.0,请配合反向代理或隧道做一层鉴权。出问题了这样排查现象:WebUI 提示 Hermes agent is not responding 或 gateway 不可达。原因:API_SERVER_KEY没设置或不足 16 位,8642 端口根本没打开。操作:按上一节写入 key 并重建容器,再确认宿主机上 8642 有监听。现象:容器启动即崩,日志里是PermissionError/permission denied。原因:宿主机 UID 和容器内 UID 不一致,常见于绑定挂载场景。操作:id -u查出宿主 UID,写入.env的UID/GID后重建;改用命名卷(默认)通常可绕开。现象:.env: permission denied(对应 issue #1389)。原因:WebUI 的凭据权限检查强制 0600,旧文件读不了。操作:在.env里加HERMES_SKIP_CHMOD1后重建。现象:容器起不来,报port is already allocated。原因:宿主 8787 / 9119 / 8642 被别的进程占用。操作:改 compose 文件ports里冒号左侧的宿主端口,容器侧端口保持不动。日常维护速查操作命令说明看日志docker logs hermes-agent(webui / dashboard 同理)排查启动与运行时错误全部停止docker compose -f docker-compose.three-container.yml down只停容器,数据卷保留升级镜像down→docker volume rm hermes-webui_hermes-agent-src→pull→up -d必须删 agent-src 卷,否则旧源码被原样复用备份数据见下方命令全部状态都在 hermes-home 卷里备份把共享卷打包出来,还原时反向挂载即可:docker run --rm -v hermes-webui_hermes-home:/source -v $(pwd):/backup alpine \ tar -czf /backup/hermes-backup.tar.gz -C /source .卷名前缀取决于 compose 项目名(默认就是目录名hermes-webui),不确定时先docker volume ls看一眼。进一步阅读docs/docker.md——官方 Docker 参考:三种 Compose 的完整对比、失败模式表和绑定挂载迁移步骤。ARCHITECTURE.md——后端/前端布局与状态目录结构,想弄清数据落在哪时看它。docs/troubleshooting.md——常见报错现象与对应修复的清单。docker-compose.two-container.yml——不带监控面板的变体,只需聊天加定时任务时对照参考。【免费下载链接】hermes-webuiHermes WebUI: The best way to use Hermes Agent from the web or from your phone!项目地址: https://gitcode.com/GitHub_Trending/he/hermes-webui创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考