Teable Standalone 独立版 Docker 自托管部署指南开箱即用的单机部署方案【免费下载链接】teable✨ AI Spreadsheet for Business项目地址: https://gitcode.com/GitHub_Trending/te/teableTeable 是一个构建在 PostgreSQL 之上的业务数据平台其 Standalone独立版镜像专注于交付核心能力表格、协作、API 与自动化。本篇基于仓库中的 docker-compose.yaml 与 .env 示例完整讲解 Standalone 的架构边界、编排文件、环境变量、启动流程与数据持久化细节帮助你在单机上用一条命令完成自托管并理解其底层启动机制为后续向完整版平滑演进做好准备。Standalone 定位能部署到什么程度根据 dockers/examples/standalone/README.md 与 dockers/README.md 中的对比Teable 的自托管分为两条路线能力Standalone 独立版Full-featured 完整版表格、协作、API、自动化✅✅AI 功能Chat、Agents❌✅App Builder构建并部署应用❌✅沙箱 / 预览Sandboxes / previews❌✅部署足迹单机应用 PostgreSQL单机Docker或 Kubernetes 集群Standalone 版本专门承载 Teable 的核心业务能力不需要额外组件即可运行AI 能力对话、App Builder、沙箱属于 full-featured 自托管部署。官方也明确了升级路径如果已经运行 Standalone升级到完整版时你的数据会原地保留——完整版部署是在现有应用旁边附加运行时平面不会迁移或重建数据。这一设计让 Standalone 既可以作为正式轻量部署也可以作为完整版的前置步骤。部署前置与准备部署前需要准备Docker Engine 与 Docker Compose 插件docker compose子命令可用可访问ghcr.io容器镜像仓库宿主机可用端口3000Web/API与42345PostgreSQL 对外映射用于本机直连数据库。部署目录位于仓库的 dockers/examples/standalone/其中包含两个文件docker-compose.yaml编排定义与.env全部配置变量。按 README 的说明在执行docker compose up -d之前必须查看并更新.env中的变量尤其是各类密码。docker-compose.yaml 逐项解读docker-compose.yaml 定义了三个服务、一个自定义网络与三个命名卷。teable 应用服务teable: image: ghcr.io/teableio/teable:latest restart: always ports: - 3000:3000 volumes: - teable-data:/app/.assets:rw # 也可以改用宿主目录挂载bind mount # 这样更难误删卷导致数据丢失 # - ./docker/teable/data:/app/.assets:rw env_file: - .env environment: - TZ${TIMEZONE} networks: - teable-standalone depends_on: teable-db: condition: service_healthy teable-cache: condition: service_healthy关键点镜像ghcr.io/teableio/teable:latest为官方构建的完整产品镜像由仓库根目录 dockers/teable/Dockerfile 的多阶段构建产物封装EXPOSE端口为 3000端口3000:3000暴露 Web 界面与 API访问地址即http://127.0.0.1:3000数据卷teable-data:/app/.assets:rw保存应用本地资产附件等。compose 文件给出了可选的 bind mount 写法如./docker/teable/data:/app/.assets:rw官方注释建议用它替代命名卷从而降低误删卷导致数据丢失的风险健康依赖depends_on配合condition: service_healthy保证只有在 PostgreSQL 与 Redis 都通过健康检查后才启动应用避免启动竞态环境变量通过env_file: .env整体注入并将TZ透传给容器。teable-db 数据库服务teable-db: image: postgres:15.4 restart: always ports: - 42345:5432 volumes: - teable-db:/var/lib/postgresql/data:rw # 也可以使用 bind mount # - ./docker/db/data:/var/lib/postgresql/data:rw environment: - TZ${TIMEZONE} - POSTGRES_DB${POSTGRES_DB} - POSTGRES_USER${POSTGRES_USER} - POSTGRES_PASSWORD${POSTGRES_PASSWORD} networks: - teable-standalone healthcheck: test: [CMD-SHELL, sh -c pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}] interval: 10s timeout: 3s retries: 3镜像版本postgres:15.4即 Teable 元数据库meta与业务数据均存储于 PostgreSQL 15对外端口42345:5432仅用于从宿主机直接连接数据库调试、SQL 查询等场景容器网络内部仍通过teable-db:5432访问与.env中POSTGRES_HOSTteable-db、POSTGRES_PORT5432对应健康检查使用pg_isready每 10 秒探测一次超时 3 秒失败重试 3 次后才标记为 healthy持久化数据落在teable-db命名卷的/var/lib/postgresql/data同样提供了 bind mount 替代写法。teable-cache 缓存服务teable-cache: image: redis:7.2.4 restart: always expose: - 6379 volumes: - teable-cache:/data:rw networks: - teable-standalone command: redis-server --appendonly yes --requirepass ${REDIS_PASSWORD} healthcheck: test: [CMD, redis-cli, --raw, incr, ping] interval: 10s timeout: 3s retries: 3镜像版本redis:7.2.4仅通过expose在容器网络内暴露6379不对外发布端口避免未授权访问持久化与鉴权启动参数--appendonly yes开启 AOF 持久化--requirepass ${REDIS_PASSWORD}强制设置密码即.env中的REDIS_PASSWORD健康检查用redis-cli incr ping验证读写可用性。网络与卷networks: teable-standalone: name: teable-standalone-network driver: bridge volumes: teable-data: {} teable-db: {} teable-cache: {}三个服务共享 bridge 网络teable-standalone-network通过服务名互访三个命名卷分别承载应用资产、数据库文件与 Redis 数据。仓库根目录的 dockers/networks.yml、dockers/database-postgres.yml、dockers/cache-redis.yml 等文件展示了这些基础设施片段在更大部署中的复用方式。.env 配置变量详解.env 示例 是 Standalone 部署唯一的配置入口以下逐组说明。时区TIMEZONEUTC注入teable与teable-db两个容器的TZ环境变量。注意部署后如需修改时区需同时重新创建容器与数据库容器docker compose up -d --force-recreate因为 PostgreSQL 的时区在进程启动时读取。PostgreSQL 连接POSTGRES_HOSTteable-db POSTGRES_PORT5432 POSTGRES_DBexample POSTGRES_USERexample POSTGRES_PASSWORDexample2passwordPOSTGRES_HOST/PORT指向 compose 网络内的数据库服务名不应改为127.0.0.1除非应用以 host 模式运行POSTGRES_PASSWORD为示例值正式部署前务必修改。Redis 连接REDIS_HOSTteable-cache REDIS_PORT6379 REDIS_DB0 REDIS_PASSWORDreplace_this_passwordREDIS_PASSWORD同时用于 Redis 容器启动参数--requirepass与后端连接串两处必须保持一致同样需要在部署前替换。应用地址与数据库 URLPUBLIC_ORIGINhttp://127.0.0.1:3000 PRISMA_DATABASE_URLpostgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DB} PUBLIC_DATABASE_PROXY127.0.0.1:42345PUBLIC_ORIGIN后端校验的外部访问地址。本地部署保持http://127.0.0.1:3000若通过域名或反向代理暴露需改为对应公网地址后端环境校验中该变量为必填项见 env.validation.schema.tsPRISMA_DATABASE_URL后端通过 Prisma 连接 PostgreSQL 的 DSN直接引用上面的 PostgreSQL 变量组合而成无需单独修改PUBLIC_DATABASE_PROXY127.0.0.1:42345对应 compose 中数据库对宿主机的映射端口供宿主机侧 SQL 客户端直连。事务超时可选# 事务最长执行时间毫秒默认 5000 #PRISMA_TRANSACTION_TIMEOUT60000 # 从连接池获取事务的最大等待时间毫秒默认 2000 #PRISMA_TRANSACTION_MAX_WAIT5000适用于大批量更新、大量关联链接写入等长事务场景按需取消注释并调整。邮件服务可选#BACKEND_MAIL_HOSTsmtp.teable.ai #BACKEND_MAIL_PORT465 #BACKEND_MAIL_SECUREtrue #BACKEND_MAIL_SENDERnoreply.teable.ai #BACKEND_MAIL_SENDER_NAMETeable #BACKEND_MAIL_AUTH_USERusername #BACKEND_MAIL_AUTH_PASSpasswordStandalone 默认不配置邮件。只有需要发送邮件如邀请、通知时才启用且必须替换为实际 SMTP 配置否则无法正确发信。缓存后端BACKEND_CACHE_PROVIDERredis BACKEND_CACHE_REDIS_URIredis://default:${REDIS_PASSWORD}${REDIS_HOST}:${REDIS_PORT}/${REDIS_DB}Standalone 编排默认使用 Redis 作为缓存。后端环境校验对BACKEND_CACHE_REDIS_URI要求必须匹配redis://或rediss://协议前缀见 env.validation.schema.ts。示例 URI 使用default作为 Redis 用户名密码引用上面的REDIS_PASSWORD端口与库号与 Redis 组保持一致。此外.env 示例 中还注释了一个可选的安全开关BACKEND_SESSION_ORIGIN_CHECK_ENABLED用于对不安全的 API 请求启用浏览器 Session Origin 校验仅在反向代理或 CDN 能保留Origin与Sec-Fetch-*请求头时才建议开启。启动、验证与常用运维命令前置步骤完成后在dockers/examples/standalone/目录下执行docker compose up -d首次启动会依次拉起teable-db→teable-cache→teable由健康依赖保证顺序随后浏览器访问http://127.0.0.1:3000常用运维命令# 查看全部服务状态与健康检查结果 docker compose ps # 跟踪应用日志 docker compose logs -f teable # 修改 .env 后重建容器保留数据卷 docker compose up -d --force-recreate # 停止服务不删除数据卷 docker compose down # 彻底清理会删除命名卷中的数据谨慎执行 docker compose down -v启动流程与数据库迁移的源码视角Standalone 容器的启动过程并非简单的进程拉起而是先迁移、后启动的两段式流程可以从源码确认镜像入口镜像ENTRYPOINT指向scripts/start.sh见 Dockerfile自动迁移start.sh 默认在启动前执行node scripts/db-migrate.mjs数据库迁移失败则整个容器启动失败并退出exit 1。也可通过参数覆盖skip-migrate跳过迁移、migrate-only仅迁移后退出迁移实现db-migrate.mjs 解析PRISMA_DATABASE_URL兼容PRISMA_META_DATABASE_URL先对 meta 库执行prisma migrate deployschema 为packages/db-main-prisma/prisma/postgres/schema.prisma再对 data 库执行同样的部署迁移schema 为packages/db-data-prisma/prisma/schema.prisma并带 5 次、每次间隔 3 秒的重试逻辑同时通过wait-for等待数据库端口就绪服务启动迁移完成后同时启动 NestJS 后端apps/nestjs-backend/dist/index.js与插件服务器plugins/server.jswait -n保证任一进程退出即终止容器见 start.sh。这一设计意味着首次启动时数据库表结构由容器自动完成初始化无需手工执行 SQL升级镜像后重启容器也会自动应用新的迁移。数据持久化、遥测与安全注意事项数据持久化位置应用资产、PostgreSQL 数据、Redis 数据分别落在三个命名卷teable-data、teable-db、teable-cache。如需长期保留数据建议按 compose 中注释改为 bind mount 目录并做好定期备份尤其是teable-db卷遥测状态按 dockers/examples/standalone/README.md 的说明Standalone 镜像中Telemetry遥测是默认关闭的无需额外配置即可保证自托管环境的隐私性默认密码必须修改.env中的POSTGRES_PASSWORD与REDIS_PASSWORD均为占位示例值正式部署务必替换为强密码且修改后需同步更新PRISMA_DATABASE_URL与BACKEND_CACHE_REDIS_URI它们引用这些变量端口暴露面PostgreSQL 的42345端口对外映射建议仅对可信网络开放或改用防火墙限制来源 IPRedis 不对外发布端口反向代理若通过域名访问建议在反向代理层启用 HTTPS并将PUBLIC_ORIGIN改为域名地址会话校验可选仅当代理/CDN 能透传Origin与Sec-Fetch-*头时才启用BACKEND_SESSION_ORIGIN_CHECK_ENABLED以增强 API 安全性。后续演进升级到完整版时数据不丢失如果未来需要 AI Chat、App Builder 与沙箱能力无需推倒重来。官方迁移路径migration/2026-07-basic-to-full-featured明确说明完整版部署会在现有 Standalone 应用旁边附加运行时平面已有数据原地保留无需迁移或重建数据库。因此 Standalone 既可长期作为轻量级正式部署也可作为完整版的稳健起点——这正是其单机、一个 PostgreSQL、三服务精简架构的价值所在。通过本文你已经掌握了 Standalone 版的能力边界、docker-compose.yaml三服务的职责划分、.env全部变量的含义与取值规则、容器启动时的自动迁移机制以及数据持久化与安全加固要点。接下来即可直接修改.env中的密码并执行docker compose up -d完成你的第一次 Teable 自托管。【免费下载链接】teable✨ AI Spreadsheet for Business项目地址: https://gitcode.com/GitHub_Trending/te/teable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考