Why I built Fluxychat

Most modern hosts make HTTP easy. Stateful WebSockets are still awkward on the same platform, and the managed realtime products that fill the gap often come with sales calls, stiff pricing, or a push to move your database over to them.

I built Fluxychat because I wanted chat to deploy like the rest of my stack: application code on a Worker, rooms without running a separate socket cluster.

This is open beta. I work on it solo. I'd rather hear what's confusing in onboarding than get a long feature list.

Rooms need sticky state. Durable Objects handle presence, typing, and fan-out per room.

Cloudflare documents that a single Durable Object can serve many concurrent WebSocket clients; FluxyChat uses one Room object per room so load and billing stay room-scoped instead of one global socket fleet.

Messages and metadata sit in D1 so you keep queryable history without handing everything to a third-party BaaS.

The same Worker serves HTTP (JWT mint, REST writes, webhooks, GDPR export) and upgrades to WebSockets. One deploy surface, Cloudflare billing you can read.

If you already run APIs or static apps on Cloudflare, chat can live on that account instead of adding Pusher, Ably, or another region somewhere else.

Cloudflare’s own docs vocabulary — coordination, shared state, chat rooms, WebSocket hibernation — is the same story FluxyChat implements with one Room Durable Object per channel.

Hosted cloud: sign up, run the quickstart wizard, and you get a project, member JWT, room, and first message in a few minutes. Clerk handles auth. The console covers rooms, agents, webhooks, and billing hooks.

Self-host: clone the MIT monorepo, deploy apps/worker to your Cloudflare account, run D1 migrations, and point @fluxy-chat/sdk at your Worker URL. You own secrets, upgrades, and where data lives.

Same codebase either way. Hosted saves setup time. Self-host gives you the keys. Both let you read the code.

REST on Vercel is easy; long-lived WebSockets often are not — limits, pricing, and workarounds (managed Vercel WebSocket products or DIY functions) show up in every builder thread.

FluxyChat keeps your Next.js or Nuxt app where it is and runs room WebSockets on Workers + one Durable Object per room. You skip a separate Pusher/Ably line item and avoid running your own socket VPS.

See /guides/cloudflare-workers-chat for the step-by-step mental model after Cloudflare’s official chat demo.

Most live-chat listicles target support teams: inbox, ticketing, CSAT. FluxyChat is different. It is the room layer for chat inside your SaaS UI — tenant-scoped rooms, @fluxy-chat/sdk, D1 history, operator console.

You can still build a support experience on top (see docs/use-cases/support-chat.md). I am not trying to replace Intercom. I am trying to replace the part where you either rent generic channels or run your own socket cluster.

Agentic products fit here too: user messages and agent tool_call / tool_result share one WebSocket timeline, so you can see what happened before wiring Salesforce, HubSpot, or whatever integration runner you use.

Stream and TalkJS get you to polished chat UI fast. Fluxychat is for people who want messages on their Worker, readable source, and a hosted trial that can become self-host without rewriting transport.

PartyKit and generic edge realtime tools excel at collab sessions and custom party state — not tenant-scoped chat with history, templates, and operator tooling. See the comparison table on /compare.

Supabase Realtime and Convex bundle realtime with their database. Fluxychat does not ask you to migrate Postgres. You deploy Worker + D1, or use our hosted stack.

Pusher and Ably are strong managed channels at scale. Fluxychat fits if you'd rather pay Cloudflare and own the schema, or try hosted first and fork when you need to.

Workers + Upstash Redis DIY is valid if you want to build every piece. Fluxychat is the pre-wired chat layer (room DO, D1, SDK, reconnect semantics).

Vercel WebSocket workarounds and Ably’s Next.js tutorials solve adjacent problems; FluxyChat targets in-app chat on Cloudflare with room-per-DO scaling — see /compare.

At this stage I prefer edge pricing and explicit quotas over opaque per-connection enterprise deals.

Plans and billing hooks live in the console. The Worker enforces quotas on messages and agent invokes.

Self-hosters pay Cloudflare directly. Hosted users start on a free tier and upgrade when limits show up. No sales call required to try it.

Browser or server SDK → Worker (HTTP + WebSocket) → Durable Object per room for live state → D1 for messages, projects, and webhooks. Admin JWTs mint member tokens server-side so API keys stay off the client. An optional agent worker handles mentions via webhooks and posts replies into the same room stream.