家庭实验室仪表盘选择指南：CasaOS、Glance与Homepage对比

前言：家庭实验室仪表盘的意义

对于自建服务（self-hosting）爱好者而言，家庭实验室（Homelab）不仅仅是一堆运行在本地服务器上的容器和应用，它更是一个需要统一管理和监控的生态系统。当你部署的服务从三五个增长到几十个时，一个清晰、美观、高效的仪表盘（Dashboard）就成了刚需。

这里所说的"容器"，指的是基于 Docker 等容器化技术运行的应用实例。Docker 是一种操作系统级别的虚拟化技术，它将应用程序及其所有依赖项打包到一个标准化的单元中运行。与传统虚拟机不同，容器共享宿主机的操作系统内核，因此启动速度快、资源开销小。Docker 的核心概念包括"镜像"（Image）和"容器"（Container）——镜像是只读的应用模板，容器则是镜像的运行实例。用户通常从 Docker Hub（全球最大的容器镜像仓库）或 GitHub Container Registry 拉取社区维护的镜像来部署服务。在 Homelab 场景中，用户通常通过 Docker Compose（一个基于 YAML 的多容器编排工具）来定义和管理多个服务，一个典型的家庭实验室可能同时运行媒体服务器、下载工具、DNS 过滤、反向代理等数十个容器。

值得一提的是，Docker 本身经历了重要的架构演变——其底层运行时已从最初的 LXC 迁移到自研的 containerd 和 runc。containerd 现已成为 CNCF（云原生计算基金会）的毕业项目，被 Kubernetes 等编排系统广泛采用。此外，Podman 作为 Red Hat 推出的无守护进程（daemonless）容器引擎，近年来在 Homelab 社区也获得了一定关注——它不需要以 root 权限运行后台服务，在安全性上具有理论优势，且命令行语法与 Docker 几乎完全兼容，用户迁移成本极低。

除了 Docker Compose 之外，部分进阶 Homelab 用户也开始尝试 Kubernetes（K8s）的轻量级发行版如 K3s 来管理容器集群，尽管这对家庭场景来说通常属于过度工程化。此外，Docker 的网络模型（bridge、host、macvlan 等）在 Homelab 中扮演着关键角色——bridge 模式为每个容器分配独立的虚拟网络接口，host 模式让容器直接使用宿主机网络栈以减少性能损耗，macvlan 模式则允许容器拥有独立的局域网 IP 地址，如同一台真实的物理设备。不同的网络模式决定了容器如何暴露端口、如何与局域网设备通信，理解这些概念对于后续配置仪表盘与各服务的 API 通信至关重要。

近年来，Linuxserver.io 团队维护的一系列标准化镜像（统一 UID/GID 管理、统一目录结构）已成为 Homelab 社区的事实标准，极大降低了自建服务的部署门槛——这也正是统一仪表盘变得不可或缺的原因。

近日，一位Reddit用户分享了自己家庭实验室仪表盘的演变历程，从最初的 CasaOS，到中期的 Glance，再到最终选定的 Homepage，这条进化路线颇具代表性，也反映了自建社区在工具选择上的普遍趋势。

三个阶段：从开箱即用到高度定制

阶段一：CasaOS —— 新手友好的起点

CasaOS 是许多人踏入自建领域的第一站。它由 IceWhale Technology 开发，于 2022 年开源发布，本质上是一个基于 Docker 的轻量级家庭云系统，提供了图形化的应用商店和可视化管理界面。CasaOS 在 Docker 之上封装了一层 Web UI，提供了类似手机应用商店的体验——社区贡献者可以提交预配置好的 Docker Compose 模板，用户只需点击安装即可完成部署。值得一提的是，CasaOS 同时也是 ZimaBoard（一款面向 Homelab 的单板服务器）的默认操作系统，这使其在入门级硬件市场获得了广泛曝光。

CasaOS 的流行与入门级 Homelab 硬件生态的蓬勃发展密不可分。除了 ZimaBoard 之外，近年来涌现了大量面向家庭服务器场景的硬件平台，包括 Intel NUC（虽已停产但仍被广泛使用的迷你电脑）、搭载 Intel N100 处理器的各类迷你主机（因其极低功耗和足够的性能而成为 Homelab 新宠），以及树莓派（Raspberry Pi）等 ARM 平台。CasaOS 的轻量级设计使其能在这些低功耗设备上流畅运行，这也是其能快速获得用户基础的硬件层面原因。许多用户的 Homelab 之旅正是始于一台百元级的迷你主机加上 CasaOS 的组合。

