Minimal Cloudflare product demos
One small Hono-based Worker per product. Chapters markedlive run in a sandboxed Dynamic Worker. ๐ Share
| hello-hono live | Workers | Smallest Worker + request.cf metadata |
| kv live | Workers KV | get / put / delete / list + TTL |
| d1 live | D1 | Migrations + SQL CRUD |
| durable-objects live | Durable Objects | Per-name object, SQLite storage, RPC |
| r2 live | R2 | Streaming upload / download |
| queues | Queues | Producer + consumer in one Worker |
| workflows | Workflows | Durable steps, sleep, auto-retry |
| cron | Cron Triggers | scheduled() handler |
| static-assets | Static Assets | Static files + Worker API routes |
| service-bindings live | Service Bindings | Worker-to-Worker RPC, zero overhead |
| rate-limit live | Rate Limiting | Per-key limits on the edge |
| workers-ai live | Workers AI | LLM inference with one binding call |
| vectorize live | Vectorize | Semantic search with embeddings |
| browser-run live | Browser Run | Headless Chromium screenshot |
| images live | Images | Inspect / resize / convert images |
| Email Service | Transactional send via send_email | |
| flagship | Flagship | Feature flag evaluation with context |
How it works
- Each demo is a tiny Hono Worker showing the ordinary, minimal usage of one product โ source in the repo.
- Live chapters are bundled with esbuild at build time and loaded on demand into a Dynamic Worker with
globalOutbound: null, so demo code has no network access. - Bindings are capability-based facades passed via
ctx.exports: the demo code is unchanged, but its KV / D1 / R2 / AI calls are forwarded to session-scoped resources. Each visitor gets their own isolate, KV/R2 prefix, Vectorize namespace โ and a SQLite-backed Durable Object standing in for D1. - Everything cleans itself up: KV TTLs, Durable Object alarms, and an R2 lifecycle rule expire each session's data.