只在内网用 ToolJet 可以吗——自托管和权限要先定哪些?

文章导读
只在内网用 ToolJet,通常可以,但前提不是“装起来能打开”,而是先定三组边界:实例启动是否依赖外网、管理员账号从哪来、谁能看到哪些应用。内网离线环境里,镜像、邮件、第三方登录三项最容易在初始化或邀请成员时卡住;权限则要在发布第一个应用前就分好工作区和角色,否则后面补权限会变成逐个应用调整。
📋 目录
  1. 一 先确认实例的对外依赖有哪些
  2. 二 确定账号来源与登录方式
  3. 三 划分工作区与成员角色
  4. 四 用两个不同角色的账号做一次可见性验证
  5. 五 记录内网环境的后续维护检查点
A A

只在内网用 ToolJet,通常可以,但前提不是“装起来能打开”,而是先定三组边界:实例启动是否依赖外网、管理员账号从哪来、谁能看到哪些应用。内网离线环境里,镜像、邮件、第三方登录三项最容易在初始化或邀请成员时卡住;权限则要在发布第一个应用前就分好工作区和角色,否则后面补权限会变成逐个应用调整。

内网自托管 ToolJet 的关键不是能不能装,而是先定三件事:实例启动是否依赖外网、管理员账号从哪来、应用和工作区怎么隔离给不同人看。建议先在内网跑通离线镜像导入、本地账号登录和一条最小权限规则,再用两个账号验证可见性。邮件、OIDC/SAML 等能力可以后补,但补之前要确认内网 IdP 可达、回调地址正确。边界是:任何依赖外网且未替换的项,都可能让邀请、登录或升级流程失败。

先确认实例的对外依赖有哪些

自托管组件通常以容器方式运行,启动时首先要能拿到镜像。如果内网没有镜像仓库,建议在一台能访问镜像源的机器上拉取并导出,再导入内网。检查时先看 compose 文件里引用了哪些镜像和外部地址:

docker compose config | grep -iE 'image|smtp|mail|oidc|saml|oauth|host|url'
docker compose pull
docker save tooljet/tooljet-ce:latest -o tooljet-ce.tar
docker load -i tooljet-ce.tar

上面的镜像名和标签需要替换成你实际使用的版本。邮件依赖要看 SMTP 配置:如果内网没有邮件中继,可以把邀请邮件、通知邮件先关闭,改为管理员在后台手动创建用户。SMTP 的配置位置通常在 .env 或 compose 的环境变量段,也可能在管理后台的邮件设置里,具体以部署版本为准。第三方登录依赖同理:OIDC、SAML、Google、GitHub 这类登录都要求回调地址可达。内网若没有对应的身份提供方,建议先只保留本地账号;若内网已有 IdP,也要先确认 ToolJet 到 IdP 的网络连通、证书和回调 URL 再做开启动作。

确定账号来源与登录方式

首次初始化时,通常通过浏览器访问内网地址,按页面提示创建第一个管理员。部分版本支持用环境变量预设管理员邮箱和密码,但变量名和是否生效需要结合你部署的版本确认,不建议直接照搬旧教程。管理员创建完成后,先退出再登录一次,确认本地账号可独立工作。

可选登录方式一般包括本地账号、OIDC/SAML、第三方 OAuth。内网环境建议按这个顺序推进:先本地账号,再按需接内网 IdP。开启位置通常在环境变量或管理后台的认证设置中。前置条件包括:客户端 ID 与密钥、内网可解析的回调域名、受信任的证书、用户属性映射规则。对于组同步、自动创建用户这类能力,未实际验证前只把它当作判断方向,不要先依赖它做权限设计。

TOOLJET_HOST=http://tooljet.intra.example
# 邮件:离线环境可先留空或关闭邀请
SMTP_HOST=
SMTP_PORT=
SMTP_USER=
SMTP_PASSWORD=
# SSO:确认 IdP 可达后再填
OIDC_CLIENT_ID=
OIDC_CLIENT_SECRET=

变量名以实际版本为准。改完后重启服务,用未登录窗口访问一次,确认登录页只显示你允许的入口。

划分工作区与成员角色

ToolJet 的权限通常按层级理解:实例级管理员管全局设置;工作区承载应用和成员;工作区内的成员或组再绑定角色;角色决定能否管理成员、创建应用、编辑应用或只运行应用。设置入口一般在工作区设置、用户管理、组与权限、应用分享这些页面里,不同版本的名称可能略有差异。

只在内网用 ToolJet 可以吗——自托管和权限要先定哪些?

建议先建工作区,再添加成员,最后发布应用并按组授权。角色变化后,页面上的可见差异需要实际观察:管理员能看到设置、用户和数据源管理;编辑者能创建和修改应用;查看者通常只能看到被授权应用的运行界面。如果一个账号不在该工作区,它登录后不应看到这个工作区的应用入口;如果角色被移除,刷新后应用可能从列表消失,或打开时提示无权限。

用两个不同角色的账号做一次可见性验证

准备两个测试账号:账号 A 作为管理员或编辑者,账号 B 作为普通查看者。用管理员分别创建,并分到同一个工作区,但给不同角色。不要用同一浏览器会话切换,建议用两个浏览器或一个隐身窗口,避免缓存影响判断。

  1. 账号 A 登录,创建一个最小应用,比如只放一段文本和一个输入框。
  2. 发布应用,并把应用访问权限授予账号 B 所在的组或账号 B。
  3. 账号 A 访问该应用,应能看到编辑入口、数据源配置和工作区管理入口。
  4. 账号 B 登录后访问同一应用,应能看到运行界面,但不应该看到编辑按钮、数据源凭据、成员管理或工作区设置。
  5. 再用账号 B 访问一个未授权应用,应该看不到入口,或打开时被拒绝。

如果账号 B 看不到已授权应用,按顺序检查:账号 B 是否已加入工作区、组是否绑定了应用、应用是否已发布、角色是否包含查看权限。如果账号 B 看到了编辑入口,说明角色或应用权限给多了,需要回到工作区权限设置里收紧。

记录内网环境的后续维护检查点

长期可用的前提是知道日志、数据卷和配置分别在哪里。日志通常用 compose 查看,数据卷则要回到 compose 文件里的 volumes 段确认,数据库数据和上传文件通常分开存放。

docker compose ps
docker compose logs `--tail`=200
docker volume ls
docker compose exec db pg_dump -U postgres tooljet > backup.sql

上面的服务名、数据库用户名和库名需要按实际部署替换。升级前建议先备份数据库、上传文件所在卷、.env 和 compose 文件,以及反向代理配置。端口或访问地址变更时,要同步修改 TOOLJET_HOST、容器端口映射、反向代理规则、OIDC/SAML 回调地址、邮件里的链接地址和对外 Webhook 地址。改完后从不同网段访问一次,确认登录、应用打开和文件上传没有因为地址变化而失败。