ADR-004: Deployment & Infrastructure

Status: Accepted
Date: 2026-07-03
Deciders: CTO (b999c0b2), DEV (9f66dba7)

---

Context

Cartly muss als SaaS-Produkt zuverlässig und skalierbar deployed werden können. Die Entscheidung muss以下几点 berücksichtigen:

• MVP-Zyklus: Schnelle Iterationen in Sprint 1
• Kosten: Startup-konform, kein überdimensioniertes Infrastructure
• Developer Experience: CI/CD das Entwickler nicht blockiert
• Zero-Downtime: Produktiv-Systeme dürfen nicht ausfallen

Decision

Deployment Platform: Railway (MVP) / Vercel (Frontend)

Component	Platform	Reason
Backend API (Node/Fastify)	Railway	Docker-native, einfaches DB+Redis Setup, Blue-Green Deploys
Frontend (Next.js)	Vercel	Edge Network, Preview PRs, SSR/SSG optimiert
Database	Neon (PostgreSQL)	Serverless, Branching für Previews, günstiger Tier
Cache/Queue	Upstash (Redis)	Serverless Redis, kein ops overhead
Container Registry	GHCR (GitHub Container Registry)	Integriert in GitHub Actions

Warum NICHT andere Optionen:

• AWS/GCP/Azure: Zu komplex für MVP, kein Startup-Budget
• Heroku: Zu teuer im Verhältnis zu Railway bei gleicher Funktionalität
• DigitalOcean App Platform: Weniger Developer-experience als Railway/Vercel

Consequences

Positiv:

• Railway + Vercel haben exzellente DX, DEV kann sich auf Code konzentrieren
• Neon/Upstash sind serverless, keine Infrastruktur-Pflege
• GHCR ist in GitHub integriert, keine额外 Auth

Negativ:

• Vendor Lock-in: Wechsel zu AWS/GCP später erfordert Re-Architecture
• Kosten können bei Skalierung steigen (RailwayPricing)
• Neon Serverless hat Connection-Limits bei sehr hohem Traffic

Alternatives Considered

Alternative	Why Not
Docker Compose + VPS (Hetzner)	Kein Blue-Green, Manual Ops, kein Preview-Environment
Kubernetes (EKS/GKE)	Zu komplex für MVP, hoher Ops-Overhead
AWS ECS/Fargate	Teuer, AWS-spezifisches Know-how nötig
Coolify (Self-hosted)	Gute Option für später, aktuell noch nicht nötig

Related

• DEPLOY-001 Runbook
• DB-001 Database Backup

---

Accepted: 2026-07-03