A WebSocket backend for your app, with your own users
Your app already runs on its own host, with its own login, and now it needs live updates or a list of who's online. A live endpoint on Tessryx holds the WebSocket connections at the edge, and your app connects to it from wherever it lives.
You bring your own users: your backend signs a short token for each person, a JWT or an HMAC signature, and the key that checks it lives in Tessryx Secrets. ChatGPT or Claude, connected to Tessryx, can write the live endpoint and its join workflow, and tells you the name of the secret to store the key under.
What to ask your AI
Connect Tessryx to ChatGPT or Claude, then paste one of these, or say it your own way.
Live cursors on a shared board “add live cursors to the whiteboard in my react app. it's hosted on my own server, and my backend already signs jwts (HS256) for logged-in users with the board id in them”
Payments on an admin dashboard “when a stripe payment comes in, show it right away on the admin dashboard in my web app. the app is hosted somewhere else and my backend signs a jwt for each admin”
Who's viewing a document Needs Pro“show who else is looking at the same document in my app, with names and avatars from the jwt my backend signs with RS256. there are usually a few hundred people online”
What Tessryx runs for you
Updates from any workflow
Any workflow can publish to the live endpoint, from a webhook or a route your backend calls. The endpoint's own workflow shapes each update once for each room that has people in it, and every open copy of your app in that room gets the result.
Real-time pages, multiplayer and chatThe join workflow
A join workflow checks the token with the key you stored and admits the person under your own id for them, with only the channels they may send on. Your workflows can take away someone's right to send at any time, or close a room with a reason.
Your own users on live pagesMessages between users
Relay channels pass each user's messages to everyone else in the room about ten times a second, with no run per message. Every message is checked against a schema and stamped with its sender's id.
Channels for players and chatWho's in each room, by name
Your app gets the list of who's in each room, who joined, who left and how many are there, with the name and avatar your token carries. Someone counts as gone 30 seconds after their last tab closes.
Who's here (presence)A handler for your app's rules
A handler workflow checks each batch of messages before anyone sees it, for a top speed, a cooldown, turn order or who may erase a stroke. The sender's page hears about a dropped message through onRejected(channel, 'rule', reason).
Game rules checked at the edgeRoom state
A room can share a small state, like a board or round settings, which your app gets on joining and whenever it changes. Workflows can load it from your records when a room opens and save it back as it goes.
Shared room state
What it costs
Plan: FreeUp to 100 people can be connected to one live endpoint at once on the free plan, which gives 10,000 credits a month. Pro raises that to 5,000 people and 100,000 credits for $20 a month.
A person joining is 1 credit, the run of your join workflow, and a reconnect within a few minutes isn't charged. An update is 1 credit for each room with people in it, and a bigger room doesn't cost more. Relaying is charged by the minute: 1 credit for each person who sends, at least 2 while anyone sends, plus 8 when a handler checks the messages and 2 for each thousand watchers past the first thousand. Who's online is free.
A shared board with 200 people on it for an hour, 20 of them drawing in any minute, comes to 1,400 credits: 200 joins and 1,200 for relaying. Pro covers a board that size.
What it can't do yet
Ordinary pages and routes reply in a single response, without server-sent events or streamed HTTP bodies. Live updates travel over the WebSocket.
Ordinary pages and routes aren't streamedA join workflow sees the query your app connects with, which is where the token goes, and never the person's IP address.
Your logic can't see the visitor's IP or most request headersJavaScript in workflows and handlers is calculation only, with no npm packages. A workflow reaches other services through integrations.
JavaScript in workflows is calculation only
Questions
How does my app connect?
It loads the site runtime from your Tessryx site, https://<your-site>.tessryx.app/_tessryx/site-1.js, and calls tessryx.live(path, { host, query: { token }, onRelay, onPresence }). The runtime reconnects by itself and is sent what it missed, up to a minute's worth. Any WebSocket client works too, at wss://<your-site>.tessryx.app/_live/<endpoint>.
Which tokens can a join workflow check?
It checks JWTs and HMAC-SHA256 signatures over a message you choose. For a JWT, the key you store sets which algorithms pass: a shared secret takes HS256, HS384 or HS512, and a PEM public key takes RS256, RS384 and RS512 for RSA, or ES256 and ES384 for EC. Expiry is checked whenever a token has one, and audience and issuer when you name them.
Do I need a CORS setting?
A live endpoint needs no CORS setting, because browsers don't apply CORS to WebSockets. Your tokens and the join workflow decide who gets in, and an endpoint with neither a join workflow nor a sign-in gate is open to anyone.
What happens when a token runs out?
The join workflow sets when each admission ends, usually from the token's own expiry, at most 12 hours ahead. At that time the connection closes and joins again through the workflow, which turns away anyone you've cut off. Your app can then reconnect with a fresh token.
Can people sign in with Tessryx instead?
A page served from your Tessryx site can use Tessryx sign-in, through the same gate as any page. That sign-in doesn't travel to other websites.