对于刚接触 Homelab 的用户来说，CasaOS 的最大优势在于"开箱即用"——你几乎不需要编写任何配置文件，就能一键部署常见的应用。

然而，CasaOS 的这种"傻瓜化"设计也是一把双刃剑。当用户的需求逐渐复杂化，比如需要接入外部服务、自定义布局或深度整合监控数据时，CasaOS 相对封闭的架构就会显得力不从心。其应用商店模板有时会滞后于上游镜像版本，且自定义网络配置和高级 Docker 参数的支持相对有限，这也是进阶用户最终选择离开的主要原因。它更像是一个应用管理器，而非一个真正意义上的"仪表盘"。

阶段二：Glance —— 信息聚合的尝试

随着需求升级，这位用户转向了 Glance。Glance 由开发者 glanceapp 于 2024 年初开源，迅速在 GitHub 上获得了超过 10,000 颗星，是近年来在自建社区颇受欢迎的一款仪表盘工具，它的定位与 CasaOS 有明显区别——它更强调"信息聚合"。Glance 的设计灵感部分来源于"startpage"（浏览器起始页）文化，即用户将浏览器默认页面替换为自定义的信息聚合页面。

Glance 采用 Go 语言编写，编译后为单一二进制文件，无需额外依赖即可运行，资源占用极低（通常仅需 10-30MB 内存）。Go 语言（又称 Golang）由 Google 于 2009 年发布，以编译速度快、内置强大的并发处理机制（goroutine）、部署极其简便而在基础设施工具领域广受青睐。Go 编译生成的是静态链接的二进制文件，将所有依赖都打包在可执行文件内部，这意味着用户可以直接下载一个文件即可运行，甚至不需要安装 Docker 或任何运行时环境。这种分发方式在自建社区中被称为"zero dependency"部署，特别适合资源受限的环境，如树莓派或低配 VPS。事实上，许多 Homelab 社区中流行的基础设施工具——如 Traefik（反向代理）、Caddy（Web 服务器）、AdGuard Home（DNS 过滤）——都采用 Go 语言编写，这绝非巧合。

Glance 可以在一个页面上同时展示 RSS 订阅、天气、股票行情、系统监控指标、Docker 容器状态等多种信息组件（widgets），还支持 Reddit 帖子流、Hacker News、YouTube 频道更新、GitHub Release 追踪等丰富的数据源。它采用 YAML 配置文件驱动，给了用户更大的自由度，可以按照自己的喜好排列各种信息卡片。YAML（YAML Ain't Markup Language）是一种人类可读的数据序列化格式，因其简洁的缩进语法而被广泛用于 DevOps 和基础设施配置领域。YAML 在 Homelab 中的广泛使用实际上是整个 IT 行业向声明式配置（Declarative Configuration）迁移的缩影——声明式配置描述的是系统的期望状态而非操作步骤，与之相对的命令式配置（Imperative Configuration）则逐步指定每一个操作。Docker Compose 的 YAML 文件就是典型的声明式配置——用户只需声明"我需要一个运行 Plex 的容器，映射端口 32400"，而无需手动执行创建网络、拉取镜像、启动进程等具体步骤。这种范式转变使得复杂系统的管理变得可预测、可复现。

与图形界面配置相比，YAML 配置文件的优势在于：可以通过 Git 进行版本控制，追踪每一次变更；便于备份和迁移，只需复制配置文件即可在新环境中重建完整的仪表盘；同时支持模板化和变量替换，在管理大量服务时效率远高于逐个点击配置。这也是为什么经验丰富的自建用户普遍倾向于"配置即代码"（Configuration as Code）方式的原因。

对于喜欢把仪表盘当作"个人信息中枢"的用户，Glance 是一个非常有吸引力的选择。这种"个人信息门户"的定位使其与 Homepage 形成了互补关系——事实上，有些用户会同时使用两者，分别作为浏览器起始页和服务管理面板。

阶段三：Homepage —— 最终的归宿

最终，这位用户选择了 Homepage 作为长期使用的方案。Homepage（github: gethomepage/homepage）是目前 Homelab 圈子里最流行的仪表盘之一，它使用 Next.js 框架构建，运行在 Node.js 环境之上，支持服务端渲染（SSR）以获得更好的首屏加载速度，在灵活性、美观度和服务集成能力之间取得了很好的平衡。

