After Cloudflare’s real-time chat tutorial

What the tutorial proves

Cloudflare’s real-time chat application tutorial validates the core pattern: WebSocket upgrade on a Worker, shared state in a Durable Object, fan-out to clients in a room.

That is the right mental model. It is not yet multi-tenant auth, billing, operator tooling, or client reconnect semantics.

Build a real-time chat application on Cloudflare Workers →

What teams add next (the long tail)

• Project-scoped JWT and room membership, not open rooms.
• D1 (or equivalent) for history, search, and export, not memory-only fan-out.
• Reconnect, loadMore, and delivery status on the client.
• Quotas, webhooks, GDPR flows, and an operator console.
• Agent tool_call / tool_result on the same timeline as user messages.

Cloudflare Workers WebSocket chat demo →

FluxyChat as the production layer

• One RoomDurableObject per room: same architecture as the tutorial, maintained in MIT source.
• Self-host on your Cloudflare account or try hosted beta. No second socket vendor.
• @fluxy-chat/sdk for React/Next.js; vanilla store for other stacks.
• Dashboard for projects, rooms, agents, and billing hooks.

Astro, Nuxt, or Vercel front

Keep your UI on Pages, Astro, or Vercel. Point the SDK at your Worker URL. You get edge chat without rebuilding the tutorial boilerplate on every feature.