ToolJet 3.20 常用 CLI 命令与工具详解

目标：把 ToolJet v3.20.246-lts 日常运维要用的三组命令工具一次讲全——Compose 服务编排命令组、官方 CLI（@tooljet/cli）、主服务内置运维脚本（数据库迁移/插件管理/账号恢复/密钥轮换），每条命令给出实测输入与真实回显，帮助读者把「部署完成」变成「运维上手」。本文全部命令与回显均在 Ubuntu 22.04 服务器实测采集（2026-10-21），可直接照抄执行。

一、环境信息

本文所有命令与回显均在下列环境实测（2026-10-21）：

• 操作系统：Ubuntu 22.04.4 LTS（x86_64）
• ToolJet：v3.20.246-lts 社区版，按官方 Docker Compose 方案部署（部署过程见《ToolJet 3.20 Docker Compose 部署指南》），部署目录 /opt/tooljet
• 编排工具：Docker Compose v5.5.1（实测 docker compose version 回显见 4.1.6）
• 主服务运行时：Node.js 22.15.1、npm 10.9.2（实测 tooljet info 回显见 4.2.3）
• 服务验证：健康检查 curl http://localhost:8137/api/health 实测返回 {"works":"yeah","license":{"valid":false,"expired":true}}
• 标注约定：【实测】= 本文环境中真实执行采集的回显；【实查】= 官方文档/包元数据实查（查询日期 2026-10-21）

二、工具概览

ToolJet 的命令面由三组构成，职责不同、入口不同，先看全景再逐组上手：

💡 技术拓展：选命令入口时的判断逻辑——管理「这套服务怎么跑」用 Compose 命令；开发「数据源连接器插件」用官方 CLI；处理「平台自身的库/账号/密钥」用内置运维脚本。三组不互相替代：例如重置管理员口令不能靠重启服务（Compose 命令不改变数据），必须走 reset 脚本；而创建插件脚手架靠 Compose 命令无从下手，CLI 才是正道。

三组工具的详细用法见第四章：Compose 命令组见 4.1，官方 CLI 见 4.2，内置运维脚本见 4.3。

三、前置条件

1. 已按《ToolJet 3.20 Docker Compose 部署指南》完成部署并可通过健康检查（本文实测环境健康检查回显正常）；
2. 能在部署目录（/opt/tooljet）执行 docker compose 命令；
3. 能进入主服务排障（docker compose exec tooljet sh）以运行内置脚本；
4. 使用官方 CLI 需要服务器可访问 npm registry（离线环境可将 npm 包下载后离线安装，本文不展开）。

进入主服务排障环境的标准入口（后续 4.3 的内置脚本都在这个环境里执行）：

cd /opt/tooljet
docker compose exec tooljet sh

【实测】执行后进入主服务内部（提示符切换为服务内 shell），pwd 显示工作目录为 /app：

/app #

四、各工具详解

4.1 Compose 编排命令组

Compose 命令组负责服务编排层的一切操作。以下命令均在部署目录 /opt/tooljet 中执行（先 cd /opt/tooljet，下同）。

4.1.1 查看服务状态：docker compose ps

排查「服务是否正常」的第一条命令，显示每个服务的运行状态、端口映射与存活时长：

cd /opt/tooljet
docker compose ps

实测输出：

NAME                            IMAGE                                                                     COMMAND                   SERVICE    CREATED       STATUS       PORTS
tooljet-3.20.246-lts-app        tooljet/tooljet-ce:v3.20.246-lts                                          "./server/entrypoint…"   tooljet    7 hours ago   Up 7 hours   0.0.0.0:8137->80/tcp, [::]:8137->80/tcp
tooljet-3.20.246-lts-postgres   sha256:ca0bd484cb98bf4b24eb1010e73fb3fcbd6714d240fbc1a10eea5b7dbecb641d   "docker-entrypoint.s…"   postgres   7 hours ago   Up 7 hours   5432/tcp

解读：STATUS 列应为 Up；PORTS 列确认对外端口映射（实测环境 8137->80，即宿主机 8137 端口转发到服务内 80 端口）；postgres 服务无对外端口映射（仅内部网络可达，属正常安全设计）。

4.1.2 服务清单与对外端口确认：config --services / port

改动部署文件后，先确认 Compose 实际识别的服务清单与端口绑定，避免「改了没生效」：

