「内部那个工单表能不能别再让我改前端了？给我一个能自己加字段的后台就行，最好放我们自己服务器上。」对方做仓储，三句话里两句在强调自托管。
听起来是选型问题，动手才发现是部署问题：开源低代码平台搭建，demo 都号称五分钟跑通，卡住的从来不是拖拽，是官方那份 compose 有多少行、Node 版本对不对、端口有没有被占。下面数字均为 2026-10-22 用 GitHub API 拉取，compose 是我下载后逐行数出来的。
准备：五个候选与它们的官方 compose，先摊开看
五个项目的真实数据（GitHub API，2026-10-22）：NocoDB 65,314 星，仓库约 1.44 GB；Appsmith 40,999 星，Apache-2.0，v2.5.1（10-21）；ToolJet 41,116 星，AGPL-3.0，v3.20.247-lts（10-21）；Budibase 28,340 星，v3.50.0（10-19）；Baserow 6,185 星，2.4.1（10-13）。
第一个反常识：其中四个的许可证，GitHub 识别不出来——NocoDB、Budibase、Baserow、Teable 的 license 字段全是 NOASSERTION，只有 Appsmith（Apache-2.0）、ToolJet（AGPL-3.0）是标准标识。而几份流传很广的对比表里，NocoDB 被写成 AGPL-3.0、Budibase 被写成 GPL-3.0，写得斩钉截铁。要商用二开，就自己打开仓库根目录的 LICENSE 读一遍。
步骤一：先挑部署形态，别急着 docker compose up
我原本以为 Budibase 功能最全所以最重，把官方 compose 拉下来数完才发现不是。四份文件均取自各自默认分支：
- Appsmith
deploy/docker/docker-compose.yml：344 字节、1 个服务，端口 8080:80 - Baserow
docker-compose.yml：21,861 字节、10 个服务（caddy、backend、web-frontend、三个 celery worker、email-receiver、db、redis、permissions-fixer）加 6 个卷；同目录docker-compose.all-in-one.yml只要 489 字节、1 个服务 - Budibase
hosting/docker-compose.yaml：5,623 字节、8 个服务，含 litellm-service 与 litellm-db 一整套 - ToolJet
docker-compose.yaml：2,287 字节、6 个服务，端口 3000/3001/5432/6379/8082
三个结论：上手成本不是软件的属性、是你选了哪份 compose 的属性——Baserow 全量编排是 Appsmith 那份的 63 倍，可它自己又给了 489 字节的单容器版；Budibase 默认编排已塞进一整套 litellm，只想用表单列表的话这两个服务白占内存；另外说明实测边界——本机没有 Docker，以上只做了静态核对，容器有没有真跑起来我没验证。
步骤二：源码路线要先过 Node 版本这道坎
打算拉源码改，拦路虎在这。各仓库 package.json 的 engines 实测：ToolJet 钉 node 22.15.1 + npm 10.9.2（精确版本）；Budibase 是 >=22.18.0 <23.0.0；Appsmith 要 node ^24.14.1 + yarn ^3.5.1；Teable 要 pnpm>=12，engines.npm 直接写着 please-use-pnpm；NocoDB 根 package.json 是 monorepo 壳子，无 engines。
本机实测 Node v22.22.2、npm 10.9.7，pnpm 与 yarn 都没装。对照下来只满足 Budibase；Teable 要先装 pnpm；ToolJet 钉死 22.15.1 过不去；Appsmith 两个条件都不满足。想在一台机器上同时二开两个，要么走容器，要么上多版本管理器。
只想先摸摸界面有个省力办法：npm 上 nocodb 包实测 version 0.301.3、解压后 28,459,389 字节（约 27.1 MB）、要求 node >=22，而 GitHub 仓库约 1.44 GB。先看效果就装 npm 包，别 clone。
步骤三：起服务、建第一张表，接上真实数据源
两个真机踩到的坑，都跟照抄一行命令有关。
坑一，端口冲突且报错不指向端口。本机 curl http://localhost:8080/ 返回的是 Welcome to nginx!，而 Appsmith 官方 compose 写的正是 8080:80。动手前先确认端口是空的，比事后翻日志快得多。
坑二，npx nocodb 这条最短路径在我这儿不成立，本机 npm 10.9.7 直接报 could not determine executable to run。「一行命令起服务」的教程在你机器上未必复现得了。
接数据按用途分三类：给现有数据库套表格界面走 NocoDB 这类；要带流程的完整后台走 Budibase 这类；拖组件拼管理面板走 Appsmith、ToolJet。这跟开源论坛本地部署那篇一致——卡住人的从来不是代码，是目录不可写、代理没配、端口被占。默认参数也别急着调，批量提取工具里并发默认 6 就是调过的，这类平台的连接池、附件上限同理。
结果校验：三件事确认它真跑起来了
首页能开不代表能用。我验这三件：首页返回 200 且不是 nginx 欢迎页（这条就挡掉上面的端口坑）；建表写一条记录后彻底停掉服务再起来，数据还在不在——验的是卷有没有真挂上；换无痕窗口确认未登录看不到数据。
后两条要单独验，是因为登录接口成功、后续请求全部鉴权失败这种事真的会发生。做法沿用抓取与界面分层的思路：数据层验一遍，界面层验一遍。接到真实业务数据时也别忘了——公开可见不等于可以随意使用，涉及个人信息要先做合规评估，这条我在采集类工具实操里也写过。
仓库与官方编排都在 GitHub：nocodb/nocodb、appsmithorg/appsmith、Budibase/budibase、ToolJet/ToolJet、baserow/baserow。版本号、许可证与系统要求以各仓库最新说明为准。
常见问题
容器起不来，先查什么？
先查端口。Appsmith 官方 compose 映射 8080:80，很多机器这个口已被 nginx 占了，症状是启动失败但报错指向别处。其次查卷目录属主，Budibase 那份专门带了 volume-permissions-fixer，权限不对会直接退出。
有中文界面吗？
主流项目都带多语言，覆盖程度不一，中英文版本的功能入口偶尔对不上。以官方 README 与文档最新说明为准，我没逐个实测，不给具体版本。
升级会不会丢数据？
看卷有没有独立挂出来。按上面第二条做一次停启演练，数据还在就说明挂对了，之后拉新镜像再 up 一般不会丢；卷没挂对，升级一次丢一次。
能拿来做商业二次开发吗？
先读 LICENSE。实测 NocoDB、Budibase、Baserow、Teable 四个仓库 GitHub 的 license 字段都是 NOASSERTION，二手对比表给的协议名不可信；Appsmith 是 Apache-2.0、ToolJet 是 AGPL-3.0，商用前务必自己确认条款差异。
不想用了怎么清干净？
容器路线要 docker compose down -v 才会连卷一起删，不加 -v 数据卷会留下。源码路线除删目录外，还要清本地生成的数据库文件与缓存，否则下次重装会读到旧数据。
