ADR-001: Cloudflare Stack with Python Workers
Status
Accepted (2026-04-02)
Context
CascadeGuard needs a hosting platform for its SaaS API and dashboard. The platform does not run Kubernetes — scanning and image building happen in users’ CI pipelines. Our platform receives results, tracks state, and serves a dashboard.
The open-source CascadeGuard codebase is entirely Python. Cloudflare Workers now supports Python as a first-class runtime.
Decision
Full Cloudflare stack with Python on Workers:
| Component | Choice |
|---|---|
| API runtime | Cloudflare Workers (Python) |
| Dashboard | Cloudflare Pages (React + Vite) |
| Database | Turso (edge SQLite) |
| Object storage | Cloudflare R2 |
| Job queue | Cloudflare Queues |
| Cache | Cloudflare KV |
| DNS/CDN | Cloudflare |
Why Python on Workers
- Single language across the entire stack (open-source CLI, CI tooling, SaaS API)
- Code reuse from the open-source repo (scan result parsing, SBOM processing)
- Cloudflare Workers supports Python as first-class — no TypeScript rewrite needed
Why Cloudflare
- Near-zero MVP infrastructure cost (free tiers cover MVP traffic)
- Global edge deployment, scales to zero
- No servers or clusters to manage
Consequences
- Positive: ~$1/mo MVP infrastructure cost
- Positive: No ops burden — no K8s, no VMs
- Positive: Single language (Python) end to end
- Negative: Python Workers runtime is newer — fewer community examples
- Negative: Turso/D1 are SQLite-based — no PostgreSQL features
- Migration path: Workers-compatible runtimes exist (workerd); DB can move to Neon/PlanetScale if needed