如何在 VPS 上用 Docker Compose 部署 headless openhuman-core 并挂载持久化数据卷【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhumanOpenHuman 本体是桌面应用但它的 Rust 核心openhuman-core是一个 headless JSON-RPC 服务器可以独立托管在云服务器上多台桌面客户端指向同一个 core、内部测试者不需要本地 Rust 工具链、长时间运行的 cron / webhook 任务不再依赖笔记本会话。gitbooks/features/cloud-deploy.md 把这条部署路径称为 Any VPS via Docker Compose在任意装有 Docker 的 VPS 上用 Compose 起一个容器运行openhuman-core serve监听 7788 端口并把工作区挂到持久化数据卷上。文档明确的前提主机已安装 Docker Engine ≥ 24 和 Compose 插件DigitalOcean Droplet、Hetzner、Linode、EC2、家庭服务器均可如果拉取 GHCR 发布镜像主机应为linux/amd64。发布镜像是linux/amd64arm64 主机应下载同一 GitHub Release 附带的独立 tarballopenhuman-core-version-aarch64-unknown-linux-gnu.tar.gz或在 arm64 构建机上从源码构建镜像。容器起来后对外暴露三个端点GET /health公开 liveness probe所有部署路径的 healthcheck 都用它POST /rpcbearer 保护的 JSON-RPC 入口GET /events、GET /ws/dictation公开流式通道。部署对象是 core 而不是 UI。文档说明 OpenHuman 支持的远程形态是core remote, UI localcore 跑在 Linux 服务器上桌面客户端通过 RPC URL 连接部署的 core 目前不会把完整 React/Tauri UI 作为生产 Web 应用对外提供托盘、原生 deep link、系统 keychain 等桌面专属功能仍依赖 Tauri shell。准备 .env必配项仓库根目录的 .env.example 是配置模板docker-compose.yml 通过env_file读取与 compose 文件同目录的.env。文档给出的开始前所需清单变量是否必需说明OPENHUMAN_CORE_TOKEN是客户端调用/rpc携带的 bearer token用openssl rand -hex 32生成。文档强调拿到这个 token 的人可以驱动整个 coreBACKEND_URL是core 连接的 Tinyhumans 后端生产环境为https://api.tinyhumans.aiOPENHUMAN_APP_ENV否production或staging默认productionOPENHUMAN_CORE_HOST否容器内默认0.0.0.0OPENHUMAN_CORE_PORT否默认7788RUST_LOG否info够用排查问题用debug在 VPS 上克隆仓库并生成.envgit clone openhuman 仓库地址 # 占位符替换为你获取本项目的仓库地址 cd openhuman cp .env.example .env # 编辑 .env至少设置 # BACKEND_URLhttps://api.tinyhumans.ai # OPENHUMAN_CORE_TOKENopenssl rand -hex 32 的输出 # OPENHUMAN_APP_ENVproductiontoken 直接在服务器上生成openssl rand -hex 32把输出粘进.env的OPENHUMAN_CORE_TOKEN行。这个值之后还要配到每台桌面客户端文档建议按密码对待。启动并验证docker compose up -d仓库内 Compose 文件默认从 Dockerfile 本地构建镜像tag 为openhuman-core:local构建较慢但版本与源码一致。Compose 文件自身固定了容器内绑定地址OPENHUMAN_CORE_HOST0.0.0.0、端口7788、OPENHUMAN_WORKSPACE/home/openhuman/.openhuman并设置restart: unless-stopped宿主机重启后容器自动拉起。按文档给出的两条命令验证docker compose ps curl -fsS http://localhost:7788/health/health是公开端点不需要 tokencurl 不报错误即说明容器已可响应。docker-compose.yml 还配置了 healthcheck每 30 秒执行一次curl -fsS http://localhost:7788/healthtimeout 5s、start_period 15s、重试 3 次docker compose ps中的健康状态会反映这条检查的结果。看日志docker compose logs -f openhuman-core持久化卷openhuman-workspace容器内工作区目录固定为/home/openhuman/.openhuman存放 core 的配置、sqlite 数据库和 skill 状态。文档对生产部署的要求很直接必须把该目录挂到持久卷上否则重启就丢数据。docker-compose.yml 已经完成了这件事volumes: - openhuman-workspace:/home/openhuman/.openhuman volumes: openhuman-workspace: name: openhuman-workspace也就是说按仓库文件原样启动持久化已就位无需额外操作。数据属主问题由镜像自带的入口点处理Docker 创建的 named volume 默认属于root:root而 core 以非 root 的openhuman用户Dockerfile 中 UID 10001运行若不做处理首次写工作区就会报Permission denied (os error 13)。镜像内的/usr/local/bin/docker-entrypoint-core.sh源文件为 scripts/docker-entrypoint-core.sh按顺序以root启动对$OPENHUMAN_WORKSPACE和$HOME/.openhuman执行mkdir -pchown openhuman:openhumanexec gosu openhuman openhuman-core $降权交接给二进制。该逻辑是幂等的全新卷上 chown 是修复已修复的卷上是空操作。从早于该修复的旧镜像升级时不需要手动docker volume rm。Compose 文件同时限制了容器能力read_only: true、no-new-privileges、cap_drop: ALL只加回CHOWN/SETUID/SETGID三个能力分别用于修复卷属主和 gosu 降权。文件注释给出零能力的替代方案固定user: 10001:10001入口点会直接执行二进制并跳过修复代价是无法再修复 root 属主的卷。资源上限默认mem_limit4g、cpus2.0可用OPENHUMAN_CORE_MEM_LIMIT/OPENHUMAN_CORE_CPUS环境变量覆盖。可选分支改用 GHCR 发布镜像不想在 VPS 上编译 Rust 的话可以用各生产发布推送到 GHCR 的多 tag 镜像下面1.2.4为文档给出的示例版本docker pull ghcr.io/tinyhumansai/openhuman-core:latest # 跟踪最新 prod cut docker pull ghcr.io/tinyhumansai/openhuman-core:v1.2.4 # 按 GitHub Release tag 固定 docker pull ghcr.io/tinyhumansai/openhuman-core:1.2.4 # 按 SemVer 固定按 docker-compose.yml 头部注释的说明把build:段替换为image: ghcr.io/tinyhumansai/openhuman-core:tagtag替换为上面的镜像 tag再执行docker compose up -d即不再本地构建。cloud-deploy 指南 对同一操作的表述是把image:字段切到发布镜像。边界提醒发布镜像是linux/amd64arm64 VPS 上应改走文档给出的独立 tarball 或源码构建两条路而不是直接拉发布镜像。核对运行中的 token 来源重部署后 401是最常见的部署故障根因几乎都是 token 来源。core 有两种加载 token 的方式实现见 src/core/auth.rsOPENHUMAN_CORE_TOKEN环境变量由调用方预置Tauri shell、Docker、App Platform、systemd 均属此类core 原样使用从不写文件{workspace}/core.token文件仅在未设置环境变量时于首次启动生成供 CLI 客户端cat。文档对任何远程/容器化部署的规则始终设置OPENHUMAN_CORE_TOKEN不要依赖容器里的core.token——临时文件系统重部署后 token 会丢容器外读到的也是过期或空值。两条路径在启动时互斥混用就是重部署后 dashboard 401的常见原因。确认运行中的容器实际用的是哪个# 宿主机上查来源打印 env 或 file:/path scripts/print-core-token.sh --where # 进容器看前 8 位脱敏可进日志 docker compose exec openhuman-core /bin/sh -c \ echo -n $OPENHUMAN_CORE_TOKEN | head -c 8; echo …scripts/print-core-token.sh 还支持--redact前 8 位 hex 省略号和不带参数打印完整值可直接管道给客户端。把桌面客户端指向这台 corecore 部署完成不等于可用——桌面端要显式切换到外部 core。在桌面应用的环境文件app/.env.local中写入# 使用托管 core而不是本地拉起 sidecar OPENHUMAN_CORE_RUN_MODEexternal OPENHUMAN_CORE_RPC_URLhttps://core.example.com/rpc OPENHUMAN_CORE_TOKEN与服务器 .env 中相同的值重启桌面应用。也可以不编辑文件直接用首次运行选择器里的 Core RPC URL token 输入框旁边的Test connection按钮会对该 URL 发起core.ping在内联位置报告Connected ✓/Auth failed/Unreachable确认通过后才持久化配置。协议边界应用选择器拒绝公网http://地址公网可达的 core 必须走 HTTPS。文档给出的最小 Caddy 反代配置core.example.com { reverse_proxy localhost:7788 }只在私网/tailnet 暴露如 Tailscale 的100.x.x.x地址、公网不可达时可以直接用http://100.x.x.x:7788/rpc。若另外把浏览器 UI 部署到非 loopback origin需把该 origin 精确加入OPENHUMAN_CORE_ALLOWED_ORIGINSloopback 的 Vite originhttp://127.0.0.1:1420、http://localhost:1420自动放行。常见故障与排查重部署后客户端 401对照核对运行中的 token 来源一节确认OPENHUMAN_CORE_TOKEN环境变量存在且与每台客户端里的值一致。轮换 token 后仍持旧 token 的客户端在下次/rpc调用时收到 HTTP 401 是预期行为不是回归。Permission denied (os error 13)文档列出三个已知触发场景在同一持久卷上混用 Dockerfile 构建镜像openhuman用户 UID 10001与 GHCR 发布镜像UID 1000旧文件属主不匹配named volume 比镜像升级活得久以 root 身份docker exec往工作区写了文件——docker exec不经过入口点root 写入会留下root:root的config.tomlcore 以 0600 权限写它运行用户随后完全打不开。入口点每次启动都会递归 chown 修复跳过已属主正确的条目。如果修复无法执行例如cap_drop: ALL但没加cap_add: CHOWN入口点会拒绝启动并在日志中打印需要执行的chown命令——检查容器日志里的[docker-entrypoint] pre-heal/FATAL行。手动修复文档给出的 Docker 等价命令UID 从容器内动态推导docker exec -u 0 openhuman-core sh -c \ chown -rh $(id -u openhuman):$(id -g openhuman) /home/openhuman/.openhuman docker restart openhuman-core修复前可先确认属主注意docker exec默认以 root 进入要显式查运行用户而不是直接iddocker exec openhuman-core sh -c id openhuman; ls -ln /home/openhuman/.openhuman/config.toml日常进容器操作建议加-u openhuman避免再次制造 root 属主文件。云端运行时 OAuth 登录后 sign-in 失败现象浏览器里 OAuth 已完成提示关闭此页返回应用桌面端却报 sign-in 错误而同一账号在本地内嵌运行时登录正常。文档issue #3025指出根因几乎总在远端 coreauth_store_session会先让 core 调用后端GET /auth/me校验新会话再持久化该调用发生在你的服务器上文档列出的失败原因BACKEND_URL未设置或错误——文档说是最高发原因生产必须是https://api.tinyhumans.aistaging 为https://staging-api.tinyhumans.ai服务器到后端不通出口防火墙、DNS、TLS 拦截——core 在/auth/me上遇到网关错误/超时core 版本过旧——早于allowPendingBackendValidation的版本是同步校验、无宽限期把服务器更新到当前发布RPC token 不匹配——表现为/rpc上的 HTTP 401重贴 token 即可。在远端 core 日志里找Session validation failed (GET /auth/me)及其 status/reason桌面端对这类云场景会给出具体可操作的信息而不是笼统的 try again。运维轮换 token 与更新版本OPENHUMAN_CORE_TOKEN是公网与全量 RPC 访问之间唯一的屏障文档建议定期轮换、并在任何疑似泄露后轮换。下面命令组会改写服务器上的.env、删除临时 token 文件并重建容器执行前确认.env路径正确# 1. 生成新 token 并更新服务器侧 .env openssl rand -hex 32 /tmp/new-token sed -i.bak s|^OPENHUMAN_CORE_TOKEN.*|OPENHUMAN_CORE_TOKEN$(cat /tmp/new-token)| .env rm /tmp/new-token .env.bak # 2. 重建容器让新值进入 core 进程 docker compose up -d --force-recreate openhuman-core # 3. 确认运行中的容器使用新 token脱敏打印前 8 位 docker compose exec openhuman-core /bin/sh -c \ echo -n $OPENHUMAN_CORE_TOKEN | head -c 8; echo … # 4. 更新每台桌面客户端切换模式后在选择器重贴或改 app/.env.local 再重启。 # 仍持旧 token 的客户端下一次 /rpc 调用会 401 —— 属预期行为。更新版本本地构建路径git pull docker compose build docker compose up -d对暴露/rpc的生产部署文档建议保持变更类 update RPC 关闭OPENHUMAN_AUTO_UPDATE_RPC_MUTATIONS_ENABLEDfalse版本发布走镜像 tag 或包管理流程而不是通过 RPC 触发更新。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何在 VPS 上用 Docker Compose 部署 headless openhuman-core 并挂载持久化数据卷【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhumanOpenHuman 本体是桌面应用但它的 Rust 核心openhuman-core是一个 headless JSON-RPC 服务器可以独立托管在云服务器上多台桌面客户端指向同一个 core、内部测试者不需要本地 Rust 工具链、长时间运行的 cron / webhook 任务不再依赖笔记本会话。gitbooks/features/cloud-deploy.md 把这条部署路径称为 Any VPS via Docker Compose在任意装有 Docker 的 VPS 上用 Compose 起一个容器运行openhuman-core serve监听 7788 端口并把工作区挂到持久化数据卷上。文档明确的前提主机已安装 Docker Engine ≥ 24 和 Compose 插件DigitalOcean Droplet、Hetzner、Linode、EC2、家庭服务器均可如果拉取 GHCR 发布镜像主机应为linux/amd64。发布镜像是linux/amd64arm64 主机应下载同一 GitHub Release 附带的独立 tarballopenhuman-core-version-aarch64-unknown-linux-gnu.tar.gz或在 arm64 构建机上从源码构建镜像。容器起来后对外暴露三个端点GET /health公开 liveness probe所有部署路径的 healthcheck 都用它POST /rpcbearer 保护的 JSON-RPC 入口GET /events、GET /ws/dictation公开流式通道。部署对象是 core 而不是 UI。文档说明 OpenHuman 支持的远程形态是core remote, UI localcore 跑在 Linux 服务器上桌面客户端通过 RPC URL 连接部署的 core 目前不会把完整 React/Tauri UI 作为生产 Web 应用对外提供托盘、原生 deep link、系统 keychain 等桌面专属功能仍依赖 Tauri shell。准备 .env必配项仓库根目录的 .env.example 是配置模板docker-compose.yml 通过env_file读取与 compose 文件同目录的.env。文档给出的开始前所需清单变量是否必需说明OPENHUMAN_CORE_TOKEN是客户端调用/rpc携带的 bearer token用openssl rand -hex 32生成。文档强调拿到这个 token 的人可以驱动整个 coreBACKEND_URL是core 连接的 Tinyhumans 后端生产环境为https://api.tinyhumans.aiOPENHUMAN_APP_ENV否production或staging默认productionOPENHUMAN_CORE_HOST否容器内默认0.0.0.0OPENHUMAN_CORE_PORT否默认7788RUST_LOG否info够用排查问题用debug在 VPS 上克隆仓库并生成.envgit clone openhuman 仓库地址 # 占位符替换为你获取本项目的仓库地址 cd openhuman cp .env.example .env # 编辑 .env至少设置 # BACKEND_URLhttps://api.tinyhumans.ai # OPENHUMAN_CORE_TOKENopenssl rand -hex 32 的输出 # OPENHUMAN_APP_ENVproductiontoken 直接在服务器上生成openssl rand -hex 32把输出粘进.env的OPENHUMAN_CORE_TOKEN行。这个值之后还要配到每台桌面客户端文档建议按密码对待。启动并验证docker compose up -d仓库内 Compose 文件默认从 Dockerfile 本地构建镜像tag 为openhuman-core:local构建较慢但版本与源码一致。Compose 文件自身固定了容器内绑定地址OPENHUMAN_CORE_HOST0.0.0.0、端口7788、OPENHUMAN_WORKSPACE/home/openhuman/.openhuman并设置restart: unless-stopped宿主机重启后容器自动拉起。按文档给出的两条命令验证docker compose ps curl -fsS http://localhost:7788/health/health是公开端点不需要 tokencurl 不报错误即说明容器已可响应。docker-compose.yml 还配置了 healthcheck每 30 秒执行一次curl -fsS http://localhost:7788/healthtimeout 5s、start_period 15s、重试 3 次docker compose ps中的健康状态会反映这条检查的结果。看日志docker compose logs -f openhuman-core持久化卷openhuman-workspace容器内工作区目录固定为/home/openhuman/.openhuman存放 core 的配置、sqlite 数据库和 skill 状态。文档对生产部署的要求很直接必须把该目录挂到持久卷上否则重启就丢数据。docker-compose.yml 已经完成了这件事volumes: - openhuman-workspace:/home/openhuman/.openhuman volumes: openhuman-workspace: name: openhuman-workspace也就是说按仓库文件原样启动持久化已就位无需额外操作。数据属主问题由镜像自带的入口点处理Docker 创建的 named volume 默认属于root:root而 core 以非 root 的openhuman用户Dockerfile 中 UID 10001运行若不做处理首次写工作区就会报Permission denied (os error 13)。镜像内的/usr/local/bin/docker-entrypoint-core.sh源文件为 scripts/docker-entrypoint-core.sh按顺序以root启动对$OPENHUMAN_WORKSPACE和$HOME/.openhuman执行mkdir -pchown openhuman:openhumanexec gosu openhuman openhuman-core $降权交接给二进制。该逻辑是幂等的全新卷上 chown 是修复已修复的卷上是空操作。从早于该修复的旧镜像升级时不需要手动docker volume rm。Compose 文件同时限制了容器能力read_only: true、no-new-privileges、cap_drop: ALL只加回CHOWN/SETUID/SETGID三个能力分别用于修复卷属主和 gosu 降权。文件注释给出零能力的替代方案固定user: 10001:10001入口点会直接执行二进制并跳过修复代价是无法再修复 root 属主的卷。资源上限默认mem_limit4g、cpus2.0可用OPENHUMAN_CORE_MEM_LIMIT/OPENHUMAN_CORE_CPUS环境变量覆盖。可选分支改用 GHCR 发布镜像不想在 VPS 上编译 Rust 的话可以用各生产发布推送到 GHCR 的多 tag 镜像下面1.2.4为文档给出的示例版本docker pull ghcr.io/tinyhumansai/openhuman-core:latest # 跟踪最新 prod cut docker pull ghcr.io/tinyhumansai/openhuman-core:v1.2.4 # 按 GitHub Release tag 固定 docker pull ghcr.io/tinyhumansai/openhuman-core:1.2.4 # 按 SemVer 固定按 docker-compose.yml 头部注释的说明把build:段替换为image: ghcr.io/tinyhumansai/openhuman-core:tagtag替换为上面的镜像 tag再执行docker compose up -d即不再本地构建。cloud-deploy 指南 对同一操作的表述是把image:字段切到发布镜像。边界提醒发布镜像是linux/amd64arm64 VPS 上应改走文档给出的独立 tarball 或源码构建两条路而不是直接拉发布镜像。核对运行中的 token 来源重部署后 401是最常见的部署故障根因几乎都是 token 来源。core 有两种加载 token 的方式实现见 src/core/auth.rsOPENHUMAN_CORE_TOKEN环境变量由调用方预置Tauri shell、Docker、App Platform、systemd 均属此类core 原样使用从不写文件{workspace}/core.token文件仅在未设置环境变量时于首次启动生成供 CLI 客户端cat。文档对任何远程/容器化部署的规则始终设置OPENHUMAN_CORE_TOKEN不要依赖容器里的core.token——临时文件系统重部署后 token 会丢容器外读到的也是过期或空值。两条路径在启动时互斥混用就是重部署后 dashboard 401的常见原因。确认运行中的容器实际用的是哪个# 宿主机上查来源打印 env 或 file:/path scripts/print-core-token.sh --where # 进容器看前 8 位脱敏可进日志 docker compose exec openhuman-core /bin/sh -c \ echo -n $OPENHUMAN_CORE_TOKEN | head -c 8; echo …scripts/print-core-token.sh 还支持--redact前 8 位 hex 省略号和不带参数打印完整值可直接管道给客户端。把桌面客户端指向这台 corecore 部署完成不等于可用——桌面端要显式切换到外部 core。在桌面应用的环境文件app/.env.local中写入# 使用托管 core而不是本地拉起 sidecar OPENHUMAN_CORE_RUN_MODEexternal OPENHUMAN_CORE_RPC_URLhttps://core.example.com/rpc OPENHUMAN_CORE_TOKEN与服务器 .env 中相同的值重启桌面应用。也可以不编辑文件直接用首次运行选择器里的 Core RPC URL token 输入框旁边的Test connection按钮会对该 URL 发起core.ping在内联位置报告Connected ✓/Auth failed/Unreachable确认通过后才持久化配置。协议边界应用选择器拒绝公网http://地址公网可达的 core 必须走 HTTPS。文档给出的最小 Caddy 反代配置core.example.com { reverse_proxy localhost:7788 }只在私网/tailnet 暴露如 Tailscale 的100.x.x.x地址、公网不可达时可以直接用http://100.x.x.x:7788/rpc。若另外把浏览器 UI 部署到非 loopback origin需把该 origin 精确加入OPENHUMAN_CORE_ALLOWED_ORIGINSloopback 的 Vite originhttp://127.0.0.1:1420、http://localhost:1420自动放行。常见故障与排查重部署后客户端 401对照核对运行中的 token 来源一节确认OPENHUMAN_CORE_TOKEN环境变量存在且与每台客户端里的值一致。轮换 token 后仍持旧 token 的客户端在下次/rpc调用时收到 HTTP 401 是预期行为不是回归。Permission denied (os error 13)文档列出三个已知触发场景在同一持久卷上混用 Dockerfile 构建镜像openhuman用户 UID 10001与 GHCR 发布镜像UID 1000旧文件属主不匹配named volume 比镜像升级活得久以 root 身份docker exec往工作区写了文件——docker exec不经过入口点root 写入会留下root:root的config.tomlcore 以 0600 权限写它运行用户随后完全打不开。入口点每次启动都会递归 chown 修复跳过已属主正确的条目。如果修复无法执行例如cap_drop: ALL但没加cap_add: CHOWN入口点会拒绝启动并在日志中打印需要执行的chown命令——检查容器日志里的[docker-entrypoint] pre-heal/FATAL行。手动修复文档给出的 Docker 等价命令UID 从容器内动态推导docker exec -u 0 openhuman-core sh -c \ chown -rh $(id -u openhuman):$(id -g openhuman) /home/openhuman/.openhuman docker restart openhuman-core修复前可先确认属主注意docker exec默认以 root 进入要显式查运行用户而不是直接iddocker exec openhuman-core sh -c id openhuman; ls -ln /home/openhuman/.openhuman/config.toml日常进容器操作建议加-u openhuman避免再次制造 root 属主文件。云端运行时 OAuth 登录后 sign-in 失败现象浏览器里 OAuth 已完成提示关闭此页返回应用桌面端却报 sign-in 错误而同一账号在本地内嵌运行时登录正常。文档issue #3025指出根因几乎总在远端 coreauth_store_session会先让 core 调用后端GET /auth/me校验新会话再持久化该调用发生在你的服务器上文档列出的失败原因BACKEND_URL未设置或错误——文档说是最高发原因生产必须是https://api.tinyhumans.aistaging 为https://staging-api.tinyhumans.ai服务器到后端不通出口防火墙、DNS、TLS 拦截——core 在/auth/me上遇到网关错误/超时core 版本过旧——早于allowPendingBackendValidation的版本是同步校验、无宽限期把服务器更新到当前发布RPC token 不匹配——表现为/rpc上的 HTTP 401重贴 token 即可。在远端 core 日志里找Session validation failed (GET /auth/me)及其 status/reason桌面端对这类云场景会给出具体可操作的信息而不是笼统的 try again。运维轮换 token 与更新版本OPENHUMAN_CORE_TOKEN是公网与全量 RPC 访问之间唯一的屏障文档建议定期轮换、并在任何疑似泄露后轮换。下面命令组会改写服务器上的.env、删除临时 token 文件并重建容器执行前确认.env路径正确# 1. 生成新 token 并更新服务器侧 .env openssl rand -hex 32 /tmp/new-token sed -i.bak s|^OPENHUMAN_CORE_TOKEN.*|OPENHUMAN_CORE_TOKEN$(cat /tmp/new-token)| .env rm /tmp/new-token .env.bak # 2. 重建容器让新值进入 core 进程 docker compose up -d --force-recreate openhuman-core # 3. 确认运行中的容器使用新 token脱敏打印前 8 位 docker compose exec openhuman-core /bin/sh -c \ echo -n $OPENHUMAN_CORE_TOKEN | head -c 8; echo … # 4. 更新每台桌面客户端切换模式后在选择器重贴或改 app/.env.local 再重启。 # 仍持旧 token 的客户端下一次 /rpc 调用会 401 —— 属预期行为。更新版本本地构建路径git pull docker compose build docker compose up -d对暴露/rpc的生产部署文档建议保持变更类 update RPC 关闭OPENHUMAN_AUTO_UPDATE_RPC_MUTATIONS_ENABLEDfalse版本发布走镜像 tag 或包管理流程而不是通过 RPC 触发更新。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
