Chat & messaging

The problem

Chat SDKs have strong opinions. They give you a UI library, a threading model, and a presence API. Then they bill you on top of the infrastructure that you already pay for. A later change means that you must migrate the message history and build the UI components again.

You wanted a transport layer. You got a product.

How Celeris solves it

Celeris provides the primitives and stays out of your path. A channel is a WebSocket connection. A segment is a named stream inside that channel: a thread, a room, or a DM inbox, with no extra infrastructure. The default segment operates automatically. Named segments take one extra line of code.

You write the chat UI. Celeris moves the messages.

With signed token auth, users authenticate through your own backend. Celeris never sees your users. The token scope controls the channels that a user can join and the segments where the user can write. Your access logic stays in your code.

Connect 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" }) });

There is no SDK-mandated message schema and no forced presence model. You control the data shape and the message structure.

Relevant features

• Channels and segments: rooms and threads with no extra routing infrastructure
• Signed token auth: scoped access that your backend issues, with no Celeris auth dependency
• SDKs: JavaScript and TypeScript, Python, Go, and Java today (Rust and Dart are in development), or raw WebSocket
• Pure WebSocket underneath: the SDK is a convenience, not a cage