连 SSH 终端都做成了可卸载插件，Termix 重构后的自托管服务器面板值不值得换

管理十几台服务器的日常，大多是这样的：一个 SSH 客户端开终端，一个 SFTP 工具传文件，浏览器里再开 Portainer 看容器，偶尔还得用 RDP 连一台 Windows 机器。工具一多，主机列表和密钥就散落在好几个地方，换台电脑又得重新配一遍。

开源项目 Termix 想做的，就是把这些工作收进一个可以自己部署的面板里。官方的定位很直白：“一个免费、自托管的 Termius”。半年多前它被推荐时还是 6.8k Star 的“一站式服务器管理平台”，如今已经涨到 1.5 万 Star，最新版本 v26.10.1 发布于 2026 年 10 月 12 日，采用 Apache-2.0 协议，主体用 TypeScript 编写。

更大的变化在架构上：Termix 已经重构为“核心 + 插件”模式，连 SSH 终端本身都变成了一个可以关闭、卸载的插件。本文梳理这次重构后的能力边界、部署方式和插件开发模型，并用一个小脚本模拟核心加载插件时要做的几道检查。

一、核心只管四件事：主机、凭据、用户、会话

按照官方 README 的说法，Termix 的核心只保留“你的主机、凭据、用户、共享和会话”，其余功能全部是插件。不装任何插件时，核心提供的能力包括：

主机管理：主机可以放进多级文件夹、打标签、设置父主机（跳板），支持批量编辑、导入导出，以及一次性连接的 Quick Connect。
凭据复用：密码和密钥保存一次，多台主机共用；还可以按服务器、用户或文件夹设置默认凭据。
共享与角色：主机、凭据和文件夹可以共享给用户或角色，权限分为连接、查看、编辑、管理四级。
账户与审计：本地账户、可查看并吊销的会话、受信设备、API Key 和审计日志。
安全：密码、密钥等机密按用户加密，数据库本身也可以开启落盘加密。
桌面同步：桌面版可以独立运行，也可以连接 Termix 服务器，保留一份账户的离线副本。
界面：标签页与分屏、命令面板（双击左 Shift）、可重绑的快捷键、主题与品牌定制，以及约 30 种界面语言。
数据库：默认 SQLite，也支持 PostgreSQL 和 MySQL。

这个划分很有讲究。主机清单和凭据是团队最敏感、最需要统一治理的数据，留在核心里集中加密和授权；而终端、文件管理、容器这些“使用方式”则各自独立迭代，出了问题也只影响单个插件。

二、34 个官方插件，按用途分组看

官方插件随 Termix 一起发布，管理员可以在 Plugins 页面安装、更新或删除，每个插件都有独立的代码仓库。README 里列出了 34 个，按用途大致可以分成五组：

分组	插件	说明
连接与终端	SSH Terminal、Remote Desktop、Serial、Tunnels、Tmux Monitor、Web Endpoint	SSH 标签与分屏、浏览器内 RDP/VNC/Telnet、串口控制台、自动重连的端口转发、跨主机管理 tmux、在 Termix 内打开主机的 Web 界面
文件与容器	File Manager、Docker、Proxmox	基于 SFTP 的文件管理（支持服务器之间直传）、通过 SSH 管理 Docker 和 Podman、导入并同步 Proxmox VE 虚拟机
认证与安全	SSO、LDAP、Passkeys、TOTP、HashiCorp Vault、Step CA、OPKSSH、Termix Identity、Secret Sources、Warpgate、ACME Certificates	OIDC/LDAP 登录、通行密钥与两步验证、短期 SSH 证书、从 1Password 拉取凭据、经 Warpgate 堡垒机连接、自动申请 HTTPS 证书
运维与协作	Fleets、Automations、Snippets、Alerts、Session Recording、Session Sharing、Workspaces、AI Assistant	主机分组批量执行、定时或事件触发的自动化、常用命令片段、统一告警、会话录制与共享、保存标签布局、读取配置并提出变更建议的 AI 助手
可视化与其他	Host Metrics、Network Topology、Homepage、Tailscale、Wake-on-LAN、Usage Statistics	CPU/内存/磁盘/GPU 实时指标、主机拓扑图、拖拽式首页、接入 Tailscale 设备、网络唤醒、匿名使用统计

几个插件值得单独一提。Step CA、HashiCorp Vault 和 OPKSSH 三个插件都在做同一件事：用短期 SSH 证书代替长期私钥。证书过期即失效，离职或设备丢失时不必满世界轮换公钥，这是比“把私钥加密存进面板”更彻底的做法。Fleets 则把单机终端扩展到了批量运维，可以对一组主机同时执行命令、包管理操作和文件传输。

除了官方插件，Termix 还支持社区仓库（Community Registry）。管理员在 Plugins 的 Registries 设置里开启后，就能安装其他人发布的插件，也可以搭建自己的私有插件仓库。

