fleetdm/fleet

如果你的团队正用脚本和多个零散工具管理 macOS、Windows、Linux 和移动设备，Fleet 值得认真评估：它把设备清单、MDM、补丁和软件部署收进一个可自托管的服务，并提供 API 与 GitOps 配置方式。它本质上是运维平台，不是开发者工具。

解决什么问题

IT 或安全人员想回答一个很具体的问题：哪些机器缺补丁、装了不该装的软件，或者没通过合规基线？现在通常要拼好几个 agent、表格和一次性脚本，下个月还得再问一遍。Fleet 用一个中心服务持续收集主机信息，并允许你改变设备状态——推送 MDM 配置、部署软件、执行脚本、核对基准——都在同一个地方完成。结果是形成可重复的盘点与修复流程，而不是一份不知道多久以前的快照。

有什么不同

Fleet 在 osquery（主机可见性）和 nanoMDM（Apple MDM）之上包了一层统一服务，对外提供 REST API、webhook、YAML 配置和 fleetctl 命令行。对实践 GitOps 的团队来说，配置即代码意味着设备策略和设置可以放进版本控制，而不是只能在管理后台点选；GUI、API 和 CLI 都是文档给出的入口。README 还强调模块化：可以只用 MDM 不用安全功能，也可以关掉不用的功能，这对只打算先迁移一部分场景的团队比较友好。

第二个差异是覆盖面。README 称其生产环境支持 Linux、macOS、Windows、Chromebook、iOS 和 Android，也覆盖云主机、容器等目标，并且把 Linux 当作一等公民而不是附带支持。对混合环境来说，这减少管理员要学的控制台数量；但配置项和权限范围也随之变大，工具好不好用最终取决于你写了什么策略。

谁值得试

适合：拥有几十到几千台设备、跨多个操作系统，团队里有人熟悉 API 或配置文件，并希望设备管理能自托管、可自行审计的 IT 或安全团队。需要 macOS/Windows CIS 基准报告和审计证据、又不想完全绑定闭源套件的组织也合适。

不适合：只管理一两台个人电脑的小团队，或者只想给一台笔记本装几个软件的人——部署服务、安装 agent、编写配置和策略的成本会超过收益。完全不想自托管的团队可以先看官方提供的试用和联系维护者渠道，再决定是否自己运维。

使用条件与边界

采用它意味着你要运行一个服务端，并在每台被管主机上装 agent，因此升级、备份和访问控制都由你自己负责。README 列出 CLI 与服务端的下载方式，具体平台前置条件和 MDM 注册要求要查文档；Apple MDM 还涉及证书和推送通知配置，不是放一个文件就能跑起来。免费版采用 MIT 许可，但许可证文件区分了付费功能，功能范围应按实际需要核对，而不能从“开源”二字直接推断。

长期成本更多在维护：策略、脚本和 YAML 配置需要随设备规模和操作系统版本持续复核，与 Splunk、Snowflake 或工单系统的集成也只有有人维护才真正有用。README 表示 Fleet 只采集管理和安全所需的数据；在把它当作审计证据来源之前，应核对文档中的表是否覆盖你的合规要求。

HotRepo 点评

HotRepo 只有一条带日期的记录：2026-10-28 为 7,062 stars，当天登上每日趋势榜，增加 8 颗星。单次快照无法判断关注度是在上升、持平还是下降，因此 2020 年的创建时间和 README 的生产案例只能作为背景，不能当作当前热度的证据。真正要在投入前确认的，是文档中对最少见操作系统的 MDM 注册与升级路径——如果这块说明很薄，自托管的承诺会很快变得昂贵。总体而言，对正在规划跨平台设备管理迁移的团队，它仍是一个可信的候选 项目 README、配置文档、CLI 下载。