CRM 部署需求解析

技術討論
1

本篇文章說明如何將 trycompai/crm 部署於 Vercel 與 Supabase，並說明不需要額外 VPS、FastAPI 或其他服務。

CRM 部署需求解析

結論

  • 不需要額外準備長期運行的 VPS 或實體 Server。
  • 專案原生設計為 Vercel Serverless 架構，可完整部署於 Vercel、Neon 或 Supabase PostgreSQL、Upstash Redis、Vercel Blob、Vercel Cron 等服務。
  • 需要三個獨立 Vercel Project（前端、API、Agent）以及一個 PostgreSQL 資料庫。

原生架構

元件 專案路徑 建議部署
Web UI apps/app Vercel
Backend API apps/api Vercel
Research Agent apps/agent Vercel
Database packages/db Neon 或 Supabase PostgreSQL
Cache Redis Upstash（可選）
File storage Vercel Blob Vercel
定時同步 /internal/sync/google Vercel Cron 或外部 Cron

專案為 Bun + Turborepo monorepo，前端使用 Next.js，API 使用 NestJS，資料層 Prisma + PostgreSQL，Agent 使用 Vercel 的 eve 與 Vercel Sandbox。

使用 Supabase PostgreSQL

Supabase 可以取代官方範例中的 Neon，因為 CRM 使用標準 PostgreSQL 與 Prisma。

# 將 Supabase 的 PostgreSQL 連線字串放入環境變數
export DATABASE_URL="postgresql://..."

# 執行資料庫遷移
bun run db:deploy

注意：Supabase 的連線模式

  • Migration 建議使用 direct connection。
  • Serverless production runtime 建議使用 Supavisor pooler。
  • Prisma 的 migration URL 與 runtime URL 最好分開。
  • 必須確認 transaction pooling 與 prepared statements 的相容設定。

若需要分離連線字串，可設定：

export DATABASE_URL="Supabase pooled connection"
export DIRECT_URL="Supabase direct connection"

並在 prisma/schema.prisma 中調整：

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DIRECT_URL")
}

Auth 與 Storage

  • Auth：專案使用 Better Auth、Google OAuth、ALLOWED_SIGN_IN 與 BETTER_AUTH_SECRET，並不使用 Supabase Auth。若改用 Supabase Auth，需重寫多處登入、Session cookie、API 認證中介軟體、前端驗證、ALLOWED_SIGN_IN 邏輯與 Agent/API 身份驗證。
  • Storage：目前使用 Vercel Blob 儲存與鏡像個人頭像。改用 Supabase Storage 需要修改檔案上傳與 URL 管理程式碼，非單純改環境變數即可完成。

FastAPI 方案

不適合也沒有必要。FastAPI 是 Python 框架，若改用它，需重寫整個 apps/api：

  • NestJS controller 與 service
  • tRPC router
  • Prisma 整合
  • Better Auth
  • Google Gmail／Calendar 同步
  • 生成 router 類型
  • 前後端型別共享機制

這將破壞專案的 type‑safe 設計，且維護成本極高。

持續性服務需求

服務 目的 可用選項
PostgreSQL 資料永續儲存 Neon、Supabase、Railway、Render、自己架設
Scheduler Gmail／Calendar 同步 Vercel Cron、GitHub Actions Cron、Supabase Cron、Upstash QStash、cron‑job.org
Durable Agent Runtime Agent 執行與任務佇列 Vercel 的 eve durable‑agent 與 Vercel Sandbox

關鍵：專案高度依賴 Vercel 的 Agent、Sandbox、AI Gateway 與 durable runtime 生態。僅將 UI 部署於 Vercel 並把資料庫放 Supabase，無法完整執行 Agent 功能。

推薦部署架構

Cloudflare
└── crm.yourdomain.com

Vercel
├── crm-app
│   └── apps/app
├── crm-api
│   └── apps/api
└── crm-agent
    └── apps/agent

Supabase
└── PostgreSQL

Upstash
└── Redis（可選）

Vercel Blob
└── Profile images

Vercel Cron
└── Gmail / Calendar sync

Google Cloud
├── OAuth
├── Gmail API
└── Calendar API

主要環境變數

DATABASE_URL=
BETTER_AUTH_SECRET=
ALLOWED_SIGN_IN=

GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=

APP_URL=https://crm.example.com
API_URL=https://crm-api.example.com

AUTH_COOKIE_DOMAIN=.example.com

CRON_SECRET=
AGENT_BRIDGE_SECRET=

REDIS_URL=
PERPLEXITY_API_KEY=
RAPIDAPI_KEY=

三個 process 共用同一組 root environment variables；在 hosting platform 上直接設定即可。

實際建議

方案 可行性 複雜度 判斷
Vercel + Neon 最高 中 最接近官方架構
Vercel + Supabase PostgreSQL 高 中 適合已有 Supabase 帳號
全部部署到一臺 VPS 高 中高 Agent Sandbox 需另外處理
Vercel 單一 Project 低 高 不符合三 deployment 設計
Supabase 全包 低 高 Auth、Storage、Agent 都需改造
FastAPI backend 極低 極高 等同重寫 API
Cloudflare Workers 低 極高 Bun、NestJS、Prisma、Sandbox 相容性問題

最合理的答案：不需要購買 Server。採用三個 Vercel Project，加上一個 Supabase PostgreSQL 即可；保留 NestJS、Better Auth、Vercel Blob 與 Agent 架構，避免引入 FastAPI。

需要額外確認 Vercel Sandbox、AI Gateway、Agent 執行時間與方案費用。這些功能可能讓實際成本高於一臺普通 VPS，尤其 Agent 大量執行時。