Distillation

Date: July 22, 2026

• 🟡 (16:50) User asked whether Alchemy (alchemy.run/cloudflare) makes sense for craft's Cloudflare target.
• 🟡 (16:50) Assistant researched alchemy.run/cloudflare page: an Infrastructure-as-Code (IaC) framework, TypeScript alternative to Terraform/Pulumi/SST for Cloudflare, declares Workers/D1/KV/R2/DNS/bindings (~200 resources) in a TS program, alchemy deploy diffs/reconciles state; bun-first (bun alchemy deploy); Workers-first with Pages de-emphasized (recommends static assets from a Worker over Pages).
• 🔴 [decision] (16:50) Assistant recommended AGAINST adopting Alchemy for craft's Cloudflare target — verdict: wrong tool, reverses deliberate prior decisions. Reasons: (1) state ownership mismatch — Alchemy is stateful IaC expecting to own the whole stack, craft targets are stateless publish steps that ship a prebuilt *-cloudflare.zip artifact; (2) reverses craft's prior "no new runtime dependency" decision to use wrangler-via-shell — Alchemy is a much heavier dependency and is bun-first while craft runs on Node; (3) Alchemy is Workers-first/de-emphasizes Pages, aligning with craft's existing deployType default → worker change but adding nothing wrangler doesn't already do; (4) wrong layer — Alchemy belongs upstream of craft (in a user's own build step), not inside craft's publish target.
• 🟡 (16:50) Assistant noted Alchemy could be relevant only if getsentry/toolkit's docs site itself wanted IaC to manage its own CF resources — a project-level choice orthogonal to craft, which would still just deploy the built output regardless.
• 🟡 (16:50) Assistant recommendation: keep current wrangler-shell approach for the Cloudflare target; offered to document Alchemy as an explicitly-considered-and-rejected alternative in the design doc/cloudflare target docs, and stated intent to otherwise continue holding PR C pending user's #848 review.