docker compose config --services

实测输出：

postgres
tooljet

查询 tooljet 服务 80 端口绑定的宿主机地址：

docker compose port tooljet 80

实测输出：

0.0.0.0:8137

解读：config --services 列出部署文件中 Compose 实际生效的服务名；port 输出格式为 <绑定地址>:<宿主机端口>，用它核对 TOOLJET_HOST 应填的对外地址与端口（本例即 http://<服务器IP>:8137）。

4.1.3 查看与跟踪日志：docker compose logs

排障第二入口。--tail N 只看最近 N 行，-f 持续跟踪（Ctrl+C 退出）：

docker compose logs --tail 3 tooljet

实测输出（ORM_LOGGING=error 配置下的常规运行日志，含定时清理任务与慢查询审计行）：

tooljet-3.20.246-lts-app  | starting job to clear expired pat and sessions at  2026-10-21T15:00:00.010Z
tooljet-3.20.246-lts-app  | {"level":"info","time":1792595040010,"pid":148,"hostname":"54b49f6017ea","msg":"QUERY (2 ms): SELECT a.id FROM ai_attachments a\n        WHERE state <> 'deleting' AND next_cleanup_at <= now()\n        ORDER BY next_cleanup_at, id LIMIT 100 FOR UPDATE SKIP LOCKED"}
tooljet-3.20.246-lts-app  | {"level":"info","time":1792595280009,"pid":148,"hostname":"54b49f6017ea","msg":"QUERY (2 ms): SELECT a.id FROM ai_attachments a\n        WHERE state <> 'deleting' AND next_cleanup_at <= now()\n        ORDER BY next_cleanup_at, id LIMIT 100 FOR UPDATE SKIP LOCKED"}

解读：日志前缀为服务名；JSON 格式行是结构化业务日志（msg 字段为内容）。跟踪实时日志用 docker compose logs -f tooljet，查看 postgres 日志把服务名换成 postgres。

4.1.4 进程与资源视角：top / stats

需要区分「服务进程」与「数据库进程」的资源占用时用这一组。查看服务内进程树：

docker compose top

实测输出节选（实测首尾，保留 tooljet 全部进程与 postgres 首行）：

SERVICE   #   UID    PID      PPID     C   STIME  TTY    TIME      CMD
tooljet   1   yahui  3700319  3700280  0   16:12  pts/0  00:00:00  npm run start:prod
tooljet   1   yahui  3700377  3700319  0   16:12  ?      00:00:29  redis-server 127.0.0.1:6379
tooljet   1   yahui  3700769  3700319  0   16:13  pts/0  00:00:00  sh -c npm --prefix server run start:prod
tooljet   1   yahui  3700770  3700769  0   16:13  pts/0  00:00:00  npm run start:prod
tooljet   1   yahui  3700781  3700770  0   16:13  pts/0  00:00:00  sh -c NODE_ENV=production node dist/src/main
tooljet   1   yahui  3700782  3700781  0   16:13  pts/0  00:01:52  node dist/src/main
postgres  1   999    3700200  3700177  0   16:12  ?      00:00:01  postgres

解读：tooljet 服务的进程链为 npm run start:prod → node dist/src/main，链上还挂着内建 redis-server（WORKER=true 时随服务自启的任务队列，见配置篇）；postgres 行首的 UID 999 是数据库运行账号。

实时资源占用快照（--no-stream 取一次即退出，不加则持续刷新）：

docker compose stats --no-stream

实测输出：

CONTAINER ID   NAME                            CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O         PIDS
54b49f6017ea   tooljet-3.20.246-lts-app        0.50%     513MiB / 31.3GiB     1.60%     21.9MB / 1.92MB   88.2MB / 146MB    41
936c1904ac1e   tooljet-3.20.246-lts-postgres   0.00%     31.94MiB / 31.3GiB   0.10%     1.49MB / 1.05MB   8.29MB / 2.17MB   6

解读：实测空闲态主服务常驻内存约 513MiB、CPU 0.5%，postgres 约 32MiB——这是容量规划的经验基线（更长期的内存表现分析见配置篇）。

4.1.5 生命周期操作：up / restart / down

启停与重建的常用组合（完整部署与升级流程见部署篇，此处给运维视角速查）：

