Chat & messaging
Channels, segments, presence: the primitives you need. Build the chat experience you want, not the one the SDK forces on you.
The problem
Chat SDKs are opinionated. They give you a UI library, a threading model, a presence API, and then bill you on top of the infrastructure you're already paying for. Switching later means migrating message history and rebuilding UI components.
You wanted a transport layer. You got a product.
How Celeris solves it
Celeris provides the primitives and stays out of the way. A Channel is a WebSocket connection. A Segment is a named sub-division within that channel: a thread, a room, a DM inbox, with no extra infrastructure. The default segment works automatically; named segments take one extra line of code.
You write the chat UI. Celeris moves the messages.
Signed token auth means users authenticate through your own backend:Celeris never sees your users. Token scope controls which channels a user can join, which segments they can write to. Your access logic stays in your code.
Connecting to a chat room
const client = createClient({ credentialProvider });
const channel = client.channel("workspace-general");
const thread = channel.segment("thread-4821"); // one segment per thread
thread.onMessage((payload, metadata) => {
renderMessage(metadata.tokenReference, readJson(payload));
});
thread.subscribe();
await channel.connect();
await thread.publish({ payload: jsonPayload({ text: "hey" }) });
No SDK-mandated message schema. No forced presence model. Your data shape, your event structure.
Relevant features
- Channels and segments
and threads without extra routing infrastructure - Signed token auth
access issued from your backend, no Celeris auth dependency - SDKs
and TypeScript today (Java, Rust, Python, and Flutter coming soon), or raw WebSocket - Pure WebSocket underneath
SDK is a convenience, not a cage