Solution

Multiplayer, out of the box.

Live cursors, presence, and shared state for docs, boards, and dashboards. The data layer that syncs your rows is the same one that broadcasts who's online and what they're doing — all from one server.

The problem

Adding multiplayer usually means bolting a realtime service onto your database and keeping two systems in sync: one for persistent data, one for ephemeral presence and broadcast. The seams between them are where the bugs live — stale cursors, ghosted users, state that disagrees with itself.

How Pylon solves it
01

Presence and live cursors

Join a room and publish presence — a cursor position, a selection, a typing indicator — and receive everyone else's in real time. Join and leave events are handled for you, so users appear and disappear cleanly instead of ghosting.

02

Shared state that persists

Ephemeral signals go over broadcast; the document itself is rows in your typed database, synced live to every participant. Because both run on the same server, the persistent state and the presence layer never disagree about who changed what.

03

Permissions that hold under concurrency

Row-level policies gate every collaborative write, evaluated on the hot path for each participant — so a viewer can't edit and a non-member can't read, even mid-session. Access changes take effect immediately across all connected clients.

Ship it on Pylon.

Scaffold an app in seconds, deploy free on Cloud, scale when you need to.