docker compose up -d                   # 启动/按配置变化重建（改 .env 后必须用它，restart 不重读 .env）
docker compose restart tooljet         # 仅重启进程（不动配置）
docker compose down                    # 停止并移除服务（postgres_data 数据目录保留）

【实测】restart 与 up -d 的差异验证：修改 .env 中 USER_SESSION_EXPIRY 后执行 docker compose restart tooljet，docker compose exec tooljet env 查看（回显节选）：

USER_SESSION_EXPIRY=2880

可见值仍为旧值；改用 docker compose up -d 重建后再查，新值生效（本文环境实测过程与配置篇 3.2 节一致）。

4.1.6 版本确认：docker compose version

docker compose version

实测输出：

Docker Compose version v5.5.1

💡 说明：Compose v1（docker-compose 带连字符）已停止维护，本文统一使用 v2 语法（docker compose 空格形式）。官方部署文档同样使用该语法。

4.2 官方 CLI：@tooljet/cli

官方 CLI 是插件开发工具（npm 包 @tooljet/cli，【实查】npm registry 显示 latest 版本 0.0.14），用于创建数据源连接器插件脚手架、管理插件依赖。注意它不用于服务运维——服务运维用 4.1 的 Compose 命令与 4.3 的内置脚本。

4.2.1 安装与版本确认

在主服务环境内全局安装（实测，需要可访问 npm registry）：

npm install -g @tooljet/cli

实测输出（尾部）：

added 217 packages in 1m

30 packages are looking for funding
  run `npm fund` for details

确认安装位置与版本：

which tooljet
tooljet --version

实测输出：

/usr/local/lib/nodejs/bin/tooljet
@tooljet/cli/0.0.14 linux-x64 node-v22.15.1

解读：全局安装位置在 npm 的 nodejs bin 目录；--version 同时带出运行环境信息（node 版本），排障时可顺带确认运行时。

4.2.2 总帮助：tooljet --help

tooljet --help

实测输出（全量）：

tooljet cli tool

VERSION
  @tooljet/cli/0.0.14 linux-x64 node-v22.15.1

USAGE
  $ tooljet [COMMAND]

TOPICS
  plugin  manage plugins options: create, delete and install

COMMANDS
  info  This command returns the information about where tooljet is being run

解读：v0.0.14 的命令面就是两块——plugin 主题（create/delete/install 三个子命令）与 info 环境信息命令。

4.2.3 环境信息：tooljet info

tooljet info

实测输出（全量）：

    Operating System:
      platform: linux
      arch: x64
      version: #138~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug  7 13:43:15 UTC
    Binaries:
      node: 22.15.1
      npm: 10.9.2
    Relevant packages:
      tooljet: N/A

解读：汇报操作系统内核标识与 node/npm 版本；Relevant packages.tooljet: N/A 表示当前目录未检出 ToolJet 源码仓（该字段在源码仓内运行时会显示包版本）。

4.2.4 plugin 子命令帮助

plugin 主题的三个子命令，逐一查看用法：

tooljet plugin --help

实测输出（全量）：

manage plugins options: create, delete and install

USAGE
  $ tooljet plugin COMMAND

COMMANDS
  plugin create   Create a new tooljet plugin
  plugin delete   Delete a tooljet plugin
  plugin install  Installs a new npm module inside a tooljet plugin

tooljet plugin create --help

实测输出（全量）：

Create a new tooljet plugin

USAGE
  $ tooljet plugin create [PLUGIN_NAME] [--type database|api|cloud-storage]
    [-b]

ARGUMENTS
  PLUGIN_NAME  Name of the plugin

FLAGS
  -b, --build
  --type=<option>  <options: database|api|cloud-storage>

DESCRIPTION
  Create a new tooljet plugin

EXAMPLES
  $ tooljet plugin create <name> --type=<database | api | cloud-storage> [--build]

tooljet plugin delete --help

实测输出（全量）：

Delete a new tooljet plugin

USAGE
  $ tooljet plugin delete [PLUGIN_NAME] [-b] [-m]

ARGUMENTS
  PLUGIN_NAME  Name of the plugin

FLAGS
  -b, --build
  -m, --marketplace

DESCRIPTION
  Delete a tooljet plugin

EXAMPLES
  $ tooljet plugin delete <name> [--build]

