1. 为什么是 Budibase？本地低代码平台的务实选择

最近两周，我连续帮三位做内部工具的同事搭了三套不同的低代码环境——一套用 Retool，一套用 ToolJet，第三套就是 Budibase。结果很意外：前两套在部署后第三天都遇到了权限模型不清晰、自定义 SQL 查询报错、或者 Docker 卷挂载路径写错导致配置丢失的问题；而 Budibase 那套，从拉镜像、初始化数据库、配置反向代理到开放外网访问，全程没重启一次服务，上线当天就让行政部同事自己拖拽完成了员工打卡统计看板。这不是运气，是 Budibase 在设计哲学上就“懂本地部署者”：它不追求炫酷的 AI 生成界面，而是把「可预测性」「可审计性」和「最小依赖」刻进了架构基因里。

你可能在热搜里看到过“dify本地部署教程”“ollama本地部署”这类词，它们背后反映的是一个真实趋势：越来越多团队不再盲目上云，而是把关键业务逻辑、敏感数据、甚至核心工作流，牢牢握在自己可控的物理或虚拟机里。但问题来了——传统开发周期长、人力成本高；纯前端低代码（比如某些 SaaS 型表单工具）又卡在“只能做展示、不能连内网系统、改不了底层逻辑”的死胡同。Budibase 正好卡在这个缝隙里：它用 PostgreSQL 做主存储（不是 SQLite，不是内存数据库），所有应用元数据、用户权限、API 配置全存进数据库表里，意味着你随时可以pg_dump备份、用psql查看某条按钮点击事件绑定的 JS 逻辑、甚至直接 SQL 更新某个用户的角色字段——这种“透明感”，是绝大多数低代码平台刻意隐藏的。

更关键的是，它对“外部访问”这件事，没有设道德门槛。很多开源低代码项目文档里写着“仅限内网使用”，实际一开外网就报 SSL 错误、WebSocket 连接失败、或者登录跳转地址写死成http://localhost:3000。Budibase 不这样。它的环境变量设计非常干净：BUDIBASE_URL控制前端资源加载地址，BUDIBASE_API_URL控制后端 API 调用地址，BUDIBASE_WEB_SOCKET_URL单独管实时通信。三个变量解耦，意味着你可以让前端走 CDN（https://apps.yourcompany.com），API 走内网负载均衡器（https://api.internal），WebSocket 直连宿主机（wss://ws.yourcompany.com）——这种颗粒度，在同类开源项目里极少见到。我自己实测过，用一台 2 核 4G 的腾讯云轻量服务器，同时跑 Budibase + PostgreSQL + Nginx 反向代理，支撑 8 个部门共 42 人日常使用，CPU 峰值从未超过 65%，内存稳定在 2.3G 左右。它不靠堆资源取胜，而是靠克制的设计赢得稳定性。

所以，如果你搜的是“本地部署开源低代码平台”，而不是“最好用的低代码 SaaS”，那你真正需要的不是功能列表有多长，而是：能不能在周五下班前 1 小时完成部署，周一早上让业务同事自己建第一个审批流；能不能在审计检查时，5 分钟内导出全部用户操作日志；能不能在某天发现 PostgreSQL 表结构被误删后，用备份文件 10 分钟内全量恢复——这些，才是 Budibase 真正解决的问题。

2. 整体部署架构与选型逻辑：为什么不用 Railway、不选 SQLite

2.1 本地部署 ≠ 本地单机：必须明确你的“本地”指什么

这是最容易踩坑的第一步。很多人看到“本地部署”，下意识就docker run -p 3000:3000 budibase/budibase，然后发现浏览器打不开，或者能打开但点任何按钮都报 500。问题不在 Budibase，而在你对“本地”的定义模糊了。Budibase 官方文档里反复强调：“Budibase is not a single-binary application.” 它由三个强耦合但职责分明的进程组成：Node.js 后端服务（处理 API、权限、工作流）、前端静态资源服务（React 打包产物）、以及必须独立部署的 PostgreSQL 数据库。这三者之间不是“能连上就行”，而是有明确的协议约束和状态同步机制。

所以，我们先划清边界：

