Cloudflare stack proposal
Proposed replacement map for moving the clean repo away from Supabase and toward Cloudflare-first dev and production infrastructure.
Cloudflare stack proposal
Status: proposal, not confirmed canon.
Repo Inventory Response
Current writing-system stack is not Cloudflare-native today.
- Frontend: React 19 + Vite + TanStack Query + Zustand + TipTap/Monaco/CodeMirror, with direct Supabase client dependency in
web/package.json. - Backend: FastAPI + Uvicorn + Strawberry GraphQL + SQLAlchemy + SQLAdmin + Supabase Python SDK + boto3 + NATS client in
services/platform-api/requirements.txt. - Runtime: local Docker platform-api on
127.0.0.1:7640; current production target is Cloud Run, not Cloudflare Workers, perpm-manifest.mdx. - Current production split: hosted Supabase Postgres/Auth, Cloudflare R2, Vercel web, Cloud Run API, per
local-production-parity-map.mdx. - Supabase is still embedded in auth, JWT validation, migrations, env vars, SDK usage, and backend admin paths. It is not just "a database host."
Architecture Decision Response
Best overall base: new Cloudflare-first repo, not a fork, not a migration inside this repo.
| Current Item | Best Target | Decision |
|---|---|---|
| React/Vite web | Cloudflare Workers Static Assets + Cloudflare Vite plugin | Move. Strong fit. Replace Vercel. |
| FastAPI platform-api | Cloudflare Containers first, then rewrite stable APIs to TypeScript Workers | Do not try to lift current FastAPI directly into Python Workers. Current API has SQLAlchemy, SQLAdmin, psycopg2, process pools, background workers. |
| Python-heavy conversion/workers | Cloudflare Containers | Keep Python where Python is needed. Do not force this into Workers isolates. |
| Product DB if Postgres stays | Managed Postgres outside Cloudflare + Hyperdrive | Cloudflare does not host Postgres. Hyperdrive connects/pools to Postgres. |
| Product DB if Cloudflare-only | D1 | Only if you accept a rewrite from Postgres semantics to SQLite semantics. |
| Supabase Auth | WorkOS AuthKit for product/B2B auth; Cloudflare Access only for internal/admin | Access is not a full Supabase Auth replacement for customer auth. |
| Supabase Storage / MinIO | Cloudflare R2 | Move. This is the cleanest Cloudflare replacement. |
| NATS / coordination | Durable Objects + Queues + Workflows | Remove NATS unless you need NATS-specific pub/sub semantics. |
| Realtime/collab/session state | Durable Objects + WebSockets | Best Cloudflare-native fit. |
| Background jobs | Queues for job dispatch; Workflows for durable multi-step jobs; Containers for heavy execution | Do not run job loops inside the request API. |
| Secrets | Wrangler envs + Workers Secrets + Secrets Store | Move out of repo SOPS for Cloudflare runtime. Keep local secret process only for migration. |
| Observability | Workers Logs/Traces + Logpush/export | Replace ad hoc container logs/OpenTelemetry collector unless you keep non-CF backend. |
| Agent runtime | Cloudflare Agents SDK + Durable Objects + AI Gateway + Vectorize | Use for Cloudflare-native agents. Keep external agent repos as reference, not runtime base. |
| Vector search | Vectorize, or pgvector in external Postgres | Use Vectorize if moving RAG/search into Cloudflare. Use pgvector only if Postgres remains central. |
Provider / OSS Response
Best practical target:
Cloudflare Workers Static Assets
+ TypeScript Worker API for normal product endpoints
+ Cloudflare Containers for Python/conversion/legacy-heavy services
+ R2 for files
+ Durable Objects for live/session/collab/agent state
+ Queues + Workflows for async jobs
+ WorkOS AuthKit for product auth
+ Cloudflare Access for internal/admin gates
+ managed Postgres + Hyperdrive unless you rewrite data to D1The hard truth: "all Cloudflare" means D1, not Postgres. If Postgres remains a requirement, the best Cloudflare-compatible answer is Hyperdrive plus an external Postgres host. If eliminating Supabase is the goal, that external Postgres can be Neon/RDS/Cloud SQL/Crunchy/etc., but it is still outside Cloudflare.
Current docs checked: Cloudflare Static Assets, Hyperdrive, D1, R2, Access, Durable Objects, Queues, Workflows, Containers, Python Workers/FastAPI, Secrets Store, Workers Observability, Agents SDK, Workers AI, AI Gateway, Vectorize, WorkOS AuthKit.
Key docs: Static Assets, Hyperdrive, D1, R2 S3, Access, Durable Objects, Containers, Python Workers packages, WorkOS AuthKit.