⚠️ 注意：上面 delete 帮助首行回显为「Delete a new tooljet plugin」，系 v0.0.14 原文如此（官方描述文案笔误），照抄保留。

tooljet plugin install --help

实测输出（全量）：

Installs a new npm module inside a tooljet plugin

USAGE
  $ tooljet plugin install [NPM_MODULE] --plugin <value>

ARGUMENTS
  NPM_MODULE  Name of the npm module

FLAGS
  --plugin=<value>  (required)

DESCRIPTION
  Installs a new npm module inside a tooljet plugin

EXAMPLES
  $ tooljet plugin install <npm_module> --plugin <plugin_name>

4.2.5 plugin create 的目录约束（实测报错实录）

plugin create 有一个必须知晓的前置条件：必须在 ToolJet 的 marketplace 目录结构内运行，否则报错。实测在一个空目录执行：

mkdir -p /tmp/pjtest && cd /tmp/pjtest
tooljet plugin create demoapi --type api

实测输出（交互提问后报错）：

Enter plugin display name: Error : marketplace, docs or marketplace/_templates directory missing, make sure that you are running this command in Tooljet directory

排障结论：脚手架生成依赖 marketplace 模板目录（marketplace/、docs/、marketplace/_templates/）。正确做法是先克隆 ToolJet 的 marketplace 仓库进入其目录再执行 plugin create；若仅想看命令行为，空目录运行会稳定复现上述报错。

另外两条实测约束：

• plugin create 是交互式命令：提供插件名后会依次提问 Enter plugin display name: 等信息，需要逐项应答；
• tooljet help plugin 这种「help 作子命令」的形态不被支持，实测报错：

 ›   Error: command help:plugin not found

正确形态是 tooljet plugin --help（主题帮助）与 tooljet plugin create --help（子命令帮助）。

4.2.6 错误路径实测（快速定位参数问题）

缺必填参数 --plugin 时：

tooljet plugin install lodash

实测输出：

 ›   Error: The following error occurred:
 ›     Missing required flag plugin
 ›   See more help with --help

未知子命令时：

tooljet foobar

实测输出：

 ›   Error: command foobar not found

💡 说明：CLI 的错误输出以 › 前缀 + Error: 形式给出，且总在最后一行提示 See more help with --help——看到这类输出先补 --help 核对参数拼写，再排查目录约束。

4.3 主服务内置运维脚本

ToolJet 主服务的 server/package.json 内置了一组 npm 运维脚本（数据库、插件、账号、密钥四类）。部署形态下脚本的编译版位于 server/dist/scripts/，可直接用 node 运行；这既是官方脚本的原始入口，也规避了源码形态脚本在部署环境缺 tsconfig 的问题（常见问题 Q2）。

进入主服务环境并切到 server 目录（后续命令都在此执行）：

cd /opt/tooljet
docker compose exec tooljet sh
cd /app/server

4.3.1 脚本清单总览

【实测】server/package.json 中与运维相关的脚本名及含义：

⚠️ 注意：db:drop、db:reset 为破坏性脚本，执行前必须完成两套库备份（备份命令见部署篇升级章节）；生产排障中绝大多数场景只需要 db:migrate:prod 与各 reset/rotate 脚本。

4.3.2 数据库迁移：db:migrate:prod

升级版本或排查「表结构落后」时使用。迁移是幂等的：已执行的迁移自动跳过。实测执行（本文环境数据库为最新状态，属空跑确认）：

npm run db:migrate:prod

实测输出（尾部节选）：

Migration LockMigrationsTable1234567891000 has been executed successfully.

> server@0.0.1 db:migrate:data:prod
> node ./node_modules/typeorm/cli.js migration:run --dataSource dist/src/migration-helpers/data-migrations-datasource.js

441 migrations are already loaded in the database.
221 migrations were found in the source code.
IndexAiAttachmentReconciliation1790683260000 is the last executed migration. It was executed on Tue Sep 29 2026 12:01:00 GMT+0000 (Coordinated Universal Time).
1 migrations are new migrations must be executed.
Migration LockMigrationsTable1234567890000 has been executed successfully.

解读：脚本分两段执行——结构迁移（db-migrations-datasource）与数据迁移（data-migrations-datasource），各自建立迁移锁表防止并发；xx migrations are already loaded 行确认存量迁移数，new migrations must be executed 行提示本次新执行的迁移。验证结果用下面一句：