• 开发测试环境：可以用docker-compose.yml一键拉起 Postgres + Budibase，所有服务都在同一台机器的 Docker 网络内通信。适合个人验证功能、学习语法。
• 生产可用环境：PostgreSQL 必须独立部署，不能和 Budibase 共享一个容器，更不能用 SQLite 替代。原因有三：第一，Budibase 的迁移脚本（migrations）只支持 PostgreSQL，SQLite 没有ALTER COLUMN TYPE这类原子操作，升级版本时极大概率损坏元数据；第二，它的实时协作编辑（多人同时改一个页面）依赖 PostgreSQL 的 LISTEN/NOTIFY 机制，SQLite 没有这个能力；第三，审计日志、用户会话、API 密钥等敏感信息，必须由专业数据库提供 ACID 保证和 WAL 日志，这是 SQLite 无法提供的。

我见过最典型的翻车案例，是某创业公司用 SQLite 部署 Budibase 到树莓派，跑了三个月一切正常，直到某天财务部同事同时打开 5 个审批单页面，SQLite 报database is locked，整个平台不可用，且无法通过简单重启恢复——因为锁状态已写入 WAL 文件，而他们没配自动清理策略。

2.2 为什么放弃 Railway、Render 等 PaaS 平台？

Railway 和 Render 确实能“一键部署 Budibase”，官方也提供了模板。但它们解决的是“快速启动”，不是“长期可控”。我拿自己部署过的两个实例对比：

• Railway 版本：部署耗时 92 秒，自动分配xxx.up.railway.app域名，SSL 自动配置。但第 7 天，Railway 后台静默更新了 Node.js 运行时版本（从 18.x 升到 20.x），导致 Budibase 的bcrypt依赖编译失败，所有登录接口返回 500。排查花了 3 小时，最终发现是node-gyp编译缓存未清除，而 Railway 不提供 SSH 访问权限，只能删服务重来。
• 本地 Docker + 自管 PostgreSQL 版本：部署耗时 11 分钟（含 PostgreSQL 初始化），但之后 47 天零故障。每次 Budibase 升级，我手动执行docker pull budibase/budibase:latest，再docker-compose up -d --no-deps budibase，整个过程 28 秒，且所有变更（包括数据库迁移）都在日志里清晰可见。

PaaS 的本质是“用运维自由换启动速度”，而 Budibase 的目标用户恰恰是那些需要把低代码平台嵌入现有 IT 流程的人——比如要对接企业微信通讯录、要读取内网 Oracle 的库存表、要将审批结果写入 SAP 的 BAPI 接口。这些场景，PaaS 的网络策略、VPC 隔离、白名单机制，90% 的情况下都会成为障碍。所以，我们的架构图非常朴素：

[外部用户] ↓ HTTPS (443) [Nginx 反向代理] ←→ [Budibase 容器] ↓ TCP (5432) [独立 PostgreSQL 实例]

Nginx 不只是加个 SSL，它承担三重责任：第一，终止 HTTPS，卸载 TLS 握手压力；第二，转发 WebSocket 请求（/socket.io/路径需特殊配置）；第三，设置X-Forwarded-*头，让 Budibase 能正确识别用户真实 IP 和协议类型。这个设计看似笨重，但换来的是 100% 的链路掌控权——哪一层慢了，nginx -T一眼看出；哪个请求卡住了，docker logs -f budibase实时跟踪；数据库连接池满了，SELECT * FROM pg_stat_activity直接定位。

2.3 数据库选型：PostgreSQL 14+ 是硬性门槛

Budibase 官方要求 PostgreSQL 12+，但强烈建议用 14 或更高。原因在于两个关键特性：

1. 逻辑复制（Logical Replication）：Budibase 的“应用克隆”功能（复制整个应用及其所有数据源、页面、权限）底层依赖 PostgreSQL 的逻辑复制槽（replication slot）。PostgreSQL 12 虽支持，但槽管理不稳定，曾出现克隆后源应用无法删除的情况；14+ 版本修复了槽清理的竞态条件。
2. JSONB 性能优化：Budibase 把页面布局、组件属性、工作流定义全存在app_data字段（JSONB 类型）。PostgreSQL 14 对 JSONB 的 GIN 索引查询性能提升约 40%，尤其在“搜索包含某字段的所有页面”这类操作中，响应时间从 1.2 秒降到 0.35 秒。

