架构

它会在你的网络上部署什么、又会与谁通信。整个平台就是一个无状态容器加一个 Supabase 项目；其余一切都是向你本已信任的地方发起的出站调用。

部署

单个无状态 Node 进程，以 Docker 镜像形式发布。DEPLOY_TARGET=node 是主要目标；docker compose up 是文档给出的路径。

一个由你创建、由你拥有的 Supabase 项目——Postgres、认证和对象存储。迁移用 Supabase CLI 应用。运行本平台不需要其他任何东西。

容器不保存任何会话状态，因此可以放在普通负载均衡之后，不需要会话粘滞。后台任务通过数据库上的跨实例租约协调，也可以用 DISABLE_INPROCESS_SCHEDULER 按实例关闭，让某一个节点独占它。

/api/health for liveness and readiness probes.

所有出站目标，仅此而已。写防火墙规则时用得上。

向你所配置的各家提供商发起出站 HTTPS，使用你的密钥。提示词与补全内容不会经过我们的任何厂商。

向你接入的数据库、数仓和 SaaS API 发起出站请求。数据库驱动使用各自的原生端口；其余一律走 HTTPS。文档要求连接器使用只读凭据，且每条查询路径都会拒绝除 SELECT 一类之外的语句。

数仓位于你的 VPC 内是一种常规部署。出站请求会针对云元数据地址和链路本地地址做筛查，但私有地址段是刻意放通的。

没有遥测、没有许可证校验、没有用量上报。什么都没内置：Cookie 提示条里那份可选的分析统计，只有在你配置了自己的 VITE_GA_ID 时才存在，未配置时连提示条都不会出现。只访问你自己模型端点的离网部署，是受支持的配置。

什么受限、受什么限。完整数值以及能改变它们的环境变量都在 docs/SCALE_AND_LIMITS.md 里。

语义层查询和已关联的数仓表都会编译成在数据所在处执行的 SQL，因此十亿行的 GROUP BY 是你数仓的工作量，网络上只走分组后的结果。结果集有上限（默认 1000 行，硬上限 5000 行，超时 60 秒）——它限制的是回传的内容，从不限制表本身。

当一个流程的所有数据源都在同一个连接上、且每一步都能用该方言表达时，整条流水线会变成一条在数仓内部执行的 SQL——而这次下推在被信任之前会先在真实数仓上验证过，所以一旦被拒，损失的是速度，绝不是正确性。混合来源或无法下推的流程改在本地执行，界面会说明是哪一种。

上传和同步来的数据集是 DuckDB 表，默认上限 50 万行、100 MB。它们的用途是 CSV、样本数据和 SaaS 同步。超过几百万行，请关联数仓表，而不是把它导入进来。

由数仓支撑的组件最多保存 500 行，好让共享链接瞬时渲染。因此，如果刷新时触到了这个上限，那些在浏览器里对原始行求和的图表会显示一个部分合计——它会被标记为已截断，而不是当作确定值展示。启用聚合下推（在 SQL 里 GROUP BY）或直接查询模式，才能得到完整数字。

什么必须存活，什么丢了也没关系。

智能体、集群、数据集、仪表板、追踪和审计事件。备份好 Supabase 项目，就等于备份了整个平台。

上传的文档、生成的文件以及列式数据集镜像都放在 Supabase 存储桶里。

Parquet 镜像缓存在本地磁盘上，是可丢弃的——丢了只损失速度，绝不丢数据。在容器宿主机上给它挂一个真实卷，让它能活过重启。

完整的部署选项与环境变量在 docs/DEPLOYMENT.md；每一项行数、超时和并发上限在 docs/SCALE_AND_LIMITS.md。另请参阅安全和许可协议.