Fleetd v0.3.0：让软路由主动连回后台，命令权限留在客户端
服务器和软路由数量不多时，管理它们看起来不难：查看状态用 SSH，服务出问题查日志，要更新软件就执行几条命令。真正的麻烦是这些入口分散在不同地方——服务器一套、软路由一套；发现异常后，还要重新定位机器、确认环境，才能开始处理。
Fleetd 是一个可自行部署的服务器与软路由管理工具，MIT 协议开源，首个公开版本为 v0.3.0，中英文文档同步上线。
从“看到问题”到“处理问题”的入口
监控能提示磁盘快满了，但接下来还要查哪个目录在增长；知道某个服务失败了，也得继续看日志、检查配置，再决定是否重启。对维护少量机器的人来说，这些动作通常是连在一起的。Fleetd 的目标是让后台保留这条链路，减少在几个工具之间反复查找同一台机器。
目前功能分为几块：
- 机器监控：CPU、内存、负载、磁盘和网络速率，保留 7 天历史
- 运行状态：失败的 systemd 服务、Docker 容器、WireGuard 对端等信息
- 告警：机器离线、资源持续超限、磁盘空间不足及相关服务异常，可配置邮件通知
- 远程命令：对一台或多台机器执行经过签名、且符合客户端权限的命令
- 网页终端：在允许完整操作权限的机器上打开交互终端
- 客户端管理：批准新机器接入，分发经过签名的客户端更新包
这些信息需要结合机器环境理解。systemd 服务状态只适用于运行 systemd 的系统，不能拿同一套服务列表去要求 OpenWrt；WireGuard 的握手时间也只是排查线索，脱离流量和配置不能直接等同于线路故障。
定位于“让异常留下一个可以继续查下去的入口”。复杂监控规则、长期数据分析、完整的配置编排，仍交给擅长这些工作的工具。
架构：一台服务端，每台机器一个客户端
服务端负责管理页面、机器记录、监控数据和操作记录，数据存在 PostgreSQL。被管理的 Linux 机器上运行一个客户端，负责采集状态、接收请求，并决定是否执行。
后台用 Vue 3 编写，构建后嵌入 Go 服务端程序。客户端同样是 Go 程序，发布 Linux amd64 和 arm64 两种架构。实际安装仍要核对设备架构——一台设备运行 OpenWrt，并不意味着现成的二进制一定能用。
这个结构对部署者的好处是边界清晰：服务端一处，数据库一处，每台被管理机器上有自己的客户端和配置。排查问题时可以顺着边界走：客户端有没有连上、数据有没有上报、请求有没有到达、客户端为什么接受或拒绝。
软路由接入：先解决连接方向
云服务器和家里的软路由网络条件常常不同。服务器可能有公网地址，软路由通常在 NAT 后面。为了管理一台机器而额外开放公网入口，会增加配置和维护负担。
Fleetd 采用客户端主动连接服务端的方式：只要被管理机器能访问服务端的连接地址，就不需要为客户端开放入站管理端口。这适合把不同网络里的 Linux 服务器、OpenWrt 或 iStoreOS 设备接到同一个后台。代价是服务端本身仍需一个客户端可访问的地址，正式使用要按文档配置 HTTPS 和 WebSocket 转发。
连接建立后，新机器不会立即成为可操作对象。它先出现在“等待批准”里，管理员核对安装端与后台显示的指纹，再决定批准或拒绝。主机名可以起得一样，界面上多出一个条目不能代替身份核对。
能看到机器，不等于可以随意操作机器
把远程命令放进监控后台之后，权限问题就变得很实际：一台机器可能只需要上报状态；另一台可以接受几个固定的维护动作；只有部分机器需要完整的命令和终端能力。它们不应该因为出现在同一个后台里，就默认拥有相同的操作范围。
Fleetd 把这一决定放在客户端本地配置里，分三级：
monitor：只监控，不执行远程命令allowlist：只执行本地预先定义的动作full：允许任意命令和网页终端
命令还必须在管理员浏览器里签名，客户端用自己信任的公钥验证，并检查目标、有效期和本地权限。服务端只负责转发，不能仅凭一条普通请求就让客户端执行。
这套设计减少的是客户端对服务端指令的盲目信任，前提要说完整：浏览器和它运行的前端代码也必须可信。管理页面由服务端提供，若服务端被篡改，后续打开的页面同样可能被替换。私钥不可导出，不等于恶意页面无法尝试调用签名。因此，不能因为加了命令签名，就断言服务器失陷后整套系统仍然绝对安全。
初期比较实用的做法是：只需要监控的机器保持 monitor；能用固定动作解决的事情优先用 allowlist；确实需要完整终端时再开放 full。
更新客户端：发布包也要有自己的信任依据
设备分散之后，更新客户端是一项日常工作。每台机器手动复制程序很快会变得繁琐；让客户端下载一个文件就直接运行，又把更新来源的问题留了下来。
Fleetd 使用签名发布包：发布者在自己的环境中生成更新包并签名，客户端依据预先配置的发布公钥校验。命令签名与程序发布签名是用途不同的两个机制，不应混在一起管理。
这也意味着 GitHub Releases 里的文件要分清用途。普通客户端二进制可用于相应架构的手动部署；带签名的 .release 包只有在客户端信任对应发布公钥时才适用。自行部署的人应当按文档建立自己的发布密钥和更新流程——上传了作者的签名包，不代表它会被任意一套自建环境接受。
试用路径：从 Docker Compose 开始
git clone https://github.com/weiyi0/fleetd
cd fleetd
git checkout v0.3.0
docker compose up -d
docker compose run --rm fleetd admin-add admin
创建管理员时按提示设置密码，然后访问 ，后台支持中文和英文。
当前 Compose 配置会从源码构建服务端，并启动 PostgreSQL，因此首次运行需要下载依赖、构建程序，耗时取决于本机和网络环境。机器记录、监控数据与操作记录都落在 PostgreSQL 里，备份时不能只备份服务端配置。
这一步只是把后台启动起来，还没有接入任何机器，Docker 镜像也不会顺带生成签名客户端发布包。接下来可以按快速开始文档编译并手动运行一个客户端，体验机器接入；准备长期使用时，再配置自己的发布密钥、上传签名客户端包，通过后台提供的安装方式接入设备。
默认 Compose 示例面向试用，包含示例数据库凭据，8480 端口也不只绑定回环地址。本机体验时应限制网络访问；准备通过网络使用前，按部署文档修改凭据、配置 HTTPS，并做好数据库和密钥备份。
建议先接一台便于维护的测试机器：核对指纹、查看状态，再试验它允许执行的操作。完整流程跑通之后再逐步接入其他机器，更容易发现配置差异。
为什么从 v0.3.0 开始公开
第一个公开版本定为 v0.3.0，是因为此前使用环境中的客户端已经到 0.2.0。项目的更新机制要求目标版本比当前版本更新，公开版本沿用了这个序列。
Fleetd 适合的场景是：希望自己掌握数据、维护少量 Linux 服务器和软路由，并愿意理解基本部署与权限配置。它不把自己定位成现有运维工具的替代品——监控、自动化、配置管理都有成熟方案。Fleetd 先把自身场景做扎实：把机器状态、告警和必要的维护操作连起来，同时让每台机器保留清楚的权限边界。