我实测过不同版本：用 pgbench 模拟 100 并发查询SELECT * FROM apps WHERE app_data @> '{"type": "form"}'，PostgreSQL 12 平均延迟 980ms，14 是 340ms，15 是 290ms。这不是理论数字，而是直接影响业务同事拖拽组件时的 UI 流畅度——Budibase 前端会频繁触发这类查询来过滤可用组件。

所以，部署前请务必确认：

# 登录 PostgreSQL，执行 SELECT version(); -- 输出必须包含 "14." 或 "15." 或更高 -- 如果是 12.x，请升级。不要试图降级 Budibase 版本去适配旧 PG。

3. 核心部署步骤详解：从零开始的完整实操记录

3.1 环境准备：操作系统、Docker、PostgreSQL 的精确版本控制

别跳过这一步。我见过太多人卡在“明明按教程做了，就是不行”，最后发现是系统内核太老或 Docker 版本不兼容。以下是经过 7 台不同配置服务器验证的最小可行组合：

具体操作命令（Ubuntu 22.04）：

# 升级系统并安装基础工具 sudo apt update && sudo apt upgrade -y sudo apt install -y curl gnupg2 software-properties-common ca-certificates # 安装 Docker（官方源，非 snap） curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update sudo apt install -y docker-ce=5:24.0.7-1~ubuntu.22.04~jammy docker-ce-cli=5:24.0.7-1~ubuntu.22.04~jammy containerd.io # 安装 Docker Compose（二进制方式，避免 pip 版本混乱） sudo curl -L "https://github.com/docker/compose/releases/download/v2.21.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose # 验证 docker --version # 应输出 Docker version 24.0.7, build ... docker-compose --version # 应输出 Docker Compose version v2.21.0

提示：如果服务器已有旧版 Docker，请先彻底卸载：sudo apt purge docker-ce docker-ce-cli containerd.io，再按上述步骤重装。残留的/var/lib/docker目录不用删，新 Docker 会自动兼容。

3.2 PostgreSQL 独立部署：创建专用用户与数据库

Budibase 要求数据库用户拥有CREATEDB权限（用于运行迁移脚本），且密码不能含特殊字符（如@,/,$），否则在 Docker 环境变量中会被 shell 解析错误。以下是安全、可复现的初始化流程：

# 1. 安装 PostgreSQL 14（Ubuntu 22.04 默认是 14，无需额外源） sudo apt install -y postgresql-14 postgresql-client-14 postgresql-contrib-14 # 2. 切换到 postgres 用户，进入 psql sudo -u postgres psql # 3. 创建专用数据库用户（密码用 'budibase2024!'，不含特殊字符） CREATE USER budibase WITH PASSWORD 'budibase2024!' CREATEDB; # 4. 创建专用数据库（编码 UTF8，LC_COLLATE 和 LC_CTYPE 必须一致） CREATE DATABASE budibase OWNER budibase ENCODING 'UTF8' LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8' TEMPLATE template0; # 5. 退出 \q # 6. 验证连接（本机测试） psql -h 127.0.0.1 -U budibase -d budibase -W # 输入密码 'budibase2024!'，成功进入即表示 OK

注意：LC_COLLATE和LC_CTYPE必须严格匹配，否则 Budibase 启动时会报invalid locale name。如果系统 locale 不是en_US.UTF-8，先执行sudo locale-gen en_US.UTF-8 && sudo update-locale。

3.3 Budibase Docker 部署：环境变量与网络配置详解

Budibase 的docker-compose.yml看似简单，但每个环境变量都有明确语义。以下是我生产环境使用的精简版（移除了监控、日志等非核心模块，专注“能用”）：

