trycompai CRM 採原生 Vercel Serverless 架構，需三獨立部署加 PostgreSQL。本文解析 Supabase 替代方案、Auth 與 Storage 選擇、FastAPI 不適用原因、Agent 耐久運行需求，並給出最合理部署建議。
核心結論：不需傳統 Server，但需三個 Vercel 專案
trycompai/crm 採 Vercel Serverless 原生架構，無須長期運行的 VPS 或實體伺服器。官方架構明確要求：三個獨立 Vercel 部署 + 一個 PostgreSQL 資料庫。
| 元件 | 專案路徑 | 建議部署目標 |
|---|---|---|
| Web UI (Next.js) | apps/app |
Vercel Project 1 |
| Backend API (NestJS + tRPC) | apps/api |
Vercel Project 2 |
| Research Agent (Vercel eve + Sandbox) | apps/agent |
Vercel Project 3 |
| Database (Prisma + PostgreSQL) | packages/db |
Neon / Supabase / Railway 等 |
| Cache (可選) | Redis | Upstash |
| File Storage | Vercel Blob | Vercel |
| 定時同步 | /internal/sync/google |
Vercel Cron / GitHub Actions / Upstash QStash |
這是一個 Bun + Turborepo Monorepo，前後端共享 TypeScript 型別，從 Prisma Schema 直達 UI 元件，型別安全是核心優勢。
資料庫：Supabase 可替代 Neon，但僅限 PostgreSQL
可行做法
Supabase 提供標準 PostgreSQL，完全相容 Prisma。架構如下：
Vercel
├── crm-app (apps/app)
├── crm-api (apps/api)
└── crm-agent (apps/agent)
Supabase
└── PostgreSQL Database
設定環境變數：
DATABASE_URL="postgresql://..." # Supabase Pooled Connection (Supavisor)
DIRECT_URL="postgresql://..." # Supabase Direct Connection (Migration 用)
Prisma Datasource 需支援 directUrl：
datasource db {
provider = "postgresql"
url = env("DATABASE_URL
directUrl = env("DIRECT_URL
}
注意：專案預設可能未定義
DIRECT_URL，需小幅修改prisma/schema.prisma並確認bun run db:deploy正常。
不可行：Supabase Auth / Storage 直接替換
- Auth：專案使用 Better Auth + Google OAuth +
ALLOWED_SIGN_IN邏輯 + 共用BETTER_AUTH_SECRET。改用 Supabase Auth 等於重寫登入流程、Session Cookie、API Middleware、前端驗證、Agent 驗證，成本極高且無必要。 - Storage：目前用 Vercel Blob 儲存頭像鏡像。改用 Supabase Storage 需修改上傳與 URL 管理代碼，非單純環境變數切換。
建議：Supabase 只當 PostgreSQL，Auth、Blob 維持原架構。
為何 FastAPI 完全不適合
FastAPI 是 Python 框架，非託管服務。採用 FastAPI 意味著重寫整個 apps/api：
- 所有 NestJS Controller / Service
- tRPC Router 與型別共享機制
- Prisma 整合
- Better Auth 整合
- Gmail / Calendar 同步邏輯
- 前後端端到端型別安全
這會摧毀專案核心優勢（Prisma → tRPC → UI 型別貫通），除非準備長期維護 Fork，否則無合理性。
真正需要的「持續性服務」
雖無 VPS，但三項服務必須持續存在：
- PostgreSQL：資料核心，可用 Neon、Supabase、Railway、Render 或自架。
- Scheduler：每日觸發
POST /internal/sync/google同步 Gmail/Calendar，需CRON_SECRET保護。可用 Vercel Cron、GitHub Actions Cron、Supabase Cron、Upstash QStash、cron-job.org。 - Durable Agent Runtime：Agent 基於 Vercel eve 框架，具備：
- 自主排程與 Task Queue Claim
- 瀏覽器關閉後持續執行
- 部署後恢復 Session
- 使用 Vercel Sandbox 處理資料
關鍵限制：Agent 功能高度依賴 Vercel 的 AI Gateway、Sandbox、Durable Runtime 生態。僅將 Next.js UI 部署於 Vercel、資料庫放 Supabase，無法完整運行 Agent。
建議部署架構圖
Cloudflare (DNS)
└── 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 Consent
├── 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=
方案可行性比較
| 方案 | 可行性 | 複雜度 | 判斷 |
|---|---|---|---|
| Vercel + Neon | 最高 | 中 | 最貼近官方架構 |
| Vercel + Supabase PostgreSQL | 高 | 中 | 適合已有 Supabase 帳號，推薦 |
| 全部部署到單一 VPS | 高 | 中高 | Agent Sandbox 需額外處理 |
| Vercel 單一 Project | 低 | 高 | 違反三部署設計 |
| Supabase 全包 (Auth/Storage/Agent) | 低 | 極高 | 需大幅改造 |
| FastAPI 重寫 Backend | 極低 | 極高 | 等同重寫 API |
| Cloudflare Workers | 低 | 極高 | Bun/NestJS/Prisma/Sandbox 相容性未知 |
實務建議
- 採用三個 Vercel 專案 + Supabase PostgreSQL，保留 NestJS、Better Auth、Vercel Blob、Agent 架構。
- 確認 Vercel 方案費用：Sandbox、AI Gateway、Agent 執行時間可能使成本超過一台普通 VPS，尤其 Agent 高頻執行時。
- 設定
DIRECT_URL並測試 Migration，確保 Prisma 在 Supabase Pooler 下正常。 - 配置 Scheduler (Vercel Cron 或 GitHub Actions) 觸發同步端點。
- 驗證 Agent 行為：部署後觀察 Sandbox 啟動、Task Queue 消費、Session 恢復是否正常。
結語
trycompai CRM 的設計初衷即為 Vercel 原生 Serverless，其優勢在於前後端型別共享與 Agent 耐久運行能力。若團隊已熟悉 Vercel 生態並接受其計費模型，三專案 + Supabase PostgreSQL 是最平衡的選擇；若需極致成本控制或避免 Vendor Lock-in，評估自架 VPS 時須投入相當工程力處理 Sandbox 與 Durable Runtime。