三、部署：一个容器起服务，远程桌面再加一个 guacd

Termix 支持网页、桌面和移动端：网页版支持 PWA；Windows、Linux、macOS 都有安装包和包管理器渠道；iOS/iPadOS 和 Android 也有官方应用。服务端推荐用 Docker Compose 部署，官方示例如下：

services:
  termix:
    image: ghcr.io/termix-ssh/termix:latest
    container_name: termix
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - termix-data:/app/data
    environment:
      PORT: "8080"
      GUACD_HOST: "guacd"
      GUACD_TUNNEL_HOST: "termix"
      GUACD_RECORDING_PATH: "/termix-data/session_recordings/guacamole"
      GUACD_DRIVE_PATH: "/termix-data/rdp-drive"
    depends_on:
      - guacd
    networks:
      - termix-net

  guacd:
    image: guacamole/guacd:1.6.0
    container_name: guacd
    restart: unless-stopped
    volumes:
      - termix-data:/termix-data
    networks:
      - termix-net

volumes:
  termix-data:
    driver: local

networks:
  termix-net:
    driver: bridge

guacd 是 Apache Guacamole 的协议代理，负责把 RDP、VNC 协议转成浏览器能渲染的数据流。如果你不打算用远程桌面插件，可以把 guacd 服务和自定义网络一起删掉，只留 termix 一个容器。执行 docker compose up -d 之后访问 8080 端口即可。想先体验的话，官方演示站 demo.termix.site 任意用户名和密码都能登录。

部署位置有一个官方特意提醒的细节：如果 Termix 跑在它所管理的那张网络里，网络一出故障，它会在你最需要的时候跟着失联。 因此官方建议把它放在一台独立的 VPS 上，有固定 IP，不依赖 VPN 或端口转发就能从任何地方访问。这和“监控系统不能和被监控对象部署在一起”是同一个道理。

四、插件是怎么接入核心的

插件化之后，开发者最关心的是：写一个插件要碰多少东西？官方提供了一个 Hello World 模板仓库，结构很小，但覆盖了大多数插件需要的部件：一个侧边栏标签页、两个受权限保护的 API、一个管理员设置项、一张带三种数据库迁移的表，以及测试和发布流水线。

一切从 manifest.json 开始。它声明插件的身份、兼容的核心版本、需要的能力和向核心“贡献”的界面元素：

{
  "id": "hello-world",
  "version": "1.0.0",
  "engine": { "termix": ">=26.10.0", "api": "^1.2" },
  "capabilities": ["db:own", "network:serve", "ui:surface"],
  "contributes": {
    "tabs": [{ "id": "hello-world", "titleKey": "tab.title", "icon": "Hand", "openFrom": ["rail"] }],
    "permissions": [{ "name": "use", "defaultRoles": ["admin", "user"] }],
    "settings": { "admin": [{ "key": "greeting", "type": "string", "default": "Hello" }] }
  },
  "platforms": ["linux", "win32", "darwin"]
}

插件清单经过检查后接入核心的流程

连 SSH 终端都做成了可卸载插件，Termix 重构后的自托管服务器面板值不值得换

后端入口只有两个函数。activate 拿到核心注入的上下文 ctx，通过它定义数据表、注册路由；deactivate 甚至可以留空，因为“通过 ctx 注册的一切都会由核心回收”：

export async function activate(ctx: PluginContext) {
  const notesTable = await ctx.db.define(notes);
  registerRoutes(ctx.http.router<Router>(), ctx, notesTable);
}

export async function deactivate() {
  // Everything registered through ctx is disposed by core.
}

路由层第一行就挂上了权限中间件 ctx.rbac.require("use")，对应 manifest 里声明的 use 权限；查询时用 ctx.currentActor() 限定为当前用户的数据。数据表则通过 SDK 的 defineTable 声明，实际表名会自动加上插件前缀，notes 会变成 p_hello_world_notes，再由 npm run migrations 一次生成 SQLite、PostgreSQL 和 MySQL 三套迁移脚本。

Mermaid Diagram

开发流程也做得比较顺手：在 Termix 设置里打开插件开发者模式、生成 API Key，然后运行 npx termix-plugin dev --server http://localhost:30001 --key tmx_your_key，每次保存文件都会自动重新构建并安装到服务器。发布时用 GitHub Actions 打包出 .tmxplug 文件并记录构建来源证明，提交到社区仓库后，每个版本都要经过人工审核才会上架。

五、动手实验：模拟核心加载插件的几道关卡

插件架构的安全性很大程度上取决于核心在加载前做了哪些检查。为了把上面的机制具体化，我用 Python 写了一个小模拟器：插件清单的字段结构取自官方模板，检查规则则是根据模板文档推演的简化版，并非 Termix 源码。

