Powerful Features for Real-time Apps
Everything you need to build scalable, reliable real-time applications. From pub/sub messaging to presence tracking and beyond.
Real-time Pub/Sub Messaging
Topic-based publish-subscribe messaging over WebSocket. Messages are delivered in milliseconds, and the SDKs reconnect on their own with exponential backoff.
- Topic-based routing scoped to app and room
- Wildcards and retained messages
- Load-balanced subscriptions for worker groups
- MessagePack on the wire, JSON accepted
Presence Tracking
Know who's online in real-time. Track presence per room, and across many rooms with lobbies, with automatic join/leave events.
- Real-time online/offline status
- Per-room presence lists
- Custom presence metadata
- Presence change callbacks
Quality of Service (QoS)
Choose the delivery level for each message, from fire-and-forget to acknowledged and deduplicated. Levels apply on the hop from kraken to an MQTT broker such as EMQX or Mosquitto. The default in-process broker ignores them and delivers at most once to connected subscribers.
- QoS 0: At-most-once (fire and forget)
- QoS 1: At-least-once (acknowledged, the SDK default)
- QoS 2: Deduplicated on the broker hop
- Honoured with an MQTT broker backend (BROKER_BACKEND=mqtt)
Access Scopes (Multi-Tenancy)
Partition communication by tenant using topic namespace scoping. Assign actors to scopes and all messages, webhooks, and state are automatically isolated.
- Topic namespace partitioning per tenant
- Broker-level enforcement, no app code needed
- Scope metadata flows through webhooks
- Works across rooms, topics, and presence
Access Control (ACL)
Fine-grained permissions for every topic. Control who can publish, subscribe, and manage topics with role-based access.
- Per-topic read/write permissions
- Role-based access control
- Actor-level authentication
- Short-lived client tokens for browsers
- Per-actor token scoping
Rooms & Namespaces
Organize your topics into logical rooms. Isolate conversations, games, or sessions, each under its own app, room, and topic namespace.
- Logical topic grouping
- Room-level presence tracking
- Automatic cleanup on disconnect
- Cross-room messaging
Topic Filters
Narrow message delivery to specific entities within a topic. Subscribe to "bookings" with filters ["booking_1", "booking_2"] and only receive updates for those items. Swap filters dynamically without resubscribing.
- Filter by entity ID within a topic
- Dynamic filter management (set, add, remove)
- Routed by the broker, with no payload inspection
- Up to 100 filters per topic per connection
Webhooks
Configure webhooks per topic to integrate with external systems: in an app's topic config in @nolag/core, or returned by your own auth service. Pre-populate state on subscribe and react to published messages with automatic tenant isolation via access scopes.
- Per-topic webhook configuration
- Automatic scope isolation in payloads
- Retries on failed requests
- Custom headers and authentication
Lobbies
Observe presence across multiple rooms simultaneously. Perfect for dashboards, admin panels, and monitoring applications.
- Multi-room presence observation
- Dashboard and ops center views
- Real-time status aggregation
- Up to 10 lobbies per room
Built for Production
Open-source infrastructure with the developer experience you deserve.
MessagePack Protocol
Efficient binary serialization for minimal bandwidth usage and fast parsing.
Client Tokens
With @nolag/core, issue short-lived browser tokens from your project signing keys, so end users never see a long-lived access token.
Auto-Reconnection
The SDKs reconnect automatically with exponential backoff and keep the connection alive with heartbeats.
Pluggable Backends
Swap the auth and fan-out backends: static tokens or your own HTTP auth service, the built-in broker or your own MQTT broker.
TypeScript First
Full TypeScript support with typed events and autocomplete.
Scalable Infrastructure
Built on Erlang/OTP. Cluster kraken nodes, or point fan-out at an MQTT broker such as EMQX or Mosquitto.
Technical Overview
The technical details that make NoLag fast, reliable, and developer-friendly.
Protocol Specifications
- Transport
- WebSocket (binary)
- Serialization
- MessagePack (not JSON)
- Max Message Size
- 900KB
- Heartbeat
- 30 seconds
- Reconnect Attempts
- Up to 10 with exponential backoff
Delivery Guarantees (QoS)
Honoured when kraken runs in front of an MQTT broker. The default in-process broker delivers each message at most once, to subscribers connected at the time. Read more
Fire-and-forget (fastest)
Acknowledged delivery, may duplicate
Deduplicated on the broker hop; not an end-to-end guarantee
Actor Types (Who Connects)
Device
Frontend clients
Example: Browser, mobile app
User
Authenticated users
Example: Logged-in account
Service
Backend services
Example: Your API server
Session
Temporary connections
Example: Anonymous guest
See it in action
Run the broker locally in one command, or dive into the documentation.