Next.js 是由 Vercel 公司开发的 React 元框架，在前端开发领域占据重要地位。它支持服务端渲染（SSR）、静态站点生成（SSG）和增量静态再生（ISR）等多种渲染策略。Homepage 选择 Next.js 的核心原因在于 SSR 能力——仪表盘页面在服务端完成渲染后直接发送完整 HTML 给浏览器，用户打开页面即可立即看到所有服务状态，无需等待客户端 JavaScript 加载和逐个 API 调用完成。这种架构在通过 VPN 远程访问（网络延迟较高）或在平板、手机等性能较弱的终端设备上浏览时优势尤为明显，能够显著改善用户体验。此外，Next.js 的 API Routes 功能允许 Homepage 在同一个项目中同时承载前端页面和后端 API 代理层，这意味着 Homepage 可以在服务端安全地存储和使用各服务的 API Key，而不会将这些敏感凭证暴露给浏览器端的 JavaScript 代码——这一安全架构设计对于可能通过公网访问仪表盘的用户尤为重要。Next.js 的增量静态再生（ISR）能力还允许 Homepage 缓存不经常变化的页面片段，减少对后端服务 API 的重复调用，在服务数量庞大时有助于降低网络开销。

Homepage 的核心优势在于其强大的服务集成能力。它内置了对上百种常见自建应用的 API 支持，能够直接显示各个服务的实时状态和关键数据——比如 Plex 正在播放的媒体、qBittorrent 的下载速度、Proxmox 的资源占用等。

这里值得展开说明的是，Homepage 之所以能成为社区主流选择，关键在于其"widgets"（小组件）系统的精巧设计。Homepage 维护了一个庞大的服务适配列表，每个适配器封装了对目标服务 REST API 的调用逻辑。REST（Representational State Transfer）API 是一种基于 HTTP 协议的通信接口标准，它使用标准的 HTTP 方法（GET、POST、PUT、DELETE）来操作资源，返回的数据通常为 JSON 格式。几乎所有现代自建应用都会暴露 REST API 供外部程序调用。在实际配置中，用户需要在目标服务中生成一个 API Key（通常在应用的设置页面完成），然后将该 Key 填入 Homepage 的配置文件。Homepage 随后会定期（通常每 10-60 秒）向目标服务发送 HTTP 请求获取最新数据。例如，当用户配置了 Plex 的 widget 后，Homepage 会通过 Plex 的 REST API 获取当前正在播放的媒体信息、活跃流数量等数据，并以可视化卡片的形式展示。这种 API 驱动的架构意味着仪表盘本身不需要直接访问服务的数据库或文件系统，而是通过标准化的接口进行"松耦合"的数据交换，在安全性和维护性上都具有显著优势。截至 2024 年，Homepage 已原生支持超过 100 种服务的 API 集成，且社区持续贡献新的适配器。这种"开箱即用的深度集成"与"完全可配置的灵活性"的结合，使其在众多仪表盘工具中脱颖而出。

在竞品方面，Homelab 仪表盘领域还有几个值得关注的替代方案：Homarr 提供了拖拽式的图形化配置界面，更适合不想编写 YAML 的用户；Dashy 以其极其丰富的主题和视觉定制选项著称，支持超过 50 种预设配色方案；Organizr 则侧重于与反向代理的深度整合，支持基于用户组的访问控制。Homepage 之所以能在这些竞品中脱颖而出，核心在于其 widget 生态的广度和深度——它不仅展示服务是否在线，还能展示服务内部的业务数据，这种深度集成能力是多数竞品所欠缺的。

文中提到的 Proxmox VE（Virtual Environment）则是 Homelab 社区中最受欢迎的虚拟化管理平台之一。它是一个开源的企业级虚拟化平台，基于 Debian Linux 构建，支持 KVM 虚拟机和 LXC 容器两种虚拟化技术。KVM（Kernel-based Virtual Machine）是 Linux 内核内置的全虚拟化方案，可以运行 Windows、Linux 等完整操作系统；LXC（Linux Containers）则是操作系统级容器，共享宿主机内核，资源开销远小于完整虚拟机。用户通常将 Proxmox 安装在一台物理服务器上，然后在其中创建多个虚拟机或容器来分别运行不同的服务。通过 Homepage 集成 Proxmox 的 API，用户可以直接在仪表盘上看到各个虚拟机的 CPU、内存、磁盘使用率以及运行状态，实现统一的资源监控视图。

