Baserow Docker 部署实战All-in-One 镜像快速上线、升级、备份与无状态水平扩展【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow本文以 Baserow 官方文档docs/installation/install-with-docker.md为核心系统讲解如何通过 Docker 部署 Baserow从一条docker run命令启动本地实例到域名自动 HTTPS、外部 PostgreSQL/Redis/SMTP 接入、PostgreSQL 11 到 15 的数据目录升级、整卷备份与数据库级备份恢复、健康检查、管理命令执行直至无状态水平扩展部署。结合当前仓库中deploy/all-in-one下的 Dockerfile、入口脚本baserow.sh、Supervisor 进程配置与 Caddyfile 源码文章进一步解释每个环境变量、启动参数背后的实际行为帮助读者既能快速复制命令又能理解容器内部各服务的编排原理。前置条件与镜像总览该部署指南假定你已安装 Docker最低要求 Docker 19.03官方强烈建议安装最新版本可用docker -v检查并具备运行容器的权限如需从零安装可参考 install-on-ubuntu.md。baserow/baserow:2.3.3当前仓库 docker-compose.all-in-one.yml 中使用的版本是一个All-in-One镜像默认把 Baserow 的所有服务跑在单个容器里以获得最大易用性。它面向简单单机部署或 Google Cloud Run 这类简单容器服务如果目标是水平扩展例如 K8S 场景官方建议改用 install-with-k8s.md 所述的baserow/backend和baserow/web-frontend单服务镜像。镜像内置能力来自文档Image Feature Overview一节默认在容器内部运行一个 Postgres 数据库和一个 Redis 服务器所有持久化数据存放在容器的/baserow/data目录。设置DATABASE_URL或一组DATABASE_...变量即可禁用内置 Postgres、改连外部 Postgres。官方强烈建议任何生产部署都这么做这样其他服务或进程也能方便地访问同一个数据库。设置REDIS_URL或一组REDIS_...变量即可禁用内置 Redis、改连外部 Redis。所有服务跑在一个预配置好的 Caddy 反向代理之后。将BASEROW_CADDY_ADDRESSES设为https://YOUR_DOMAIN.com就会自动启用 HTTPS密钥和证书保存在/baserow/data/caddy。提供一套 CLI既可以对运行中的容器执行管理命令也可以只对 Baserow 数据卷执行一次性命令。从源码看 All-in-One 镜像的内部结构结合 deploy/all-in-one/Dockerfile 可以验证上述描述并了解容器内部实际做了什么镜像基于python:3.14.6-slim-trixie构建通过多阶段复制把baserow/backend与baserow/web-frontend镜像中的代码、Node.js 运行时、su-exec、wasmtime等组件聚合到一起prod构建阶段额外安装 PostgreSQL 15含 pgvector 扩展和 Redis与默认内嵌数据库和缓存的说法一致。镜像内置用户 UID/GID 固定为9999:9999baserow_docker_user保证挂载卷的权限一致性默认数据目录由DATA_DIR/baserow/data环境变量指定插件目录默认为/baserow/data/plugins。Dockerfile 中定义了HEALTHCHECK --interval60s CMD [/bin/bash, /baserow/backend/docker/docker-entrypoint.sh, backend-healthcheck]对应文档Running healthchecks一节所说的镜像自带健康检查。入口为ENTRYPOINT [/baserow.sh]、默认CMD [start]EXPOSE 80。/baserow.sh即仓库中的 deploy/all-in-one/baserow.sh它实现了一个小型 CLI支持start、start-only-db、backend-cmd、backend-cmd-with-db、web-frontend-cmd、install-plugin、uninstall-plugin、list-plugins、help等命令正是文档中Provides a CLI for execing admin commands的实现。容器内部的进程编排由 deploy/all-in-one/supervisor/supervisor.conf 定义包括以下程序组caddy反向代理默认以 root 运行以便绑定特权端口 80BASEROW_CADDY_USER默认为root见 deploy/all-in-one/supervisor/default_baserow_env.sh。webfrontendNode.js 启动的 Nuxt 前端。backendGunicorn 启动的 Django REST API生产模式下BASEROW_BACKEND_STARTUP_COMMAND默认为gunicorn。celeryworker/exportworker/beatworker分别处理常规后台任务、导出/导入类慢任务和定时CRON任务。baserow-watcher等待各服务就绪后打印 Baserow is now available at ... 日志这正是升级流程中需要观察的关键行。一个eventlistener:processes监听器任何核心进程崩溃时会让整个 supervisor 退出、容器停止避免半死状态。请求路由由仓库根目录的 Caddyfile 决定/api/*、/ws/*、/mcp/*、/assistant/*等路径反向代理到后端localhost:8000/media/*用户文件与/static/*静态资源由 Caddy 直接服务其余请求落到localhost:3000的前端。Caddyfile 顶部的on_demand_tls块则按需为 Application Builder 的额外域名签发证书。快速开始Quick Start执行下面的命令即可在本地启动一个监听 80 端口的 Baserow 服务器此时只能从运行服务器的机器通过http://localhost访问docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttp://localhost \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3常用调整项把BASEROW_PUBLIC_URL改成https://YOUR_DOMAIN或http://YOUR_IP即可启用外部访问。注意这个地址必须与浏览器地址栏中完全一致任何不同的地址都会被当作已发布的应用处理。追加-e BASEROW_CADDY_ADDRESSES:443可启用 Caddy 的自动 HTTPS。可选追加-e DATABASE_URLpostgresql://user:pwdhost:port/db使用外部 PostgreSQL。可选追加-e REDIS_URLredis://user:pwdhost:port使用外部 Redis。安全警告Docker 与 ufw 防火墙之间存在一个已知缺陷——默认情况下 Docker 在0.0.0.0上暴露端口时会绕过 ufw 的防火墙规则把上述容器直接暴露到机器所在的网络上。如果不想公开访问请改用-p 127.0.0.1:80:80 -p 127.0.0.1:443:443使 Baserow 仅在本机可访问。BASEROW_PUBLIC_URL与BASEROW_CADDY_ADDRESSES的默认值可以在 deploy/all-in-one/supervisor/default_baserow_env.sh 中确认分别为http://localhost与:80与上面的快速开始命令完全对应。如果你更习惯 compose 文件仓库根目录提供了极简的 docker-compose.all-in-one.yml等价于上面的 run 命令而面向高级用户的 docker-compose.yml 则把 caddy、backend、web-frontend、三个 celery 角色、dbpgvector/pgvector:pg15、redis 拆成独立服务并要求通过SECRET_KEY、DATABASE_PASSWORD、REDIS_PASSWORD等环境变量显式配置——文件头部注释也明确提示普通用户应优先使用docker-compose.all-in-one.yml。从旧版本升级 Baserow升级流程按文档共 8 步原文编号即如此强烈建议先备份数据参见文末备份章节。停止现有容器docker stop baserow把docker run命令中的镜像版本号改为新版本启动一个全新容器。由于旧容器尚未删除新容器必须换名否则会报response from daemon: Conflict. The container name /baserow is already in use# 旧容器尚未删除所以新容器必须用不同名字避免重名冲突 docker run \ -d \ --name baserow_version_REPLACE_WITH_NEW_VERSION \ # YOUR STANDARD ARGS HERE baserow/baserow:REPLACE_WITH_LATEST_VERSIONBaserow 会在启动时自动完成升级跟踪日志监控进度docker logs -f baserow_version_REPLACE_WITH_NEW_VERSION看到如下日志行即代表升级完成、服务恢复可用[BASEROW-WATCHER][2022-05-10 08:44:46] Baserow is now available at ...访问页面确认一切正常、数据仍在。一切正常后即可删除旧容器警告如果你此前没有用卷持久化/baserow/data删除容器将永久丢失其中全部数据。docker rm baserow这条Baserow is now available日志由 supervisor 配置中的baserow-watcher程序deploy/all-in-one/supervisor/baserow-watcher.sh打印它是启动链路的最后一环在 Caddy、webfrontend、backend、celeryworker、exportworker、beatworker 均就绪后才输出。启动时数据库迁移由MIGRATE_ON_STARTUP默认true控制模板同步由SYNC_TEMPLATES_ON_STARTUP默认true控制这两个默认值同样来自 deploy/all-in-one/supervisor/default_baserow_env.sh。升级内嵌 PostgreSQL 数据库11 → 152023 年 11 月PostgreSQL 发布了 11 版本的最终更新并宣布该版本生命周期结束11 不再获得安全与缺陷修复。如果你使用的是内嵌 PostgreSQL即启动时没有提供 Postgres 连接环境变量区别于提供连接信息的外部 Postgres且数据目录是用 PostgreSQL 11 初始化的那么当你重启或运行新版本 Baserow 时会发现它无法启动并报错——需要先把数据目录升级到 PostgreSQL 15后者才是 Baserow 官方支持的版本。Baserow 提供了专用镜像来自动完成数据目录升级。如果暂不打算升级可跳到下面的Legacy PostgreSQL 版本小节但要清楚 11 只会被支持有限时间。升级步骤注意动手之前务必先备份 Baserow 实例以防数据丢失。用docker ps确认没有任何 Baserow 实例在运行若在运行用docker stop baserow停止。运行自动升级镜像docker run \ --name baserow-pgautoupgrade \ # ALL THE ARGUMENTS YOU NORMALLY ADD TO YOUR BASEROW INSTANCE --restart no \ baserow/baserow-pgautoupgrade:1.30.1升级成功时容器会打印成功信息并退出之后按原方式启动 Baserow 即可。升级失败时该镜像会输出详细日志指出失败位置请复制全部日志向 Baserow 社区求助。Legacy PostgreSQL 版本自 2025 年 1 月 1 日起Baserow 不再发布内置 PostgreSQL 11 的新镜像。如果你在用 1.30 之前的版本运行内嵌 PostgreSQL 且想升级到最新版必须先用pgautoupgrade镜像把 PostgreSQL 升到 15再升级 Baserow 本体。如果坚持不升级1.30.1 是最后一个内置 PostgreSQL 11 的镜像版本且不会再获得任何更新。运行基于 legacy PostgreSQL 11 的最新 Baserow 镜像docker run \ --name baserow-pg11 \ # ALL THE ARGUMENTS YOU NORMALLY ADD TO YOUR BASEROW INSTANCE --restart unless-stopped \ baserow/baserow-pg11:1.30.1当前 All-in-One 镜像的 deploy/all-in-one/Dockerfile 中POSTGRES_VERSION15并安装postgresql-15-pgvector印证了官方支持版本为 15带向量扩展。常用场景示例命令更完整的环境变量说明见 configuration.md。以下示例完整继承原文档。使用域名并启用自动 HTTPS已有域名并正确配置 DNS 时可以让 Caddy 自动处理 HTTPS让 Baserow 出现在该域名下如果仍想通过http://localhost从服务器本机访问请在BASEROW_CADDY_ADDRESSES末尾追加,http://localhost。docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.REPLACE_WITH_YOUR_DOMAIN.com \ -e BASEROW_CADDY_ADDRESSES:443 \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3在已处理 SSL 的反向代理之后docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.yourdomain.com \ -v baserow_data:/baserow/data \ -p 80:80 \ --restart unless-stopped \ baserow/baserow:2.3.3使用非标准 HTTP 端口docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.yourdomain.com:3001 \ -v baserow_data:/baserow/data \ -p 3001:80 \ --restart unless-stopped \ baserow/baserow:2.3.3使用外部 PostgreSQL 服务器docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.yourdomain.com \ -e DATABASE_HOSTTODO \ -e DATABASE_NAMETODO \ -e DATABASE_USERTODO \ -e DATABASE_PASSWORDTODO \ -e DATABASE_PORTTODO \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3使用外部 Redis 服务器docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.yourdomain.com \ -e REDIS_HOSTTODO \ -e REDIS_USERTODO \ -e REDIS_PASSWORDTODO \ -e REDIS_PORTTODO \ -e REDIS_PROTOCOLTODO \ -e REDIS_SSL_CERT_REQSTODO \ -e REDIS_SSL_CA_CERTSTODO \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3使用外部邮件服务器docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.yourdomain.com \ -e EMAIL_SMTPTrue \ -e EMAIL_SMTP_HOSTTODO \ -e EMAIL_SMTP_PORTTODO \ -e EMAIL_SMTP_USERTODO \ -e EMAIL_SMTP_PASSWORDTODO \ -e EMAIL_SMTP_USE_TLS \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3使用与 Baserow 容器同宿主的 PostgreSQL以 Ubuntu 自带的 postgresql 为例其他发行版需自行找到配置路径sudo ls /etc/postgresql/查看安装的 PostgreSQL 版本。以 root 编辑/etc/postgresql/YOUR_PSQL_VERSION/main/postgresql.conf。找到被注释的# listen_addresses行。改为listen_addresses * # what IP address(es) to listen on;。以 root 编辑/etc/postgresql/YOUR_PSQL_VERSION/main/pg_hba.conf。在文件末尾追加允许 Docker 容器连接的一行host all all 172.17.0.0/16 md5重启 PostgreSQL 使配置生效sudo systemctl restart postgresql。用sudo less /var/log/postgresql/postgresql-YOUR_PSQL_VERSION-main.log检查日志无错误。以如下方式运行 Baserow--add-host host.docker.internal:host-gateway让容器能通过host.docker.internal访问宿主机docker run \ -d \ --name baserow \ --add-host host.docker.internal:host-gateway \ -e BASEROW_PUBLIC_URLhttp://localhost \ -e DATABASE_HOSThost.docker.internal \ -e DATABASE_PORT5432 \ -e DATABASE_NAMEYOUR_DATABASE_NAME \ -e DATABASE_USERYOUR_DATABASE_USERNAME \ -e DATABASE_PASSWORDREPLACE_WITH_YOUR_DATABASE_PASSWORD \ --restart unless-stopped \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ baserow/baserow:2.3.3从入口脚本 deploy/all-in-one/baserow.sh 可以看到官方专门内置了一个防呆检查如果DATABASE_HOST包含localhost且未设置DISABLE_LOCALHOST_CHECKyes容器会直接报错退出提示你必须加--add-host host.docker.internal:host-gateway并使用DATABASE_HOSThost.docker.internal——因为容器内的 localhost 是容器自身不是宿主机。对REDIS_HOSTlocalhost也有类似的检查。使用文件提供密钥*_FILE 变体DATABASE_PASSWORD、SECRET_KEY和REDIS_PASSWORD都可以通过对应的*_FILE变体从文件读取该机制的源码在 deploy/all-in-one/baserow.sh 的file_env函数中逻辑与 Docker 官方 postgres 镜像的 secrets 支持一致同一个变量与_FILE变体同时设置会直接报错退出echo your_redis_password .your_redis_password echo your_secret_key .your_secret_key echo your_pg_password .your_pg_password docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttp://localhost \ -e REDIS_PASSWORD_FILE/baserow/.your_redis_password \ -e SECRET_KEY_FILE/baserow/.your_secret_key \ -e DATABASE_PASSWORD_FILE/baserow/.your_pg_password \ -e EMAIL_SMTP_PASSWORD_FILE/baserow/.your_smtp_password \ --restart unless-stopped \ -v $PWD/.your_redis_password:/baserow/.your_redis_password \ -v $PWD/.your_secret_key:/baserow/.your_secret_key \ -v $PWD/.your_pg_password:/baserow/.your_pg_password \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ baserow/baserow:2.3.3此外baserow.sh中的create_secret_env_if_missing函数表明若未显式提供REDIS_PASSWORD/SECRET_KEY/BASEROW_JWT_SIGNING_KEY内嵌 Postgres 时还有DATABASE_PASSWORD首次启动会在$DATA_DIR下自动生成随机密钥文件.redispass、.secret、.jwt_signing_key、.pgpass并记住后续启动自动导入——这就是数据卷必须持久化的另一层原因。只启动内嵌数据库如果你要直接访问内嵌的 PostgreSQLdocker run -it \ --rm \ --name baserow \ -p 5432:5432 \ -v baserow_data:/baserow/data \ baserow/baserow:2.3.3 \ start-only-db # 然后获取密码 docker exec -it baserow cat /baserow/data/.pgpass # 最后从宿主机连接 5432 端口的 Baserow postgres 数据库用户名 baserow密码如上对应baserow.sh中start-only-db分支的实现它会用一份临时的pg_hba_temp.conf追加host all all all md5行启动 Postgres 并放开监听避免误改正常内嵌 Postgres 的pg_hba.conf并提示你从$DATA_DIR/.pgpass查看密码。Application Builder 域名内置 Caddy 被配置为自动处理 Application Builder 的额外域名并视环境变量自动为这些域名获取 SSL 证书。注意要让多域名生效BASEROW_CADDY_ADDRESSES必须是:80或:443如果在那里写死了某个 URL 则多域名不会工作。默认情况下它接受任何域名的 HTTP 请求——前面还有代理时正合适当BASEROW_CADDY_ADDRESSES以https协议开头或为:443时它会重定向 HTTP 到 HTTPS 并自动处理证书这是容器直接暴露到互联网时的推荐配置。从 Caddyfile 源码可以印证其机制全局块中on_demand_tls通过ask {$PRIVATE_BACKEND_URL:localhost:8000}/api/builder/domains/ask-public-domain-exists/询问后端该域名是否属于 Builder 公开域名是才按需签发证书站点块使用tls { on_demand }并对BASEROW_PUBLIC_URL与BASEROW_EXTRA_PUBLIC_URLS匹配的域名走后端路由/api/*、/ws/*、/mcp/*、/assistant/*否则落到前端。对数据卷运行一次性命令如果不想完整启动 Baserow、只想对数据卷执行一条后端命令可以用backend-cmd-with-db参数实现上它会先拉起内嵌 Postgres 与 Redis再执行命令并在结束后清理docker run -it \ --rm \ --name baserow \ -v baserow_data:/baserow/data \ baserow/baserow:2.3.3 \ backend-cmd-with-db manage dbshell无状态部署与水平扩展该镜像也可以配置为水平可扩展的部署方式。官方建议如果目标是 K8S/Helm优先考虑baserow/backend与baserow/web-frontend单服务镜像参见 install-with-k8s.md、install-with-helm.md如果只是想方便地在 AWS ECS 或 Google Cloud Run 上水平扩展baserow/baserow同样可以用。前提条件水平扩展要求所有状态都外置不能留在容器或卷里。你需要一个 PostgreSQL 数据库参见 supported.md 的支持列表一个 Redis同上以下任一种文件存储用于上传/下载用户文件AWS S3 或兼容服务Google Cloud StorageAzure Cloud Storage 桶可以挂载进每一个容器的某种共享卷。推荐环境变量设置全部相关DATABASE_*变量指向外部 Postgres设置全部相关REDIS_*变量指向外部 Redis必须设置DISABLE_VOLUME_CHECKyes镜像里有一个面向初级用户的启动检查会验证/baserow/data是否挂载了外部卷源码见 deploy/all-in-one/baserow.sh 中基于mount输出的检查未通过时直接退出无状态部署时容器是临时的需要禁用该检查设置AWS_*/GC_*/AZURE_*变量连接外部文件存储服务。重要上传到这些桶中的文件 URL 必须能被 Baserow 用户的浏览器直接访问确保容器始终有 CPU 时间片可用因为内部 CRON 服务会周期性触发后台任务。扩展相关的可调参数BASEROW_AMOUNT_OF_GUNICORN_WORKERS控制每个容器中的 REST API worker 数量API 的主要执行者。BASEROW_AMOUNT_OF_WORKERS控制后台 Celery worker 数量它们执行实时协作任务、清理任务和大型导出/导入等慢任务。当容器数量很多时每个容器通常只需 12 个后台 worker因为它们通过 Redis 汇集成一个任务池从任意容器领取任务。设置BASEROW_RUN_MINIMALyes且BASEROW_AMOUNT_OF_WORKERS1可让镜像只启动更少的内部进程以降低内存占用——此时只会有一个 Celery 进程同时处理快慢两个队列。副作用是单个大数据库快照等慢任务会延迟同队列中的快任务例如向所有查看该表的实时推送行更新信号。这两个 worker 变量的默认值可在 deploy/all-in-one/supervisor/default_baserow_env.sh 中确认BASEROW_AMOUNT_OF_WORKERS默认1、BASEROW_AMOUNT_OF_GUNICORN_WORKERS默认3。备份与恢复Baserow 默认把全部持久化数据存放在/baserow/data目录。强烈建议挂载 Docker 卷到该路径以持久化数据避免误删容器导致数据丢失。以下备份/恢复操作最好在未使用中的 Baserow 服务器上执行。备份整个 Baserow注意此方式仅在你没有使用外部 PostgreSQL 时有效。它会备份Baserow 的 Postgres 数据库这是 PGDATA 目录的原始拷贝可移植性差如需可移植的数据库备份见下节Caddy 配置与数据包括运行时对 Caddy 的修改以及自动签发的 SSL 证书/密钥Redis 状态并非严格必需用户上传文件仅当未配置外部文件存储时。命令假定你以-v baserow_data:/baserow/data运行如挂载方式不同请相应调整# 备份前先确保 Baserow 已停止 docker stop baserow docker run --rm -v baserow_data:/baserow/data -v $PWD:/backup ubuntu tar cvf /backup/backup.tar /baserow/data恢复整个 Baserow# 恢复前先确保 Baserow 已停止 docker stop baserow docker run --rm -v baserow_data:/baserow/data -v $PWD:/backup ubuntu tar cvf /backup/backup.tar /baserow/data docker run --rm -v new_baserow_data_volume:/results -v $PWD:/backup ubuntu bash -c mkdir -p /results/ cd /results tar xvf /backup/backup.tar --strip 2 # 现在用常规 run 命令以新的数据卷启动 Baserow docker run -v new_baserow_data_volume:/baserow/data .....只备份 Postgres 数据库请确保只备份一个没有被运行中的 Baserow 或其他进程正在改动的数据库。Baserow 自身的所有数据都存于 Postgres可执行# 先阅读该命令的帮助信息 docker run -it --rm -v baserow_data:/baserow/data baserow/baserow:2.3.3 \ backend-cmd-with-db backup --help # 停止 Baserow 实例 docker stop baserow # 下面命令把 Baserow 备份到 baserow_data 卷中的 backups 目录 docker run -it --rm -v baserow_data:/baserow/data baserow/baserow:2.3.3 \ backend-cmd-with-db backup -f /baserow/data/backups/backup.tar.gz # 或者备份到宿主机文件上 docker run -it --rm -v baserow_data:/baserow/data -v $PWD:/baserow/host \ baserow/baserow:2.3.3 backend-cmd-with-db backup -f /baserow/host/backup.tar.gz只恢复 Postgres 数据库恢复时必须恢复到全新的 Baserow 数据卷中# 停止 Baserow 实例 docker stop baserow # 从包含备份包的新卷恢复 docker run -it --rm \ -v old_baserow_data_volume_containing_the_backup_tar_gz:/baserow/old_data \ -v new_baserow_data_volume_to_restore_into:/baserow/data \ baserow/baserow:2.3.3 backend-cmd-with-db restore -f /baserow/old_data/backup.tar.gz # 或从宿主机文件恢复 docker run -it --rm \ -v baserow_data:/baserow/data -v \ $(pwd):/baserow/host \ baserow/baserow:2.3.3 backend-cmd-with-db restore -f /baserow/host/backup.tar.gz健康检查与管理命令镜像 Dockerfile 已定义了HEALTHCHECK间隔 60 秒执行backend-healthcheck支持健康检查的软件会直接使用它。若想在运行中的容器上手动触发健康检查docker exec baserow ./baserow.sh backend-cmd backend-healthcheck # 查看所有可用健康检查 docker exec baserow ./baserow.sh backend-cmd help对名为baserow的现有容器执行 Baserow 或 Django 管理命令docker exec baserow ./baserow.sh backend-cmd manage # 例如为运行中的 Baserow 迁移数据库 docker exec baserow ./baserow.sh backend-cmd manage migrate这两条命令中的backend-cmd对应 deploy/all-in-one/baserow.sh 中cd /baserow/backend后执行docker-entrypoint.sh的分支最终落到后端镜像自带的 Django 管理命令入口。自定义 Baserow挂载自定义配置文件Baserow 启动时会自动 source 位于/baserow/supervisor/env/或/baserow/data/env/下的所有.sh文件入口脚本 deploy/all-in-one/baserow.sh 会先导入/baserow/supervisor/env/*.sh再导入$DATA_DIR/env/*.sh最后才加载默认环境文件。利用这一点可以创建单一配置文件来配置 Baserowcustom_baserow_conf.sh EOF export BASEROW_PUBLIC_URLtodo export BASEROW_CADDY_ADDRESSEStodo # 你可以在这里编写任意 Bash 逻辑按条件配置 Baserow EOF docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttp://localhost \ -v $PWD/custom_baserow_conf.sh /baserow/supervisor/custom_baserow_conf.sh \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3也可以直接把配置存放在卷的baserow_data/env目录下这样每次挂载该数据卷都会自动加载。基于 Baserow 构建自己的镜像FROM baserow/baserow:2.3.3 # /baserow/supervisor/env/ 下的任何 .sh 文件都会在启动时被 source 加载 # 适合存放你自己的环境变量覆盖。 COPY custom_env.sh /baserow/supervisor/env/custom_env.sh # 设置 DATA_DIR 环境变量可改变 Baserow 持久化数据的存放位置 # 启动时 Baserow 会尝试 chown 并正确初始化该目录。 ENV DATA_DIR/baserow/data # 该镜像默认烧录了 UID/GID 为 9999:9999 的用户。设置此变量可改变 # Caddy、backend、Celery 与 web-frontend 服务运行时的用户。 # 但请注意默认入口必须以 root 运行使用 USER 指令可能会破坏启动流程。 ENV DOCKER_USERbaserow_docker_userUID/GID 9999:9999 的内置用户与DOCKER_USER环境变量在 deploy/all-in-one/Dockerfile 的ARG UID9999/ARG GID9999和useradd步骤中得到印证DATA_DIR的默认值/baserow/data则在 Dockerfile 的ENV与 deploy/all-in-one/supervisor/default_baserow_env.sh 中均有定义。小结单机最简单路径一条docker run命令 -v baserow_data:/baserow/data卷BASEROW_PUBLIC_URL决定可访问地址BASEROW_CADDY_ADDRESSES:443一键获得自动 HTTPS。生产建议外部 PostgreSQL/Redis、文件存储外置DISABLE_VOLUME_CHECKyes、按BASEROW_AMOUNT_OF_GUNICORN_WORKERS/BASEROW_AMOUNT_OF_WORKERS调节并发或用BASEROW_RUN_MINIMALyes降低内存占用。升级前先整卷或数据库级备份内嵌 Postgres 11 用户必须先用baserow-pgautoupgrade镜像升到 15。日常管理依赖镜像内置 CLIbackend-cmd运行中容器、backend-cmd-with-db一次性命令、start-only-db仅数据库、install-plugin等均可用docker run --rm -it [-v baserow:$DATA_DIR] baserow help查看全部命令。【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Baserow Docker 部署实战All-in-One 镜像快速上线、升级、备份与无状态水平扩展【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow本文以 Baserow 官方文档docs/installation/install-with-docker.md为核心系统讲解如何通过 Docker 部署 Baserow从一条docker run命令启动本地实例到域名自动 HTTPS、外部 PostgreSQL/Redis/SMTP 接入、PostgreSQL 11 到 15 的数据目录升级、整卷备份与数据库级备份恢复、健康检查、管理命令执行直至无状态水平扩展部署。结合当前仓库中deploy/all-in-one下的 Dockerfile、入口脚本baserow.sh、Supervisor 进程配置与 Caddyfile 源码文章进一步解释每个环境变量、启动参数背后的实际行为帮助读者既能快速复制命令又能理解容器内部各服务的编排原理。前置条件与镜像总览该部署指南假定你已安装 Docker最低要求 Docker 19.03官方强烈建议安装最新版本可用docker -v检查并具备运行容器的权限如需从零安装可参考 install-on-ubuntu.md。baserow/baserow:2.3.3当前仓库 docker-compose.all-in-one.yml 中使用的版本是一个All-in-One镜像默认把 Baserow 的所有服务跑在单个容器里以获得最大易用性。它面向简单单机部署或 Google Cloud Run 这类简单容器服务如果目标是水平扩展例如 K8S 场景官方建议改用 install-with-k8s.md 所述的baserow/backend和baserow/web-frontend单服务镜像。镜像内置能力来自文档Image Feature Overview一节默认在容器内部运行一个 Postgres 数据库和一个 Redis 服务器所有持久化数据存放在容器的/baserow/data目录。设置DATABASE_URL或一组DATABASE_...变量即可禁用内置 Postgres、改连外部 Postgres。官方强烈建议任何生产部署都这么做这样其他服务或进程也能方便地访问同一个数据库。设置REDIS_URL或一组REDIS_...变量即可禁用内置 Redis、改连外部 Redis。所有服务跑在一个预配置好的 Caddy 反向代理之后。将BASEROW_CADDY_ADDRESSES设为https://YOUR_DOMAIN.com就会自动启用 HTTPS密钥和证书保存在/baserow/data/caddy。提供一套 CLI既可以对运行中的容器执行管理命令也可以只对 Baserow 数据卷执行一次性命令。从源码看 All-in-One 镜像的内部结构结合 deploy/all-in-one/Dockerfile 可以验证上述描述并了解容器内部实际做了什么镜像基于python:3.14.6-slim-trixie构建通过多阶段复制把baserow/backend与baserow/web-frontend镜像中的代码、Node.js 运行时、su-exec、wasmtime等组件聚合到一起prod构建阶段额外安装 PostgreSQL 15含 pgvector 扩展和 Redis与默认内嵌数据库和缓存的说法一致。镜像内置用户 UID/GID 固定为9999:9999baserow_docker_user保证挂载卷的权限一致性默认数据目录由DATA_DIR/baserow/data环境变量指定插件目录默认为/baserow/data/plugins。Dockerfile 中定义了HEALTHCHECK --interval60s CMD [/bin/bash, /baserow/backend/docker/docker-entrypoint.sh, backend-healthcheck]对应文档Running healthchecks一节所说的镜像自带健康检查。入口为ENTRYPOINT [/baserow.sh]、默认CMD [start]EXPOSE 80。/baserow.sh即仓库中的 deploy/all-in-one/baserow.sh它实现了一个小型 CLI支持start、start-only-db、backend-cmd、backend-cmd-with-db、web-frontend-cmd、install-plugin、uninstall-plugin、list-plugins、help等命令正是文档中Provides a CLI for execing admin commands的实现。容器内部的进程编排由 deploy/all-in-one/supervisor/supervisor.conf 定义包括以下程序组caddy反向代理默认以 root 运行以便绑定特权端口 80BASEROW_CADDY_USER默认为root见 deploy/all-in-one/supervisor/default_baserow_env.sh。webfrontendNode.js 启动的 Nuxt 前端。backendGunicorn 启动的 Django REST API生产模式下BASEROW_BACKEND_STARTUP_COMMAND默认为gunicorn。celeryworker/exportworker/beatworker分别处理常规后台任务、导出/导入类慢任务和定时CRON任务。baserow-watcher等待各服务就绪后打印 Baserow is now available at ... 日志这正是升级流程中需要观察的关键行。一个eventlistener:processes监听器任何核心进程崩溃时会让整个 supervisor 退出、容器停止避免半死状态。请求路由由仓库根目录的 Caddyfile 决定/api/*、/ws/*、/mcp/*、/assistant/*等路径反向代理到后端localhost:8000/media/*用户文件与/static/*静态资源由 Caddy 直接服务其余请求落到localhost:3000的前端。Caddyfile 顶部的on_demand_tls块则按需为 Application Builder 的额外域名签发证书。快速开始Quick Start执行下面的命令即可在本地启动一个监听 80 端口的 Baserow 服务器此时只能从运行服务器的机器通过http://localhost访问docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttp://localhost \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3常用调整项把BASEROW_PUBLIC_URL改成https://YOUR_DOMAIN或http://YOUR_IP即可启用外部访问。注意这个地址必须与浏览器地址栏中完全一致任何不同的地址都会被当作已发布的应用处理。追加-e BASEROW_CADDY_ADDRESSES:443可启用 Caddy 的自动 HTTPS。可选追加-e DATABASE_URLpostgresql://user:pwdhost:port/db使用外部 PostgreSQL。可选追加-e REDIS_URLredis://user:pwdhost:port使用外部 Redis。安全警告Docker 与 ufw 防火墙之间存在一个已知缺陷——默认情况下 Docker 在0.0.0.0上暴露端口时会绕过 ufw 的防火墙规则把上述容器直接暴露到机器所在的网络上。如果不想公开访问请改用-p 127.0.0.1:80:80 -p 127.0.0.1:443:443使 Baserow 仅在本机可访问。BASEROW_PUBLIC_URL与BASEROW_CADDY_ADDRESSES的默认值可以在 deploy/all-in-one/supervisor/default_baserow_env.sh 中确认分别为http://localhost与:80与上面的快速开始命令完全对应。如果你更习惯 compose 文件仓库根目录提供了极简的 docker-compose.all-in-one.yml等价于上面的 run 命令而面向高级用户的 docker-compose.yml 则把 caddy、backend、web-frontend、三个 celery 角色、dbpgvector/pgvector:pg15、redis 拆成独立服务并要求通过SECRET_KEY、DATABASE_PASSWORD、REDIS_PASSWORD等环境变量显式配置——文件头部注释也明确提示普通用户应优先使用docker-compose.all-in-one.yml。从旧版本升级 Baserow升级流程按文档共 8 步原文编号即如此强烈建议先备份数据参见文末备份章节。停止现有容器docker stop baserow把docker run命令中的镜像版本号改为新版本启动一个全新容器。由于旧容器尚未删除新容器必须换名否则会报response from daemon: Conflict. The container name /baserow is already in use# 旧容器尚未删除所以新容器必须用不同名字避免重名冲突 docker run \ -d \ --name baserow_version_REPLACE_WITH_NEW_VERSION \ # YOUR STANDARD ARGS HERE baserow/baserow:REPLACE_WITH_LATEST_VERSIONBaserow 会在启动时自动完成升级跟踪日志监控进度docker logs -f baserow_version_REPLACE_WITH_NEW_VERSION看到如下日志行即代表升级完成、服务恢复可用[BASEROW-WATCHER][2022-05-10 08:44:46] Baserow is now available at ...访问页面确认一切正常、数据仍在。一切正常后即可删除旧容器警告如果你此前没有用卷持久化/baserow/data删除容器将永久丢失其中全部数据。docker rm baserow这条Baserow is now available日志由 supervisor 配置中的baserow-watcher程序deploy/all-in-one/supervisor/baserow-watcher.sh打印它是启动链路的最后一环在 Caddy、webfrontend、backend、celeryworker、exportworker、beatworker 均就绪后才输出。启动时数据库迁移由MIGRATE_ON_STARTUP默认true控制模板同步由SYNC_TEMPLATES_ON_STARTUP默认true控制这两个默认值同样来自 deploy/all-in-one/supervisor/default_baserow_env.sh。升级内嵌 PostgreSQL 数据库11 → 152023 年 11 月PostgreSQL 发布了 11 版本的最终更新并宣布该版本生命周期结束11 不再获得安全与缺陷修复。如果你使用的是内嵌 PostgreSQL即启动时没有提供 Postgres 连接环境变量区别于提供连接信息的外部 Postgres且数据目录是用 PostgreSQL 11 初始化的那么当你重启或运行新版本 Baserow 时会发现它无法启动并报错——需要先把数据目录升级到 PostgreSQL 15后者才是 Baserow 官方支持的版本。Baserow 提供了专用镜像来自动完成数据目录升级。如果暂不打算升级可跳到下面的Legacy PostgreSQL 版本小节但要清楚 11 只会被支持有限时间。升级步骤注意动手之前务必先备份 Baserow 实例以防数据丢失。用docker ps确认没有任何 Baserow 实例在运行若在运行用docker stop baserow停止。运行自动升级镜像docker run \ --name baserow-pgautoupgrade \ # ALL THE ARGUMENTS YOU NORMALLY ADD TO YOUR BASEROW INSTANCE --restart no \ baserow/baserow-pgautoupgrade:1.30.1升级成功时容器会打印成功信息并退出之后按原方式启动 Baserow 即可。升级失败时该镜像会输出详细日志指出失败位置请复制全部日志向 Baserow 社区求助。Legacy PostgreSQL 版本自 2025 年 1 月 1 日起Baserow 不再发布内置 PostgreSQL 11 的新镜像。如果你在用 1.30 之前的版本运行内嵌 PostgreSQL 且想升级到最新版必须先用pgautoupgrade镜像把 PostgreSQL 升到 15再升级 Baserow 本体。如果坚持不升级1.30.1 是最后一个内置 PostgreSQL 11 的镜像版本且不会再获得任何更新。运行基于 legacy PostgreSQL 11 的最新 Baserow 镜像docker run \ --name baserow-pg11 \ # ALL THE ARGUMENTS YOU NORMALLY ADD TO YOUR BASEROW INSTANCE --restart unless-stopped \ baserow/baserow-pg11:1.30.1当前 All-in-One 镜像的 deploy/all-in-one/Dockerfile 中POSTGRES_VERSION15并安装postgresql-15-pgvector印证了官方支持版本为 15带向量扩展。常用场景示例命令更完整的环境变量说明见 configuration.md。以下示例完整继承原文档。使用域名并启用自动 HTTPS已有域名并正确配置 DNS 时可以让 Caddy 自动处理 HTTPS让 Baserow 出现在该域名下如果仍想通过http://localhost从服务器本机访问请在BASEROW_CADDY_ADDRESSES末尾追加,http://localhost。docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.REPLACE_WITH_YOUR_DOMAIN.com \ -e BASEROW_CADDY_ADDRESSES:443 \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3在已处理 SSL 的反向代理之后docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.yourdomain.com \ -v baserow_data:/baserow/data \ -p 80:80 \ --restart unless-stopped \ baserow/baserow:2.3.3使用非标准 HTTP 端口docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.yourdomain.com:3001 \ -v baserow_data:/baserow/data \ -p 3001:80 \ --restart unless-stopped \ baserow/baserow:2.3.3使用外部 PostgreSQL 服务器docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.yourdomain.com \ -e DATABASE_HOSTTODO \ -e DATABASE_NAMETODO \ -e DATABASE_USERTODO \ -e DATABASE_PASSWORDTODO \ -e DATABASE_PORTTODO \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3使用外部 Redis 服务器docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.yourdomain.com \ -e REDIS_HOSTTODO \ -e REDIS_USERTODO \ -e REDIS_PASSWORDTODO \ -e REDIS_PORTTODO \ -e REDIS_PROTOCOLTODO \ -e REDIS_SSL_CERT_REQSTODO \ -e REDIS_SSL_CA_CERTSTODO \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3使用外部邮件服务器docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttps://www.yourdomain.com \ -e EMAIL_SMTPTrue \ -e EMAIL_SMTP_HOSTTODO \ -e EMAIL_SMTP_PORTTODO \ -e EMAIL_SMTP_USERTODO \ -e EMAIL_SMTP_PASSWORDTODO \ -e EMAIL_SMTP_USE_TLS \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3使用与 Baserow 容器同宿主的 PostgreSQL以 Ubuntu 自带的 postgresql 为例其他发行版需自行找到配置路径sudo ls /etc/postgresql/查看安装的 PostgreSQL 版本。以 root 编辑/etc/postgresql/YOUR_PSQL_VERSION/main/postgresql.conf。找到被注释的# listen_addresses行。改为listen_addresses * # what IP address(es) to listen on;。以 root 编辑/etc/postgresql/YOUR_PSQL_VERSION/main/pg_hba.conf。在文件末尾追加允许 Docker 容器连接的一行host all all 172.17.0.0/16 md5重启 PostgreSQL 使配置生效sudo systemctl restart postgresql。用sudo less /var/log/postgresql/postgresql-YOUR_PSQL_VERSION-main.log检查日志无错误。以如下方式运行 Baserow--add-host host.docker.internal:host-gateway让容器能通过host.docker.internal访问宿主机docker run \ -d \ --name baserow \ --add-host host.docker.internal:host-gateway \ -e BASEROW_PUBLIC_URLhttp://localhost \ -e DATABASE_HOSThost.docker.internal \ -e DATABASE_PORT5432 \ -e DATABASE_NAMEYOUR_DATABASE_NAME \ -e DATABASE_USERYOUR_DATABASE_USERNAME \ -e DATABASE_PASSWORDREPLACE_WITH_YOUR_DATABASE_PASSWORD \ --restart unless-stopped \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ baserow/baserow:2.3.3从入口脚本 deploy/all-in-one/baserow.sh 可以看到官方专门内置了一个防呆检查如果DATABASE_HOST包含localhost且未设置DISABLE_LOCALHOST_CHECKyes容器会直接报错退出提示你必须加--add-host host.docker.internal:host-gateway并使用DATABASE_HOSThost.docker.internal——因为容器内的 localhost 是容器自身不是宿主机。对REDIS_HOSTlocalhost也有类似的检查。使用文件提供密钥*_FILE 变体DATABASE_PASSWORD、SECRET_KEY和REDIS_PASSWORD都可以通过对应的*_FILE变体从文件读取该机制的源码在 deploy/all-in-one/baserow.sh 的file_env函数中逻辑与 Docker 官方 postgres 镜像的 secrets 支持一致同一个变量与_FILE变体同时设置会直接报错退出echo your_redis_password .your_redis_password echo your_secret_key .your_secret_key echo your_pg_password .your_pg_password docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttp://localhost \ -e REDIS_PASSWORD_FILE/baserow/.your_redis_password \ -e SECRET_KEY_FILE/baserow/.your_secret_key \ -e DATABASE_PASSWORD_FILE/baserow/.your_pg_password \ -e EMAIL_SMTP_PASSWORD_FILE/baserow/.your_smtp_password \ --restart unless-stopped \ -v $PWD/.your_redis_password:/baserow/.your_redis_password \ -v $PWD/.your_secret_key:/baserow/.your_secret_key \ -v $PWD/.your_pg_password:/baserow/.your_pg_password \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ baserow/baserow:2.3.3此外baserow.sh中的create_secret_env_if_missing函数表明若未显式提供REDIS_PASSWORD/SECRET_KEY/BASEROW_JWT_SIGNING_KEY内嵌 Postgres 时还有DATABASE_PASSWORD首次启动会在$DATA_DIR下自动生成随机密钥文件.redispass、.secret、.jwt_signing_key、.pgpass并记住后续启动自动导入——这就是数据卷必须持久化的另一层原因。只启动内嵌数据库如果你要直接访问内嵌的 PostgreSQLdocker run -it \ --rm \ --name baserow \ -p 5432:5432 \ -v baserow_data:/baserow/data \ baserow/baserow:2.3.3 \ start-only-db # 然后获取密码 docker exec -it baserow cat /baserow/data/.pgpass # 最后从宿主机连接 5432 端口的 Baserow postgres 数据库用户名 baserow密码如上对应baserow.sh中start-only-db分支的实现它会用一份临时的pg_hba_temp.conf追加host all all all md5行启动 Postgres 并放开监听避免误改正常内嵌 Postgres 的pg_hba.conf并提示你从$DATA_DIR/.pgpass查看密码。Application Builder 域名内置 Caddy 被配置为自动处理 Application Builder 的额外域名并视环境变量自动为这些域名获取 SSL 证书。注意要让多域名生效BASEROW_CADDY_ADDRESSES必须是:80或:443如果在那里写死了某个 URL 则多域名不会工作。默认情况下它接受任何域名的 HTTP 请求——前面还有代理时正合适当BASEROW_CADDY_ADDRESSES以https协议开头或为:443时它会重定向 HTTP 到 HTTPS 并自动处理证书这是容器直接暴露到互联网时的推荐配置。从 Caddyfile 源码可以印证其机制全局块中on_demand_tls通过ask {$PRIVATE_BACKEND_URL:localhost:8000}/api/builder/domains/ask-public-domain-exists/询问后端该域名是否属于 Builder 公开域名是才按需签发证书站点块使用tls { on_demand }并对BASEROW_PUBLIC_URL与BASEROW_EXTRA_PUBLIC_URLS匹配的域名走后端路由/api/*、/ws/*、/mcp/*、/assistant/*否则落到前端。对数据卷运行一次性命令如果不想完整启动 Baserow、只想对数据卷执行一条后端命令可以用backend-cmd-with-db参数实现上它会先拉起内嵌 Postgres 与 Redis再执行命令并在结束后清理docker run -it \ --rm \ --name baserow \ -v baserow_data:/baserow/data \ baserow/baserow:2.3.3 \ backend-cmd-with-db manage dbshell无状态部署与水平扩展该镜像也可以配置为水平可扩展的部署方式。官方建议如果目标是 K8S/Helm优先考虑baserow/backend与baserow/web-frontend单服务镜像参见 install-with-k8s.md、install-with-helm.md如果只是想方便地在 AWS ECS 或 Google Cloud Run 上水平扩展baserow/baserow同样可以用。前提条件水平扩展要求所有状态都外置不能留在容器或卷里。你需要一个 PostgreSQL 数据库参见 supported.md 的支持列表一个 Redis同上以下任一种文件存储用于上传/下载用户文件AWS S3 或兼容服务Google Cloud StorageAzure Cloud Storage 桶可以挂载进每一个容器的某种共享卷。推荐环境变量设置全部相关DATABASE_*变量指向外部 Postgres设置全部相关REDIS_*变量指向外部 Redis必须设置DISABLE_VOLUME_CHECKyes镜像里有一个面向初级用户的启动检查会验证/baserow/data是否挂载了外部卷源码见 deploy/all-in-one/baserow.sh 中基于mount输出的检查未通过时直接退出无状态部署时容器是临时的需要禁用该检查设置AWS_*/GC_*/AZURE_*变量连接外部文件存储服务。重要上传到这些桶中的文件 URL 必须能被 Baserow 用户的浏览器直接访问确保容器始终有 CPU 时间片可用因为内部 CRON 服务会周期性触发后台任务。扩展相关的可调参数BASEROW_AMOUNT_OF_GUNICORN_WORKERS控制每个容器中的 REST API worker 数量API 的主要执行者。BASEROW_AMOUNT_OF_WORKERS控制后台 Celery worker 数量它们执行实时协作任务、清理任务和大型导出/导入等慢任务。当容器数量很多时每个容器通常只需 12 个后台 worker因为它们通过 Redis 汇集成一个任务池从任意容器领取任务。设置BASEROW_RUN_MINIMALyes且BASEROW_AMOUNT_OF_WORKERS1可让镜像只启动更少的内部进程以降低内存占用——此时只会有一个 Celery 进程同时处理快慢两个队列。副作用是单个大数据库快照等慢任务会延迟同队列中的快任务例如向所有查看该表的实时推送行更新信号。这两个 worker 变量的默认值可在 deploy/all-in-one/supervisor/default_baserow_env.sh 中确认BASEROW_AMOUNT_OF_WORKERS默认1、BASEROW_AMOUNT_OF_GUNICORN_WORKERS默认3。备份与恢复Baserow 默认把全部持久化数据存放在/baserow/data目录。强烈建议挂载 Docker 卷到该路径以持久化数据避免误删容器导致数据丢失。以下备份/恢复操作最好在未使用中的 Baserow 服务器上执行。备份整个 Baserow注意此方式仅在你没有使用外部 PostgreSQL 时有效。它会备份Baserow 的 Postgres 数据库这是 PGDATA 目录的原始拷贝可移植性差如需可移植的数据库备份见下节Caddy 配置与数据包括运行时对 Caddy 的修改以及自动签发的 SSL 证书/密钥Redis 状态并非严格必需用户上传文件仅当未配置外部文件存储时。命令假定你以-v baserow_data:/baserow/data运行如挂载方式不同请相应调整# 备份前先确保 Baserow 已停止 docker stop baserow docker run --rm -v baserow_data:/baserow/data -v $PWD:/backup ubuntu tar cvf /backup/backup.tar /baserow/data恢复整个 Baserow# 恢复前先确保 Baserow 已停止 docker stop baserow docker run --rm -v baserow_data:/baserow/data -v $PWD:/backup ubuntu tar cvf /backup/backup.tar /baserow/data docker run --rm -v new_baserow_data_volume:/results -v $PWD:/backup ubuntu bash -c mkdir -p /results/ cd /results tar xvf /backup/backup.tar --strip 2 # 现在用常规 run 命令以新的数据卷启动 Baserow docker run -v new_baserow_data_volume:/baserow/data .....只备份 Postgres 数据库请确保只备份一个没有被运行中的 Baserow 或其他进程正在改动的数据库。Baserow 自身的所有数据都存于 Postgres可执行# 先阅读该命令的帮助信息 docker run -it --rm -v baserow_data:/baserow/data baserow/baserow:2.3.3 \ backend-cmd-with-db backup --help # 停止 Baserow 实例 docker stop baserow # 下面命令把 Baserow 备份到 baserow_data 卷中的 backups 目录 docker run -it --rm -v baserow_data:/baserow/data baserow/baserow:2.3.3 \ backend-cmd-with-db backup -f /baserow/data/backups/backup.tar.gz # 或者备份到宿主机文件上 docker run -it --rm -v baserow_data:/baserow/data -v $PWD:/baserow/host \ baserow/baserow:2.3.3 backend-cmd-with-db backup -f /baserow/host/backup.tar.gz只恢复 Postgres 数据库恢复时必须恢复到全新的 Baserow 数据卷中# 停止 Baserow 实例 docker stop baserow # 从包含备份包的新卷恢复 docker run -it --rm \ -v old_baserow_data_volume_containing_the_backup_tar_gz:/baserow/old_data \ -v new_baserow_data_volume_to_restore_into:/baserow/data \ baserow/baserow:2.3.3 backend-cmd-with-db restore -f /baserow/old_data/backup.tar.gz # 或从宿主机文件恢复 docker run -it --rm \ -v baserow_data:/baserow/data -v \ $(pwd):/baserow/host \ baserow/baserow:2.3.3 backend-cmd-with-db restore -f /baserow/host/backup.tar.gz健康检查与管理命令镜像 Dockerfile 已定义了HEALTHCHECK间隔 60 秒执行backend-healthcheck支持健康检查的软件会直接使用它。若想在运行中的容器上手动触发健康检查docker exec baserow ./baserow.sh backend-cmd backend-healthcheck # 查看所有可用健康检查 docker exec baserow ./baserow.sh backend-cmd help对名为baserow的现有容器执行 Baserow 或 Django 管理命令docker exec baserow ./baserow.sh backend-cmd manage # 例如为运行中的 Baserow 迁移数据库 docker exec baserow ./baserow.sh backend-cmd manage migrate这两条命令中的backend-cmd对应 deploy/all-in-one/baserow.sh 中cd /baserow/backend后执行docker-entrypoint.sh的分支最终落到后端镜像自带的 Django 管理命令入口。自定义 Baserow挂载自定义配置文件Baserow 启动时会自动 source 位于/baserow/supervisor/env/或/baserow/data/env/下的所有.sh文件入口脚本 deploy/all-in-one/baserow.sh 会先导入/baserow/supervisor/env/*.sh再导入$DATA_DIR/env/*.sh最后才加载默认环境文件。利用这一点可以创建单一配置文件来配置 Baserowcustom_baserow_conf.sh EOF export BASEROW_PUBLIC_URLtodo export BASEROW_CADDY_ADDRESSEStodo # 你可以在这里编写任意 Bash 逻辑按条件配置 Baserow EOF docker run \ -d \ --name baserow \ -e BASEROW_PUBLIC_URLhttp://localhost \ -v $PWD/custom_baserow_conf.sh /baserow/supervisor/custom_baserow_conf.sh \ -v baserow_data:/baserow/data \ -p 80:80 \ -p 443:443 \ --restart unless-stopped \ baserow/baserow:2.3.3也可以直接把配置存放在卷的baserow_data/env目录下这样每次挂载该数据卷都会自动加载。基于 Baserow 构建自己的镜像FROM baserow/baserow:2.3.3 # /baserow/supervisor/env/ 下的任何 .sh 文件都会在启动时被 source 加载 # 适合存放你自己的环境变量覆盖。 COPY custom_env.sh /baserow/supervisor/env/custom_env.sh # 设置 DATA_DIR 环境变量可改变 Baserow 持久化数据的存放位置 # 启动时 Baserow 会尝试 chown 并正确初始化该目录。 ENV DATA_DIR/baserow/data # 该镜像默认烧录了 UID/GID 为 9999:9999 的用户。设置此变量可改变 # Caddy、backend、Celery 与 web-frontend 服务运行时的用户。 # 但请注意默认入口必须以 root 运行使用 USER 指令可能会破坏启动流程。 ENV DOCKER_USERbaserow_docker_userUID/GID 9999:9999 的内置用户与DOCKER_USER环境变量在 deploy/all-in-one/Dockerfile 的ARG UID9999/ARG GID9999和useradd步骤中得到印证DATA_DIR的默认值/baserow/data则在 Dockerfile 的ENV与 deploy/all-in-one/supervisor/default_baserow_env.sh 中均有定义。小结单机最简单路径一条docker run命令 -v baserow_data:/baserow/data卷BASEROW_PUBLIC_URL决定可访问地址BASEROW_CADDY_ADDRESSES:443一键获得自动 HTTPS。生产建议外部 PostgreSQL/Redis、文件存储外置DISABLE_VOLUME_CHECKyes、按BASEROW_AMOUNT_OF_GUNICORN_WORKERS/BASEROW_AMOUNT_OF_WORKERS调节并发或用BASEROW_RUN_MINIMALyes降低内存占用。升级前先整卷或数据库级备份内嵌 Postgres 11 用户必须先用baserow-pgautoupgrade镜像升到 15。日常管理依赖镜像内置 CLIbackend-cmd运行中容器、backend-cmd-with-db一次性命令、start-only-db仅数据库、install-plugin等均可用docker run --rm -it [-v baserow:$DATA_DIR] baserow help查看全部命令。【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
