> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xano.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Legacy Realtime vs Realtime

> How the current Realtime differs from the original Workspace Settings version — and why nothing forces you to move.

## 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**.

|                            | Legacy Realtime                                    | Realtime                                                                                                |
| -------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Unit of work**           | A channel with a single trigger                    | A named message handler with its own function stack                                                     |
| **Payload**                | Whatever the client sent; you validate it yourself | A declared schema, validated before your logic runs                                                     |
| **Channel address**        | A name pattern such as `chatroom/*`                | A typed path template such as `rooms/{room_id}`                                                         |
| **Path parameters**        | Parsed out of the channel name as strings          | Declared input types (`text`, `int`, `decimal`, `bool`); raw join/session parameters can remain strings |
| **Where logic runs**       | One trigger per channel                            | Per message, plus five lifecycle triggers                                                               |
| **Delivery**               | Broadcast to the channel                           | Per-message `deliver_to` (`channel`, `sender`, `others`, `explicit`)                                    |
| **Server-side publish**    | `api.realtime_event` (Realtime Event (v1))         | `realtime.publish` (Realtime Publish)                                                                   |
| **Per-recipient control**  | None                                               | A deliver trigger can rewrite or drop each copy                                                         |
| **Access control**         | A fixed set of channel checkboxes                  | Channel settings, per-message auth, and triggers that authorize against your data                       |
| **Servers**                | One workspace-level configuration                  | Multiple servers, each with its own connection address                                                  |
| **Drafts and publish**     | Changes go live on save                            | Drafts, publish, branches, diffs, version history                                                       |
| **Observability**          | —                                                  | A Messages tab in Request History, with retention controls                                              |
| **XanoScript / CLI / Git** | Not available                                      | Full push, pull, diff, and export support                                                               |

## 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:

<Steps>
  <Step>
    ### Create a realtime server

    Create a new [realtime server](/realtime/realtime-servers-and-channels) and note its connection address. It's separate from your legacy connection hash, so nothing currently connected is affected.
  </Step>

  <Step>
    ### 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.
  </Step>

  <Step>
    ### Turn the trigger into messages

    Legacy channel triggers usually branch on an action. Each of those branches becomes its own [message](/realtime/messages) with a declared payload and its own delivery target — and the authorization part becomes a [join trigger](/realtime/realtime-triggers#join).
  </Step>

  <Step>
    ### 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](/realtime/publishing-from-xano). Keep legacy publishing where you still serve V1 clients.
  </Step>

  <Step>
    ### 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.
  </Step>

  <Step>
    ### 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.
  </Step>
</Steps>

## Next steps

<CardGroup cols={2}>
  <Card title="Realtime" icon="signal-stream" href="/realtime/overview">
    Start with the concepts and hierarchy.
  </Card>

  <Card title="Realtime (Legacy)" icon="clock-rotate-left" href="/realtime/realtime-in-xano">
    Documentation for the original version.
  </Card>
</CardGroup>


## Related topics

- [Realtime In Xano (Legacy)](/realtime/realtime-in-xano.md)
- [Realtime In Webflow (Legacy)](/realtime/realtime-in-webflow.md)
- [Realtime Functions (Legacy)](/the-function-stack/functions/apis-and-lambdas/realtime-functions.md)