npm run db:migrate:prod 2>&1 | grep -c "has been executed successfully"

实测输出：

2

两段迁移各一条成功记录，即为干净完成。

4.3.3 账号恢复：reset-superadmin

管理员忘记口令时的官方恢复路径。先看脚本自示用法（不带参数执行）：

node dist/scripts/reset-superadmin.js

实测输出：

Usage: npm run reset-superadmin -- --email admin@company.com

按用法传入邮箱执行。实测一：邮箱不存在时：

node dist/scripts/reset-superadmin.js --email admin@example.com

实测输出（尾部，正常 SQL 调试行已略）：

✗ No user found with email: admin@example.com

实测二：邮箱存在但不是实例级超管时：

node dist/scripts/reset-superadmin.js --email admin@tooljet.local

实测输出（尾部）：

✗ User admin@tooljet.local is not a super admin (user_type must be 'instance')

排障结论（两条实测回显共同给出脚本边界）：

• No user found：邮箱拼写错误或用户不存在，先用管理界面确认邮箱；
• not a super admin (user_type must be 'instance')：该脚本只作用于实例级超管（用户表 user_type='instance' 的账号，即装机时第一个注册的实例管理员），普通工作区管理员（user_type='workspace'，本文环境实测值）不走此脚本——工作区管理员口令由实例超管在管理界面重置，或走登录页「忘记口令」邮件流程（需已配置 SMTP，见配置篇邮件参数）。

重置成功时脚本会为目标实例超管生成新的口令重置链接（链接域名由 TOOLJET_HOST 决定，配置不正确会导致链接打不开——这也是先核对 TOOLJET_HOST 再执行重置的原因）。

4.3.4 两步认证重置：reset-mfa

用户开启两步认证后丢失验证器时的恢复脚本，用法与 reset-superadmin 同构（--email 传参）。以本文环境实测账号为例（实际执行时把邮箱换成目标用户邮箱）：

node dist/scripts/reset-mfa.js --email admin@tooljet.local

【实测】该脚本与 reset-superadmin 共享同一套运行时初始化，目标邮箱不存在时同样返回 ✗ No user found with email: ... 形态的报错；重置成功后该用户的两步认证被清除，可重新走登录页绑定流程。

4.3.5 加密密钥轮换：rotate:keys:prod

LOCKBOX_MASTER_KEY 泄露或需要定期轮换时使用。⚠️ 执行前必须：完成两套库备份、在维护窗口操作、新密钥通过环境变量注入。实测查看脚本流程（--help 不被识别，直接进入交互流程）：

node dist/scripts/rotate-lockbox-key.js --help

实测输出（尾部）：

Step 1: Validating new master key...
✓ New master key (LOCKBOX_MASTER_KEY) validated

Step 2: Enter old master key...
ℹ️  You will be prompted to enter your OLD master key
   (the key currently used in production)

Please enter the old key:

解读：脚本按「验证新密钥（读环境变量 LOCKBOX_MASTER_KEY）→ 交互输入旧密钥 → 全量重加密数据源凭据」三步走。实测环境直接执行时新密钥校验通过后停在旧密钥交互输入处（此时 Ctrl+C 退出无副作用）；正式轮换时在旧密钥提示处输入现役密钥即可。轮换前可加 --dry-run 参数演练（配置篇实查该脚本支持该参数，输出含「DRY RUN MODE: No changes will be made」提示），确认无误再正式执行。

⚠️ 注意：轮换期间所有数据源凭据会被重新加密，中断执行可能导致凭据不可解密——务必先备份两套库，且新密钥一经启用立即离线记录。

4.3.6 插件管理脚本：plugins:install / reload

插件市场离线装载或插件故障重载时使用：

node dist/scripts/plugins-install.js      # 装载插件（扫描插件目录写入插件注册信息）
node dist/scripts/plugins-reload.js       # 重载插件（刷新已注册插件的元数据与文件）
node dist/scripts/plugins-uninstall.js    # 卸载插件

【实测】三个脚本与 reset/rotate 脚本共享同一运行时初始化：入口即连数据库（query: SELECT version() 等初始化日志），操作对象是主库中的插件注册表。日常排障中，若管理界面插件列表显示异常，先跑 plugins-reload.js 再刷新页面。

4.3.7 Worker 模式启动：worker:prod

