`cloudflare_durable` WebSockets broken in preview; `cloudflare_module` inconsistent on Workers

[Erafle]

Describe the bug

While implementing NuxtHub Realtime / WebSockets following the official guide:
https://hub.nuxt.com/docs/guides/realtime

I’m seeing two issues depending on the Nitro preset:

1. cloudflare_durable preset: WebSocket connections never appear to establish after npm run build + npm run preview (visitor count stays at 0). In the browser console I also see:

WebSocket connection to 'ws://localhost:8787/ws/visitors' failed:

I get the same “0 visitors” behavior when deploying/running on Cloudflare Workers too.

2. cloudflare_module preset: Works correctly in npm run build + npm run preview, but once deployed to Cloudflare Workers, visitor counts are inconsistent (e.g. sometimes shows 1 visitor with 2 tabs open, sometimes 2, sometimes fluctuates).

This started happening on the latest NuxtHub update (multi-vendo).

Steps to reproduce

Repro A — cloudflare_durable preset (fails in preview + Workers)

1. Create a Nuxt app and install NuxtHub.
2. Follow the Realtime guide.
3. Configure Nitro preset to cloudflare_durable (as per docs / recommended approach).
4. Run:
   • npm run build
   • npm run preview
5. Open the app in two tabs.
6. Observe the Realtime visitors counter stays at 0 (no connections).

(Also reproduced on Cloudflare Workers with the same preset: visitors stay at 0.)

Repro B — cloudflare_module preset (works in preview, inconsistent on Workers)

1. Same setup as above, but set Nitro preset to cloudflare_module (Nitro docs).
2. Run:
   • npm run build
   • npm run preview
3. Open two tabs → visitors count behaves as expected locally.
4. Deploy to Cloudflare Workers.
5. Open two tabs → visitors count is inconsistent (often shows 1 even with 2 tabs, sometimes 2, sometimes fluctuates).

Expected behavior

• With cloudflare_durable, after npm run build + npm run preview, WebSocket connections should work the same way as they do in dev, and the visitors count should increase when opening multiple tabs.
• On Cloudflare Workers, visitors count should be stable and accurate for concurrent connections, regardless of preset.

Actual behavior

• cloudflare_durable: no working websocket connections in preview (and also seems broken on Workers). Visitors stay at 0.
• cloudflare_module: preview works, but Workers deployment yields inconsistent visitor counts.

[onmax]

cloudflare_module = each worker isolate has its own peers Set. This is expected.

Use cloudflare_durable with explicit DO bindings in wrangler.jsonc:

{
  "durable_objects": {
    "bindings": [{ "name": "$DurableObject", "class_name": "$DurableObject" }]
  },
  "migrations": [{ "tag": "v1", "new_classes": ["$DurableObject"] }]
}

Without this config, cloudflare_durable fails locally with "WebSocket connection failed" because Nitro expects the binding but doesn't auto-generate it.

Repro + fix: https://github.com/onmax/repros/tree/main/nuxthub-realtime-722

production: https://nuxthub-realtime-722.maximogarciamtnez.workers.dev

[Erafle]

Before the multi-vendor update, NuxtHub’s Cloudflare Workers realtime setup “just worked” out of the box because NuxtHub effectively handled the Durable Objects wiring as part of the Cloudflare-specific integration.

Also: is it possible to change the Durable Object binding name used for WebSockets? Specifically, can the binding name that defineWebSocketHandler uses (e.g. the default $DurableObject) be customized so I can target multiple Durable Object classes/bindings (for different realtime channels/features) in the same app?

[onmax]

@Erafle Good question. The custom DO binding name isn't a NuxtHub limitation; it's in Nitro.

Nitro hardcodes $DurableObject in cloudflare-durable.ts:12. The underlying crossws adapter already supports a bindingName option, but Nitro doesn't expose it.

Related: nitrojs/nitro#3378 (custom DO classes)

I'm working on a PR to add nitro.cloudflare.durable.bindingName config. Will update here once it's ready.

By the way, I feel your frustration - I'm facing the same issues, too. It used to be really easy to deploy on Cloudflare; now, I feel like it's a bit more complicated. However, I'm working on some pull requests and issues to try to simplify the deployment process on Cloudflare.

[onmax]

PR opened: nitrojs/nitro#3875 and nitrojs/nitro#3876

[Erafle]

Alright, a big thanks for your time and clarifications, I'll put this one in resolved.