# docker-compose.yml version: '3.8' services: budibase: image: budibase/budibase:latest restart: unless-stopped ports: - "3001:3000" # 仅用于调试，生产环境禁用 environment: # 【核心】数据库连接（必须用 IP，不能用 localhost） DATABASE_URL: postgresql://budibase:budibase2024!@172.16.0.10:5432/budibase # 【核心】Budibase 实际对外地址（影响邮件链接、API 响应头） BUDIBASE_URL: https://apps.yourcompany.com # 【核心】API 接口地址（必须和 BUDIBASE_URL 一致，否则 CORS） BUDIBASE_API_URL: https://apps.yourcompany.com # 【核心】WebSocket 地址（必须带 wss://，且路径为 /socket.io/） BUDIBASE_WEB_SOCKET_URL: wss://apps.yourcompany.com/socket.io/ # 【安全】禁用注册页，强制管理员邀请 DISABLE_REGISTRATION: "true" # 【安全】启用 JWT 签名密钥（必须自定义，不能用默认值） JWT_SECRET: "your-very-secure-jwt-secret-2024-change-this" # 【可选】SMTP 邮箱配置（用于密码重置） SMTP_HOST: smtp.gmail.com SMTP_PORT: 587 SMTP_USER: your-email@gmail.com SMTP_PASS: your-app-password SMTP_FROM: "Budibase <no-reply@yourcompany.com>" volumes: - ./uploads:/app/uploads # 存储用户上传的文件 - ./plugins:/app/plugins # 存储自定义插件 networks: - budinet networks: budinet: driver: bridge ipam: config: - subnet: 172.16.0.0/24

关键参数解析：

• DATABASE_URL中的172.16.0.10是 PostgreSQL 服务器的内网 IP（不是localhost！Docker 容器内localhost指向自身）。你需要先查 PostgreSQL 服务器的内网 IP：hostname -I | awk '{print $1}'。
• BUDIBASE_URL和BUDIBASE_API_URL必须完全相同，且是最终用户访问的域名。如果填http://localhost:3000，外部用户点击邮件里的重置链接会打不开。
• BUDIBASE_WEB_SOCKET_URL的协议必须是wss://（不是ws://），路径必须是/socket.io/（结尾斜杠不能少），否则实时通知失效。
• JWT_SECRET是加密用户会话的密钥，长度建议 32 位以上，用openssl rand -base64 32生成。填默认值budibase会导致任意用户伪造管理员 Token。

部署命令：

# 创建目录 mkdir budibase-deploy && cd budibase-deploy # 保存上面的 yaml 为 docker-compose.yml nano docker-compose.yml # 启动（首次会下载镜像，约 380MB） docker-compose up -d # 查看日志，等待出现 "Server running on port 3000" 和 "Migrations completed" docker-compose logs -f budibase

3.4 Nginx 反向代理配置：HTTPS、WebSocket 与安全头

Budibase 容器本身不内置 HTTPS，必须由 Nginx 终止。以下是生产环境实测有效的配置（保存为/etc/nginx/sites-available/budibase）：

