Homarr 评测：用拖拽替代 YAML 的自托管仪表盘，值不值得换？
现代且易于使用的仪表板。 40 多个集成。内置 20K+ 图标。开箱即用的身份验证。没有 YAML，拖放配置。
秒懂
- 它是什么？
- Homarr 是一个主打免 YAML、拖拽配置的仪表盘项目，集成 40 多个自托管应用。本文基于仓库文档分析其机制、安装方式、局限与替代方案。
- 适合谁用？
- Homarr 适合那些已经运行多个自托管应用、希望用一个可视化界面集中管理入口和状态、并且不想手写 YAML 配置的用户。它不适合对配置版本控制有严格要求的团队，因为拖拽生成的配置难以像文本文件那样进行 diff 和审查。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题：自托管应用的入口混乱
自托管用户通常运行多个服务，比如 Jellyfin、Pi-hole、Home Assistant，每个服务有独立的 IP 和端口。记住这些地址是负担，更麻烦的是每个服务的状态（是否在线、磁盘剩余、下载进度）都需要单独打开页面查看。Homarr 的目标是把这些入口和状态聚合到一个可自定义的仪表盘上。它面向的是家庭实验室用户、小型团队以及喜欢折腾硬件的个人。这类用户通常熟悉 Docker，但不想为每个小改动去编辑配置文件。Homarr 的定位很明确：用图形界面替代文本配置，降低日常维护的门槛。
核心机制：拖拽网格与实时数据流
Homarr 的核心是一个拖拽网格系统，用户可以在浏览器中直接摆放应用图标和组件，无需接触 YAML。这个网格是响应式的，文档称其“高度可定制”。数据流方面，Homarr 使用 WebSockets、tRPC 和 Redis 实现实时更新。这意味着当你在 Pi-hole 上屏蔽一个域名，仪表盘上的统计数字会立即变化，而不是手动刷新。tRPC 是 TypeScript 的远程过程调用框架，它让前后端共享类型定义，减少了 API 不一致的风险。Redis 在这里作为消息代理和缓存层，支撑多个实例之间的状态同步。架构上，Homarr 是前后端分离的，前端处理拖拽交互，后端通过 tRPC 暴露数据，Redis 负责实时推送。这种设计比简单的静态链接聚合器更复杂，但也带来了真正的动态能力。
安装与配置：从 Docker 到 Kubernetes
Homarr 的安装方式以 Docker 为主，官方文档提供了安装指南。根据 README，它兼容 x86、Raspberry Pi 等消费级硬件，也支持 Windows、Linux、TrueNAS 和 Unraid。典型的部署是通过 Docker Compose 拉取镜像并映射端口。配置过程全部在 Web UI 完成，添加应用时只需选择集成类型并填写 URL 和 API 密钥。例如，添加 Jellyfin 时，你需要提供服务器地址和 API 密钥，Homarr 会自动拉取媒体库信息。用户管理内置，支持创建组和分配权限。单点登录支持 OIDC 和 LDAP，这对已有身份管理的团队是加分项。Kubernetes 用户可以使用官方 Helm chart 进行部署，README 提到它支持“高效扩展和高可靠性”，但具体配置细节需要查阅文档。
安全设计：加密存储与认证
Homarr 在安全方面有两个明确的设计：密码使用 BCrypt 哈希，敏感数据（如 API 密钥）使用 AES-256-CBC 加密。这意味着即使数据库泄露，攻击者也无法直接读取明文密钥。认证方面，除了本地用户管理，还支持 OIDC 和 LDAP 单点登录。这对企业环境很重要，因为可以复用现有的身份源，避免在每个工具里单独维护账号。不过，AES-256-CBC 是块加密，需要合适的初始化向量管理，文档中没有详细说明密钥如何存储和轮换。如果你计划存储多个服务的 API 密钥，建议评估 Homarr 的加密实现是否符合你的安全标准。
集成生态：40+ 应用，但深度不一
README 列出了 40 多个集成，包括 AdGuard Home、Home Assistant、Jellyfin、Nextcloud、Plex、Pi-hole 等常见自托管应用。图标库内置超过 11K 个图标，这解决了自建仪表盘时图标缺失的痛点。但集成深度差异明显。有些集成（如 Jellyfin）支持拉取媒体库和播放状态，而有些可能只是简单的链接跳转。特别要注意的是，README 中部分集成的文档链接为 null，例如 Audiobookshelf、Glances、Navidrome、Paperless-ngx、PeaNUT。这意味着这些集成可能还没有完整的文档，或者仍处于开发阶段。如果你依赖这些应用，需要先验证 Homarr 是否真正支持你需要的功能，而不是仅凭列表判断。
开发与发布节奏：活跃但需关注稳定性
仓库的默认分支是 dev，最近一次提交在 2026-08-27，发布了 v1.76.2。发布频率较高，几乎每周都有小版本更新。这是一个活跃的项目，但也意味着 API 和配置格式可能变动。对于生产环境，升级前需要阅读 release notes，特别是涉及数据库迁移的变更。Homarr 使用 Crowdin 进行翻译，社区活跃，Discord 频道是主要支持渠道。如果你遇到问题，可能需要依赖社区而不是官方工单。对于工程师来说，这意味着采用 Homarr 需要预留维护时间，不能指望“安装后不管”。
替代方案与适用边界
Homarr 的主要替代方案是 Heimdall 和 Dashy。Heimdall 是一个更简单的仪表盘，专注于链接聚合，配置也基于 YAML，但功能更少。Dashy 则提供类似的小组件和状态显示，但配置同样是 YAML 文件，适合喜欢文本配置的用户。Homarr 的差异化在于完全图形化配置和实时数据更新。如果你已经习惯用 Git 管理配置文件，Dashy 可能更适合，因为 YAML 可以 diff 和审查。Homarr 的拖拽配置存储在数据库中，这不利于版本控制。另外，Homarr 的实时更新依赖 Redis，如果 Redis 不可用，仪表盘的实时性会受影响。对于只想要静态链接页面的用户，Homarr 可能过度设计，一个简单的 nginx 页面就够了。
许可与维护成本
Homarr 采用 Apache-2.0 许可，允许商业使用和修改，但需要保留版权声明和许可文本。这是一个宽松的许可，对大多数自托管用户没有限制。维护成本方面，由于项目活跃，你需要定期跟进更新。v1.76.2 是当前版本，但 dev 分支是默认，说明项目仍处于快速迭代期。升级可能涉及数据库迁移，建议在测试环境验证后再部署。另外，Homarr 的依赖包括 Redis，这意味着你需要在 Docker 环境中额外运行一个 Redis 容器，增加了资源占用和故障点。对于 Raspberry Pi 这样的低功耗设备，需要评估内存占用是否可接受。
编辑结论
Homarr 适合那些已经运行多个自托管应用、希望用一个可视化界面集中管理入口和状态、并且不想手写 YAML 配置的用户。它不适合对配置版本控制有严格要求的团队，因为拖拽生成的配置难以像文本文件那样进行 diff 和审查。也不适合需要深度定制仪表盘逻辑的场景，因为其能力边界由内置集成决定。在采用前，建议先确认你的目标应用是否在 40 多个集成列表中，特别是那些 README 中链接为 null 的集成（如 Audiobookshelf、Glances、Navidrome），这些可能仍处于实验阶段。同时，验证 OIDC 和 LDAP 单点登录是否与你的身份提供商兼容。Homarr 的 Apache-2.0 许可允许商业使用，但若你计划分发修改版本，需注意保留版权声明。最后，升级到 v1.76.x 时，请关注发布说明中关于数据库迁移和配置格式的变更，因为 v1 系列仍在活跃开发中，API 可能未完全稳定。
社区笔记