Huly 如何用 branding.json 配置多品牌Huly 与 TraceX部署【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform在本地用 Docker Compose 部署 Huly 时同一套服务需要同时以两个品牌对外提供访问huly.local:8087上显示 Hulyhuly.local:8088上显示 TraceX。仓库通过dev/branding.json这个单一配置区分品牌——文件以「访问 host:port」为键每个条目声明key、title等品牌信息front 服务把该文件作为/branding.json暴露给客户端account、workspace、transactor 等服务则通过挂载的BRANDING_PATH读取它。这篇文章描述如何编辑该文件并重启 Compose 部署使两个端口的访问入口各自呈现对应品牌。配置文件在哪里、被哪些服务读取品牌配置只有一个来源dev/branding.json。在 dev/docker-compose.yaml 中它被挂载进多个服务account、workspace_cockroach、transactor_cockroach./branding.json:/var/cfg/branding.json并设置环境变量BRANDING_PATH/var/cfg/branding.jsonfront不挂载该文件而是通过BRANDING_URLhttp://huly.local:8087/branding.json向客户端声明品牌文件地址front 的 readme 中说明BRANDING_URL即「branding service 的 URL」见 front readmesign挂载的是另一份文件../services/sign/pod-sign/debug/branding.json与dev/branding.json无关。修改dev/branding.json不会影响 sign 服务读到的品牌配置。front 容器对外映射了两个端口dev/docker-compose.yaml 中ports: 8087:8080与8088:8080因此8087和8088两个入口都由同一个 front 服务提供品牌差异完全由 branding.json 条目区分。条目字段与 Huly / TraceX 的写法dev/branding.json 顶层是以host:port为键的对象每个条目包含仓库中实际使用的以下字段key品牌标识例如huly、tracex。front 的DESKTOP_UPDATES_CHANNELSdev;tracex:dev-tracex表明该 key 同时决定桌面客户端走哪个更新通道dev或dev-tracexkey 与通道名必须对应title对外展示的产品名例如Huly、TraceXprotocolhttplanguage语言仓库示例统一为enlastNameFirst可选仓库中 Huly 各条目设为trueTraceX 条目未设置initWorkspace可选仓库中仅example.localhost条目使用了init。仓库中与双品牌部署直接相关的两个条目huly.local:8087: { key: huly, title: Huly, protocol: http, language: en, lastNameFirst: true }, huly.local:8088: { key: tracex, title: TraceX, protocol: http, language: en }键必须写成客户端实际用来访问的host:port。仓库同时准备了从宿主机直连的条目host.docker.internal:8087/host.docker.internal:8088说明如果客户端不用huly.local域名而是走host.docker.internal需要为对应 host:port 增加条目否则匹配不到配置。另外注意仓库示例中的原样细节host.docker.internal:8088条目的key是tracex-docker而title写的是Huly——这提醒你在新增条目时key和title要分别核对二者不一致会导致品牌标识与展示名不符。部署步骤1. 准备环境使用 Docker Compose 环境仓库默认 compose 文件即 dev/docker-compose.yaml。在dev/下准备.env提供 compose 文件引用的QUEUE_CONFIG、STORAGE_CONFIG、DB_CR_URL、BACKUP_STORAGE_CONFIG、BACKUP_BUCKET_NAME、PLATFORM_ADMIN_EMAILS等变量compose 中所有服务都依赖这些变量展开。需要让客户端解析huly.local容器侧通过extra_hosts: huly.local:host-gateway指向宿主机。2. 修改 branding.json编辑dev/branding.json按上文结构维护两个端口的条目。仓库默认值已覆盖 Huly 与 TraceX如需调整展示名或 key只改对应条目即可。新增条目时保持 JSON 合法顶层仍是host:port键的对象。3. 构建镜像并启动dev/readme.md 给出的启动流程rush build rush bundle rush docker:build docker compose up -d --force-recreate其中前三个命令从源码构建服务镜像如果你复用已有镜像、只改了branding.json核心动作是让挂载了该文件的容器重新创建--force-recreate使/var/cfg/branding.json与新文件一致。结果验证确认容器在运行ARCHITECTURE_OVERVIEW.md 的排查方式docker ps拉取品牌文件确认返回的就是你修改后的内容条目、key、titlecurl http://huly.local:8087/branding.json这个地址即 front 的BRANDING_URLhttp://huly.local:8087/branding.json。JSON 中出现你期望的条目说明 front 已经在对外提供更新后的品牌配置。分别从http://huly.local:8087与http://huly.local:8088打开界面确认展示的产品名分别是 Huly 和 TraceX。排查与限制某个入口展示的品牌不对时按顺序核对curl拉到的branding.json是否为最新文件不是则检查容器是否已用--force-recreate重建条目键是否与访问用的host:port完全一致huly.local、host.docker.internal是两套键key与title是否被误写反或漏写。服务异常时按 ARCHITECTURE_OVERVIEW.md 给出的通用方式查看日志docker logs -f [container_id]。如果从桌面客户端访问且按 key 路由更新通道key必须与DESKTOP_UPDATES_CHANNELS中声明的通道名dev、dev-tracex对应。仓库中tracex-devhuly.local:8081、tracex-dockerhost.docker.internal:8088等条目面向其他访问入口与 8087/8088 双品牌部署不是同一条链路除非你的客户端实际使用这些 host:port否则不需要维护它们。services/sign使用的是独立的services/sign/pod-sign/debug/branding.jsondev/docker-compose.yaml 中单独挂载本文对dev/branding.json的修改不覆盖它。完成判据/branding.json接口返回修改后的内容且 8087、8088 两个入口分别呈现 Huly 与 TraceX 品牌即说明多品牌部署生效。【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考