而 Plex 和 qBittorrent 则是 Homelab 中所谓"媒体自动化栈"的代表性组件。一个完整的媒体自动化栈通常包括：Plex 或 Jellyfin（媒体服务器，用于流媒体播放）、Sonarr/Radarr（自动化追踪和管理电视剧/电影）、Prowlarr（索引器管理）、qBittorrent 或 Transmission（下载客户端）。这些工具通过 API 相互联动，形成了一条自动化的媒体获取和管理流水线——用户只需在 Sonarr 中添加想看的电视剧，系统便会自动搜索资源、下载、重命名文件、整理到媒体库目录中，并由 Plex 自动识别和提供流媒体播放。值得补充的是，Plex 与 Jellyfin 的选择是 Homelab 社区中一个经典的讨论话题：Plex 是闭源的商业软件，提供精良的客户端体验和远程串流功能，但部分高级功能需要付费订阅 Plex Pass；Jellyfin 则是完全开源免费的替代方案，由社区驱动开发，所有功能免费使用，但在客户端生态和硬件转码支持方面略逊于 Plex。Homepage 同时支持两者的 API 集成，用户可以根据自己的偏好选择。

除媒体栈外，常见的自建服务还包括 Pi-hole/AdGuard Home（DNS 级广告过滤）、反向代理、Vaultwarden（密码管理）、Nextcloud（私有云存储）等。

其中，Pi-hole 和 AdGuard Home 代表了一种与浏览器扩展截然不同的广告拦截思路。它们作为局域网的 DNS 服务器运行，当设备请求解析某个已知广告域名（如 ads.example.com）时，DNS 过滤器会返回空地址（0.0.0.0）而非真实 IP，从而在网络层面阻止广告内容加载。这种方式的优势在于保护范围覆盖局域网内所有设备（包括智能电视、IoT 设备等无法安装浏览器扩展的终端），且由于拦截发生在 DNS 解析阶段，被拦截的请求根本不会产生实际网络流量，从而节省带宽并加快页面加载速度。Pi-hole 还提供了丰富的查询日志和统计仪表盘，通过 Homepage 集成后，用户可以直接在主仪表盘上看到 DNS 查询总量、拦截比例等关键指标。

反向代理（Reverse Proxy）是 Homelab 架构中的关键基础设施组件，它位于用户浏览器和后端服务之间，负责将外部请求路由到正确的内部服务。例如，用户访问 plex.example.com 时，反向代理会自动将请求转发到内网中运行 Plex 的容器（如 192.168.1.100:32400）。主流的反向代理方案包括 Nginx Proxy Manager（提供图形化界面，适合新手）、Traefik（支持 Docker 标签自动发现服务，配置更为声明式）和 Caddy（以自动 HTTPS 证书管理著称，配置语法极其简洁）。反向代理还承担着 SSL/TLS 证书管理的重要职责，通常通过 Let's Encrypt（一个提供免费 SSL 证书的非营利证书颁发机构）自动获取和续期证书，确保所有自建服务都通过 HTTPS 加密访问，即使在局域网内部也能避免中间人攻击的风险。

Let's Encrypt 于 2015 年由 ISRG（互联网安全研究组）推出，通过 ACME（Automated Certificate Management Environment）协议实现了 SSL 证书的全自动申请和续期。在 Let's Encrypt 出现之前，SSL 证书需要向商业 CA 付费购买且手动安装，这导致绝大多数家庭自建服务都以未加密的 HTTP 方式运行。Let's Encrypt 的出现彻底改变了这一现状，其支持的 DNS-01 验证方式特别适合 Homelab 场景——用户无需将服务暴露到公网，只需通过 DNS 记录证明域名所有权即可获取通配符证书（如 *.home.example.com），为所有子域名提供统一的 HTTPS 加密。这使得即使完全运行在内网中的 Homelab 服务也能享受到与公网网站同等级别的传输层安全保护。

正是这些不断增长的服务，催生了对统一仪表盘的刚性需求。

同时，Homepage 完全通过配置文件管理，支持深度自定义的布局、图标和分组，配合自制的背景图，能打造出兼具实用性与视觉美感的仪表盘。