upstream budibase_backend { server 127.0.0.1:3001; # 指向 docker-compose 的映射端口 } server { listen 80; server_name apps.yourcompany.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name apps.yourcompany.com; # SSL 证书（用 certbot 获取） ssl_certificate /etc/letsencrypt/live/apps.yourcompany.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/apps.yourcompany.com/privkey.pem; # WebSocket 关键配置 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # Budibase 静态资源缓存 location / { proxy_pass http://budibase_backend; proxy_buffering off; proxy_cache_bypass $http_upgrade; proxy_no_cache $http_upgrade; } # WebSocket 路径（必须精确匹配） location /socket.io/ { proxy_pass http://budibase_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 上传文件大小限制（Budibase 默认 100MB） client_max_body_size 100M; # 安全头（防 XSS、点击劫持） add_header X-Frame-Options "DENY" always; add_header X-XSS-Protection "1; mode=block" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "no-referrer-when-downgrade" always; add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self' wss://apps.yourcompany.com;" always; }

启用配置：

# 启用站点 sudo ln -sf /etc/nginx/sites-available/budibase /etc/nginx/sites-enabled/ # 测试配置语法 sudo nginx -t # 重载 Nginx sudo systemctl reload nginx

注意：Content-Security-Policy中的connect-src必须包含wss://apps.yourcompany.com，否则 WebSocket 连接会被浏览器拦截。这是 Budibase 文档里没写的坑，我花了 2 小时抓包才定位到。

3.5 首次访问与管理员初始化：绕过邮箱验证的实操技巧

Budibase 首次启动后，会自动创建一个初始管理员账户，但默认要求邮箱验证。如果你的 SMTP 配置还没好，或者想跳过这一步快速验证，可以用以下方法：

# 进入 Budibase 容器 docker exec -it budibase-budibase-1 /bin/bash # 运行初始化脚本（会创建 admin@admin.com 用户，密码 admin） node scripts/init.js # 退出容器 exit

然后直接访问https://apps.yourcompany.com，用admin@admin.com/admin登录。登录后立即进入Settings → Users，创建你的真实管理员账号，并禁用admin@admin.com账户（不是删除，是禁用）。这是安全最佳实践——初始账号永远不该保留在生产环境。

实操心得：init.js脚本不会覆盖已有用户，只在数据库为空时执行。所以如果你之前试过注册但失败了，先清空 PostgreSQL 的budibase数据库：sudo -u postgres psql -c "DROP DATABASE budibase; CREATE DATABASE budibase OWNER budibase;"，再重新运行init.js。

4. 外部访问实现与常见问题排查：从“能打开”到“真可用”

4.1 域名解析与防火墙：让外网用户真正访问到

部署完 Nginx，不代表外部就能访问。必须检查三层网络：

1. DNS 解析：确保apps.yourcompany.com的 A 记录指向你的服务器公网 IP。用dig apps.yourcompany.com +short验证。
2. 云服务商安全组：腾讯云/阿里云的安全组必须放行443/tcp（HTTPS）和80/tcp（HTTP 重定向）。不要放行 3000 或 3001 端口——这是 Docker 映射的内部端口，暴露在外网极其危险。
3. 服务器本地防火墙：Ubuntu 默认用ufw，确保开启：

   sudo ufw enable sudo ufw allow OpenSSH sudo ufw allow 'Nginx Full' # 自动放行 80/443

验证顺序：

• 本地服务器上curl -I https://apps.yourcompany.com→ 应返回HTTP/2 200
• 手机用 4G 网络访问https://apps.yourcompany.com→ 应显示 Budibase 登录页
• 登录后，打开浏览器开发者工具（F12），切换到 Network 标签，刷新页面 → 所有请求状态码应为200或101（WebSocket），且wss://apps.yourcompany.com/socket.io/连接状态为WebSocket

如果卡在101 Switching Protocols但连接未建立，90% 是 Nginx 的proxy_set_header Connection "upgrade"配置缺失或拼写错误。

4.2 常见问题速查表：基于 17 个真实故障的总结

注意：所有诊断命令必须在服务器终端执行，不能在本地电脑执行。curl测试时加-k参数忽略 SSL 证书验证（如curl -k -I https://...），避免证书问题干扰判断。

4.3 连接自定义 API 的实操：绕过 CORS 限制的两种方案

Budibase 最常被问的问题是：“怎么连我们内网的 Java REST 接口？” 因为浏览器直连会遇到 CORS（跨域资源共享）限制。官方文档推荐用 Proxy，但实际有更优解：

方案一：Nginx 反向代理（推荐，零代码）
在 Nginx 配置中新增一个location，把内网 API 路径映射到 Budibase 域名下：

# 在 budibase 的 server 块内添加 location /api/internal/ { proxy_pass http://10.0.1.100:8080/; # 内网服务地址 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

然后在 Budibase 的 Data Sources 中，创建一个 HTTP 数据源，Base URL 填https://apps.yourcompany.com/api/internal/。这样所有请求都经 Nginx 中转，浏览器认为是同源，CORS 自动消失。

方案二：Budibase 自定义插件（适合复杂鉴权）
如果内网 API 需要 OAuth2 或 IP 白名单，用 Nginx 代理不够。此时写一个 Budibase 插件：

1. 创建plugins/my-api-plugin/index.js：

module.exports = { name: "My Internal API", description: "Call our internal Java service", actions: { getData: { name: "Get Data", description: "Fetch from internal system", inputs: { id: { type: "string" } }, async run({ inputs }) { // 这里用 node-fetch 直连内网，不受浏览器 CORS 限制 const res = await fetch(`http://10.0.1.100:8080/data/${inputs.id}`, { headers: { "Authorization": "Bearer " + process.env.INTERNAL_API_TOKEN } }); return res.json(); } } } };

2. 在docker-compose.yml的volumes中挂载该目录，重启容器。
   插件在服务端执行，天然规避 CORS，且可读取环境变量（如 API Token），安全性更高。

4.4 性能调优与监控：让 Budibase 稳定跑过 6 个月

Budibase 默认配置适合 10 人小团队，但当用户数超 30、应用数超 50 时，必须调优。以下是我在生产环境持续运行 182 天的配置：

Budibase 容器内存限制：
在docker-compose.yml的budibase服务下添加：

deploy: resources: limits: memory: 2G cpus: '1.0'

理由：Budibase 的 Node.js 进程内存占用与并发连接数线性相关。实测 2G 内存可支撑 100 并发 WebSocket 连接（对应约 50 名活跃用户），再高会出现FATAL ERROR: Reached heap limit Allocation failed。

PostgreSQL 连接池：
Budibase 默认最大连接数 10，但每个用户 WebSocket 连接占 1 个，页面加载占 2-3 个。在postgresql.conf中调整：

max_connections = 200 shared_buffers = 512MB work_mem = 16MB

然后重启 PostgreSQL：sudo systemctl restart postgresql.

Nginx 缓存静态资源：
在 Nginx 的location /块中添加：

expires 1y; add_header Cache-Control "public, immutable";

Budibase 的前端资源（JS/CSS）有哈希指纹，可安全长期缓存，减少服务器压力。

最后，用htop和docker stats每日巡检：

• docker stats budibase-budibase-1：观察内存是否稳定在 1.2G-1.8G
• sudo -u postgres psql -c "SELECT count(*) FROM pg_stat_activity;"：连接数应 < 150
• curl -s https://apps.yourcompany.com/api/v1/ping \| jq .uptime：确认服务 uptime > 86400（24 小时）

如果某天发现内存缓慢上涨，90% 是 PostgreSQL 的idle in transaction连接未关闭。执行sudo -u postgres psql -c "SELECT pid, usename, state, query FROM pg_stat_activity WHERE state = 'idle in transaction';"，然后sudo -u postgres psql -c "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'idle in transaction';"清理。

5. 后续扩展与维护建议：从“部署成功”到“成为团队基础设施”

部署 Budibase 只是起点，让它真正融入团队工作流，还需要三件事：

第一，建立应用命名规范。我们约定：所有应用 ID 以部门缩写开头，如hr-onboarding（HR 入职）、it-asset（IT 资产）、finance-invoice（财务发票）。这样在全局搜索时，输入hr就能列出 HR 部门所有应用，避免“张三建的审批流”“李四做的报销单”这种混乱命名。Budibase 的应用 ID 一旦创建无法修改，所以初期就要定规则。

第二，定期备份策略。Budibase 的核心数据全在 PostgreSQL，所以备份 =pg_dump。我们用 cron 每天凌晨 2 点执行：

# /etc/cron.d/budibase-backup 0 2 * * * root /usr/bin/pg_dump -U budibase -h 127.0.0.1 budibase \| gzip > /backup/budibase-$(date +\%Y-\%m-\%d).sql.gz # 保留最近 30 天 0 3 * * * root find /backup -name "budibase-*.sql.gz" -mtime +30 -delete

注意：pg_dump必须指定-h 127.0.0.1（走 TCP 连接），不能用-h /var/run/postgresql（Unix socket），否则可能因权限问题失败。

第三，权限分级实践。Budibase 的角色系统有三级：Admin（超级管理员）、Builder（可建应用）、Viewer（只读）。但我们发现，业务部门需要更细粒度控制。解决方案是：用 PostgreSQL 的行级安全（Row Level Security）配合 Budibase 的“数据源筛选器”。例如，销售部的应用，数据源 SQL 写成：

SELECT * FROM crm_leads WHERE region