模拟的核心版本为 26.10.1、插件 API 为 1.3，依次尝试加载四个插件：官方模板 hello-world、一个只申请 SSH 能力的 disk-report、一个要求更高核心版本的 legacy-stats，以及一个命名不规范、申请读取凭据和未知能力的可疑插件。检查项包括：插件 id 格式、核心版本与 API 主版本兼容性、能力是否在白名单内、是否申请了敏感能力。通过后再生成带前缀的表名、路由和权限名。

def engine_ok(spec):
    min_core = parse(spec["termix"].lstrip(">="))
    api = parse(spec["api"].lstrip("^") + ".0")
    api_ok = api[0] == CORE_API[0] and api[:2] <= CORE_API[:2]
    return CORE_VERSION >= min_core and api_ok


def activate(p, registry):
    prefix = "p_" + p["id"].replace("-", "_") + "_"
    tables = [prefix + t for t in p["tables"]]
    routes = f"/plugin-api/{p['id']}/*"
    perms = [f"{p['id']}.{x['name']}" for x in p["contributes"]["permissions"]]
    registry[p["id"]] = {"tables": tables, "routes": routes, "permissions": perms}
    return registry[p["id"]]

运行 python3 plugin_host_sim.py 的输出：

Termix 核心 26.10.1，插件 API 1.3.0

[启用] hello-world@1.0.0  能力=db:own,network:serve,ui:surface
       表: ['p_hello_world_notes']  路由: /plugin-api/hello-world/*  权限: ['hello-world.use']
[启用] disk-report@0.3.0  能力=ssh:connect,ui:surface
       表: 无  路由: /plugin-api/disk-report/*  权限: ['disk-report.run']
[拒绝] legacy-stats@2.1.0
       - 引擎不兼容：需要 {'termix': '>=27.0.0', 'api': '^2.0'}，当前核心 26.10.1 / API 1.3
[拒绝] Cred_Dump@0.0.1
       - id 必须是小写字母加连字符
       - 未知能力声明 ['fs:root']
       - 申请读取凭据，需要管理员人工审核

停用 hello-world：核心回收它通过 ctx 注册的路由与权限，数据表保留
当前已启用插件： ["disk-report"]

从输出能看清插件隔离的三个层面：命名空间隔离（表名和路由都带插件 id 前缀，插件之间不会互相覆盖）、权限隔离（每个插件的权限都以自己的 id 为前缀注册进 RBAC）、生命周期隔离（停用时由核心统一回收注册项）。模板里 hello-world 的 SQLite 迁移脚本也印证了第一点，生成的表名正是 p_hello_world_notes，并通过外键关联核心的 users 表、在用户删除时级联清理。

六、上生产前要想清楚的几件事

Termix 的定位决定了它会成为“钥匙串的钥匙串”：拿下这个面板，就等于拿下了它管理的所有服务器。部署前建议逐条过一遍：

1. 强制 HTTPS 和多因素登录。ACME Certificates 插件可以自动申请并续期证书；TOTP 或 Passkeys 插件给登录加第二道门。不要把 8080 端口裸露在公网上。

2. 优先用短期证书代替长期私钥。已有 Vault、step-ca 或 OIDC 体系的团队，用对应插件签发短期 SSH 证书，比把私钥存进面板安全得多。

3. 谨慎开启社区插件仓库。官方仓库之外的插件虽有人工审核和构建来源校验，但插件代码终究会在你的 Termix 服务器上执行，能接触到的资源取决于它声明的能力。安装前看清楚它申请了什么。

4. 留意遥测插件。Usage Statistics 插件会每天发送一份匿名使用报告。对内网合规有要求的团队，可以直接在插件页把它移除。

5. 数据库加密与备份。机密数据按用户加密，但别忘了同时开启数据库落盘加密，并把 termix-data 卷纳入备份计划。

6. 演示站只用于体验。demo.termix.site 任意账号都能登录，千万不要在上面填写真实主机和凭据。

和商业版 Termius 相比，Termix 的优势是完全自托管、没有付费档位（项目靠捐赠维持）、团队共享和审计能力内置；代价是需要自己承担运维和安全加固。如果只是个人管理几台机器，一个好用的 SSH 客户端加 ~/.ssh/config 往往就够了；当主机数量和协作人数上来，需要统一的权限、审计和短期证书时，Termix 这类自托管面板的价值才会真正体现。

七、总结

Termix 这次重构最值得关注的不是插件数量，而是边界划分：核心只管主机、凭据、权限和会话这些需要集中治理的数据，终端、文件、容器、远程桌面等使用方式都下放为插件，各自独立迭代、按需启停。对开发者来说，一个 manifest、一个 activate 函数、一个带前缀的数据表，就能给团队的运维面板加上自定义能力。

值不值得换，取决于你的规模和安全诉求。几台机器的个人用户可以先在演示站感受一下交互；有团队协作、合规审计和证书化登录需求的场景，Termix 是一个值得认真评估的开源选项。

开源地址：https://github.com/Termix-SSH/Termix