演进背后的逻辑：需求驱动工具选择

这条 CasaOS → Glance → Homepage 的进化路线，实际上映射了大多数自建爱好者的成长曲线：

从易用性优先到可控性优先。 新手阶段追求的是快速上手和低门槛，CasaOS 满足了这一点；随着经验积累和服务规模扩大，用户开始追求更高的定制自由度和更精细的控制能力，配置文件驱动的工具便逐渐取代了图形化的一键部署。

从功能堆砌到服务整合。 Glance 侧重于信息展示的丰富性，而 Homepage 则更强调与实际运行服务的深度联动。当仪表盘不再只是"好看"，而是真正成为运维的入口和监控中心时，服务集成能力就成了决定性因素。

值得一提的是，这位用户还提到自己制作了背景图。这个细节反映出 Homelab 文化中一个有趣的现象——仪表盘不仅是功能工具，也是个人审美和数字生活方式的表达载体。许多爱好者会花费大量时间打磨界面细节，追求所谓的"aesthetic"（美学）体验。在 Reddit 的 r/homelab 和 r/selfhosted 等社区中，"仪表盘秀"是最受欢迎的内容类型之一，用户们互相分享自己精心设计的界面，这种文化推动了 Homepage 等工具在视觉定制能力上的不断进化。

给自建新手的建议

如果你正准备搭建自己的家庭实验室仪表盘，这个案例提供了一些实用的参考：

• 不必一步到位。 从 CasaOS 这类友好的工具起步是完全合理的，先熟悉 Docker 和自建的基本概念。
• 明确核心需求。 如果你追求信息聚合，Glance 是不错的选择；如果你需要深度监控和管理众多服务，Homepage 会更合适。
• 拥抱配置文件。 虽然 YAML 配置有一定学习成本，但它带来的可控性、可移植性和版本管理便利，长期来看非常值得。将配置文件纳入 Git 版本控制是一个被广泛推荐的最佳实践——当你需要迁移服务器或回滚某次错误配置时，你会感激这个习惯。这一实践实际上是 DevOps 领域更广泛的 GitOps 运动在 Homelab 中的缩影。GitOps 的核心思想是以 Git 仓库作为基础设施和应用配置的唯一真实来源（Single Source of Truth）。在 Homelab 实践中，越来越多的用户将自己的 Docker Compose 文件、Homepage 配置、环境变量模板等全部存储在私有 Git 仓库中（如自建的 Gitea 实例）。更进阶的用户还会结合 Ansible（自动化配置管理工具，通过声明式的 Playbook 定义服务器的目标状态）或 Terraform（基础设施即代码工具，更侧重于云资源的创建和管理）来实现服务器的全自动化部署——理论上，即使服务器硬盘完全损坏，只需一个 Git 仓库和一条命令就能重建整个 Homelab 环境。此外，Renovate Bot 和 Dependabot 等自动化依赖更新工具也在 Homelab GitOps 工作流中发挥着越来越重要的作用。这些工具可以自动监测 Docker Hub 上镜像的版本更新，并在 Git 仓库中自动创建 Pull Request 来更新 Docker Compose 文件中的镜像标签版本号。用户只需审核变更内容并合并 PR，就能触发自动部署流程，将手动检查更新、修改配置、重启容器的繁琐流程简化为一次 Git 操作。这种"可重现性"正是配置文件驱动方式相对于图形界面操作的根本优势。
• 关注数据备份。 无论使用哪种仪表盘工具，确保你的配置文件和关键服务数据有可靠的备份策略。Homelab 社区中广泛推荐的"3-2-1 备份原则"——至少保留 3 份数据副本、存储在 2 种不同介质上、其中 1 份存放在异地——同样适用于仪表盘配置。结合前面提到的 Git 版本控制，你的仪表盘配置天然就满足了异地备份的要求（只要你使用了远程 Git 仓库），这也是配置文件驱动方式的又一个隐性优势。

结语

家庭实验室仪表盘的演变，本质上是用户与自己数字基础设施关系不断深化的过程。从 CasaOS 的初识，到 Glance 的探索，再到 Homepage 的深耕，每一次工具更迭背后都是需求的成长。对于自建爱好者来说，没有"最好"的仪表盘，只有"最适合当前阶段"的选择。而这种持续折腾、不断优化的过程本身，或许正是 Homelab 文化的魅力所在。

核心要点