这套方案解决的是：没有自建服务器时，如何把 DEEIX Chat 的应用、PostgreSQL 和 Redis 分别托管到 Render、Aiven 与 Upstash，并完成一套可登录验证的公开部署。最终形态是 Render 运行应用，Aiven 保存持久数据，Upstash 提供 Redis；已有 PostgreSQL 或 Redis 的读者可以直接复用，跳过相应准备步骤。

一、先理解三个服务的分工

DEEIX Chat 是一个可自行部署的多模型 AI 工作台，包含聊天、模型路由、文件与 RAG、MCP 工具、用量计费、身份和审计等模块。本方案没有把全部组件塞进同一容器，而是拆成三部分：

  • Render：拉取项目仓库并运行 Web/API 应用；
  • Aiven：提供 PostgreSQL，保存账号、配置和业务数据；
  • Upstash：提供带 TLS 的 Redis，用于缓存及相关运行状态。

这种拆分适合快速试用和低运维场景，但可用性、免费额度、休眠策略和绑卡要求都由各平台决定，正式使用前应单独确认。原帖没有给出容量、并发和备份指标，因此不能据此判断是否适合生产负载。

二、准备 PostgreSQL 与 Redis

先在 Aiven 创建 PostgreSQL 服务，选择计划和区域，等待实例就绪后保存连接地址。再在 Upstash 创建 Redis 数据库，选择 Free 计划后记录主机、端口、用户名和密码。原帖使用的 Redis 用户名为 default、端口为 6379，并要求启用 TLS。

连接信息都属于敏感配置：不要写进公开仓库、帖子或前端环境变量，也不要把截图中的凭据直接分享。建议生成独立的高强度 JWT 密钥和数据加密密钥，避免复用数据库密码。

三、在 Render 建立应用

在 Render 新建项目并关联 DEEIX Chat 仓库。第一次部署可能因为尚未提供配置而失败；此时先保留 Render 分配的公开地址，用于后续填写服务 URL 和 CORS 来源。失败应以构建日志为准，原帖预期的首次失败不是所有环境都必然发生。

从仓库复制 config.example.yaml 为自己的配置，至少核对以下项目：

  • app.env 使用 prod；
  • server.cors_allow_origin 指向前端公开地址；
  • server.public_api_base_url 指向公开 API 地址；
  • server.public_web_base_url 指向公开 Web 地址；
  • security.jwt_secret 与 security.data_encryption_key 使用独立随机值；
  • database.postgres.dsn 填写 Aiven DSN；
  • database.redis.addr、username、password 使用 Upstash 信息；
  • database.redis.tls_enabled 设为 true。

这里有一个值得注意的细节：原帖配置片段重复写了两次 server.public_api_base_url。对照项目仓库，第二项应检查是否实际需要 server.public_web_base_url；前后端同域时两者可能相同，分离部署时则必须分别填写，否则容易出现跨域或回调地址错误。

四、重新部署并验证

把配置通过 Render 支持的私密环境变量或配置文件机制注入后重新部署，不要提交到 Git。部署成功后依次验证：公开地址能打开；后端健康接口无报错；日志没有 PostgreSQL/Redis 连接失败；可以使用启动日志中给出的初始账号登录；登录后立即更改初始密码。

如果失败，按“配置是否加载 → DSN 是否正确 → Redis TLS 是否开启 → CORS 与公开 URL 是否一致”的顺序排查。项目官方还提供 SQLite 轻量方案，若只是本地评估，可先用它验证应用本身，再切换外部 PostgreSQL 和 Redis。回退时保留旧配置和数据库，不要在未备份的情况下重建实例。

可复用的工程经验

这类多服务部署最容易出错的不是代码，而是 URL、密钥、TLS 和持久化边界。先画清服务依赖，再逐项验证连接，能比反复重部署更快定位问题。把首次登录、凭据轮换、数据库备份和平台休眠策略纳入验收，才能从“页面能打开”走到“可以稳定使用”。

原作者：beyond1（高川）
原帖：https://linux.do/t/topic/2729989