ADR-0010: Deploy: Fly.io + Vercel¶
Umbra 의 Go 프로세스(bot, api, worker)는 Fly.io nrt 리전에 배포하고, React SPA 는 Vercel 에 배포한다.
Status¶
Accepted
- Decided at — 2026-04-13
- Decided by — Pablo
Context¶
Umbra 는 네 개의 프로세스를 배포해야 한다.
- umbra-bot — Discord Gateway WebSocket 상시 연결 (long-running)
- umbra-api — HTTP 서버 (stateless)
- umbra-worker — 백그라운드 작업 (asynq + Temporal + Outbox)
- umbra-web — React SPA (정적 파일)
배포 요구사항:
- 한국 사용자 latency 최소화 (아시아 리전 필요)
- Long-running process 지원 (Bot 게이트웨이)
- PR preview (웹)
- 관리 부담 최소
후보: Fly.io, Cloud Run, AWS (ECS/EKS), Railway, Render, Vercel (전체).
Decision¶
프로세스 성격에 따라 분리한다.
- Go 프로세스 3개 → Fly.io, nrt (Tokyo) 리전
- React SPA → Vercel
선택 근거:
- Fly.io 의 long-running 지원 — Discord Gateway 같은 WebSocket 상시 연결 프로세스에 적합. Cloud Run 은 stateless 전용이라 부적합
- Fly.io 의 간단한 배포 UX —
fly deploy한 명령으로 프로세스별 독립 배포 - Fly.io 의 아시아 리전 — nrt (Tokyo). 서울 리전은 없지만 한국-Tokyo latency 는 30ms 이내
- Vercel 의 SPA 최적화 — CDN edge 배포, PR preview 자동 생성, Bun 지원
- 비용 효율 — MVP 규모에서 Fly.io shared-cpu + Vercel Hobby 로 매우 낮은 비용
Consequences¶
Positive¶
- Bot / API / Worker 를 독립 머신으로 배포 → 장애 격리
- Vercel 의 preview URL 로 PR 리뷰 개선
- 배포 UX 가 단순 (fly deploy, vercel deploy)
- MVP 월 ~$45–$65 수준 비용
Negative¶
- 두 개 플랫폼 사용으로 관측 도구 파편화 (Fly.io metrics + Vercel analytics)
- Fly.io 는 서울 리전 없음 (Tokyo 가 가장 가까움)
- Vercel 종속성 (커스텀 CDN 필요 시 이전 부담)
Neutral¶
- Temporal Server 도 같은 Fly.io nrt 에서 self-hosted (MVP)
- Neon(서울), Upstash(Tokyo)와의 지리적 통합 고려됨
Alternatives considered¶
Alternative 1: Google Cloud Run 전체¶
Pros
- 관리형 서버리스
- 자동 스케일
Cons
- Bot 프로세스 부적합 — stateless 전용, WebSocket 장시간 유지 어려움
- Cold start
- VPC 등 인프라 설정 부담
Why rejected — Bot 에 치명적. 부분 도입도 혼용 복잡도 증가.
Alternative 2: AWS ECS + CloudFront¶
Pros
- 엔터프라이즈급 유연성
Cons
- 운영 부담이 MVP 에 과도 (VPC, IAM, ALB, task definition)
- 배포 파이프라인 복잡
Why rejected — MVP 관리 부담 기준 미달.
Alternative 3: Railway / Render 전체¶
Pros
- 간단한 배포 UX
Cons
- 아시아 리전 제한적 (Railway 는 리전 선택 불가 지역 존재, Render 는 Singapore)
- Fly.io 대비 머신/리소스 제어 약함
Why rejected — 한국 latency 와 제어력 관점에서 Fly.io 우위.
Alternative 4: Vercel 전체 (Go API + SPA)¶
Pros
- 단일 플랫폼
Cons
- Vercel 의 Go 지원은 serverless functions 중심 → long-running Bot 부적합
- 파일 단위 함수 배포는 Echo 같은 통합 프레임워크와 결이 다름
Why rejected — Bot 호환성 부재.
Compliance¶
- 각 Go 프로세스의
fly.toml을apps/{bot,api,worker}/fly.toml에 위치 - Vercel 프로젝트는
apps/web/을 root directory 로 설정 - 환경 변수는 Fly secrets (백엔드) / Vercel env (프론트)
- DNS 는 Cloudflare 가 관리, Fly.io / Vercel 로 CNAME
Revisit triggers¶
- Fly.io nrt 리전 장애가 빈번하면 멀티 리전 (sin, hkg, syd) 추가 검토
- Vercel 비용이 Pro plan 을 넘어 성장하면 Cloudflare Pages 또는 자체 CDN 검토
- Fly.io 가 서울 리전을 제공하면 마이그레이션 검토