独立 Worker 部署（多实例拆分任务处理）时的启动脚本，等价于 WORKER=true 环境下启动主服务：

WORKER=true npm run start:prod

【实测】单实例部署不需要单独跑该脚本——WORKER=true 时主服务启动即自动拉起内建任务队列（部署篇实测启动日志首行 Redis started）；仅当按官方多实例指引拆分 Worker 时才在专用实例上使用此形态。

五、注意事项

• 改配置必须重建：.env 修改后只有 docker compose up -d 生效，restart 不重读配置（4.1.5 实测验证）；
• reset 脚本的作用边界：reset-superadmin.js 只处理 user_type='instance' 的实例超管账号（4.3.3 实测验证），工作区管理员不适用；
• CLI 的目录约束：tooljet plugin create 必须在含 marketplace/_templates 的目录结构内运行（4.2.5 实测报错实录），空目录必失败；
• 破坏性脚本先备份：db:drop、db:reset、正式密钥轮换执行前必须完成 tooljet_production 与 tooljet_db 两套库备份（备份命令见部署篇升级章节）；
• 脚本形态选择：部署形态下用 node dist/scripts/*.js 直跑编译版脚本；npm run db:migrate:prod 等 :prod 后缀脚本同样走 dist 路径，二者等价；不带 :prod 的 ts-node 形态面向源码仓开发环境，在部署形态会因缺 tsconfig 报错（常见问题 Q2）；
• 日志噪声识别：内置脚本运行时输出大量 query: 与 info: 前缀行，这是 ORM 调试日志，判断结果看 ✓/✗ 符号行即可。

六、常见问题（FAQ）

Q1：执行 tooljet 提示 not found？ CLI 未安装或不在 PATH。先 npm install -g @tooljet/cli，再 which tooljet 确认（本文实测路径 /usr/local/lib/nodejs/bin/tooljet）；若仍找不到，检查 npm 全局 bin 目录是否在 PATH 中（npm config get prefix 查看）。

Q2：跑 npm run reset-superadmin 报 Couldn't find tsconfig.json 且堆栈含 diagnosticCodes: [ 5109 ]？ 该形态是面向源码仓的 ts-node 脚本入口，部署形态的程序目录里没有 tsconfig.json（实测确认 /app/server 下无该文件）。改用编译版直跑：node dist/scripts/reset-superadmin.js --email admin@tooljet.local（4.3.3 实测通过）。所有 *:prod 后缀脚本等价于此形态。

Q3：reset-superadmin.js 报 ✗ User admin@tooljet.local is not a super admin (user_type must be 'instance')（以实测回显为例）？ 目标账号是工作区管理员而非实例超管。实例超管是部署后第一个注册的账号（用户表 user_type='instance'）；确认账号身份可查用户表（SELECT email, user_type FROM users;，实测回显见 4.3.3 排障结论）。工作区管理员口令由实例超管在管理界面重置。

Q4：docker compose ps 里某服务 STATUS 显示 Exited 或反复重启？ 先看日志定位：docker compose logs --tail 100 tooljet（数据库服务把服务名换成 postgres）。数据库连不上（wait-for-it.sh: timeout ... for postgres:5432）多为 .env 中 PG_HOST 未填服务名 postgres；其余高频故障的定位与修复见《ToolJet 3.20 Docker Compose 部署指南》常见问题章节。

Q5：CLI 装好了，plugin create 却一直报 marketplace, docs or marketplace/_templates directory missing？ 这是目录约束而非安装问题：脚手架生成依赖 marketplace 仓库的模板结构。先克隆 ToolJet 官方 marketplace 仓库，进入其根目录再执行 plugin create（4.2.5 实测报错与分析）。

七、参考链接

• 官方 CLI npm 包：https://www.npmjs.com/package/@tooljet/cli
• 官方 CLI 源码：https://github.com/ToolJet/ToolJet/tree/main/packages/cli
• 官方插件开发文档：https://docs.tooljet.ai/docs/marketplace/creating-a-plugin
• 官方部署文档：https://docs.tooljet.ai/docs/setup/docker
• 本专栏介绍篇：《ToolJet 3.20 介绍与选型指南》
• 本专栏部署篇：《ToolJet 3.20 Docker Compose 部署指南》
• 本专栏配置篇：《ToolJet 3.20 配置参数详解》