Skip to main content

​
Nothing breaks

The current version of Realtime is additive. The original Workspace Settings–based Realtime is not deprecated and not altered:
  • Existing channels and their triggers keep working exactly as before
  • The existing connection hash keeps working
  • The legacy Realtime tab stays fully editable
  • Both systems can run at the same time, on separate connection addresses
Adopting the new version is a choice, not a migration. You can stand a new realtime server up next to a live legacy implementation without touching it, build something new, and leave production running unchanged.

​
What changed

In legacy Realtime, realtime is configuration. You declare channel name patterns and tick permission checkboxes, one trigger per channel is the only place logic can run, and changes go live on save. It sits outside most platform workflows — no drafts, branches, version history, request history, or XanoScript. In the current version, a message is a real handler.

​
What that unlocks

The practical gap is in work that was awkward or impossible before:
  • Chat with a transcript, presence, and per-recipient redaction
  • Collaborative editing where each change is validated server-side first
  • Live dashboards fed by any task
  • Multiplayer state keyed to a typed channel path
  • Request/response over a socket, using deliver_to: sender
  • Streaming an LLM or agent response back over the same connection

​
Should you move?

There’s no deadline, so the question is whether you’re hitting the legacy ceiling. Consider moving a feature when:
  • You’re validating payloads by hand inside a channel trigger
  • You’re parsing IDs out of channel names, or trusting a client-supplied one
  • Different recipients should see different versions of the same message
  • You need a reply to the sender only, rather than a broadcast
  • Realtime logic needs to move through branches, review, and version history like the rest of your backend
If a legacy channel is doing simple fan-out and you’re happy with it, leaving it alone is a perfectly good answer.

​
Moving a feature over

Because both systems run side by side, migration is incremental rather than a cutover:
1

​
Create a realtime server

Create a new realtime server and note its connection address. It’s separate from your legacy connection hash, so nothing currently connected is affected.
2

​
Recreate the channel as a typed path

Turn chatroom/* into chatroom/{room_id} with a declared type, and set the channel’s publish policy, anonymous access, presence, and rate limiting.
3

​
Turn the trigger into messages

Legacy channel triggers usually branch on an action. Each of those branches becomes its own message with a declared payload and its own delivery target — and the authorization part becomes a join trigger.
4

​
Update server-side publishing

For each API, function, task, or database trigger that should reach V2 subscribers, replace Realtime Event (v1) with Realtime Publish. Supply the target server name and resolved channel path. Recreate any required validation and authorization in the publishing stack: the optional Message field labels the outgoing event and does not execute a message handler. See Publishing from Xano. Keep legacy publishing where you still serve V1 clients.
5

​
Point a client at the new connection address

Connect a client to the new server and exercise it while the legacy implementation keeps serving production traffic.
6

​
Cut over, then retire the legacy channel

Once the new path is proven, move remaining clients and disable the legacy channel — on your own schedule.

​
Next steps

Realtime

Start with the concepts and hierarchy.

Realtime (Legacy)

Documentation for the original version.