deepstream.io, a realtime data sync and pub/sub server that keeps records, events and remote procedure calls in step across every connected client.
deepstream.io is a realtime server for applications that need state to stay in step across many clients at once. It offers four primitives over a single websocket connection: records, which are JSON documents that synchronise automatically so every subscriber sees a change the moment it is written; events, a straightforward publish and subscribe channel for fire and forget messages; remote procedure calls, which route a request to whichever client has registered to answer it and return the result; and presence, which reports who is currently connected. Clients subscribe to what they care about and the server handles fan out, so an application does not have to poll, diff or reconcile state by hand.
It suits collaborative editors and shared dashboards, multiplayer and realtime game state, live tracking and telemetry feeds, chat and notification backends, and any service that needs to push updates to browsers, mobile apps or backend workers without building a bespoke socket layer. A HTTP and JSON interface sits alongside the websocket endpoint so systems that cannot hold an open connection can still publish and read.
deepstream ships upstream with authentication set to none, which means any client that can reach the port may read and write every record, event and remote procedure call, and its sample user file seeds a published example account. cloudimg replaces both before the server is ever reachable. The image is pinned to file based authentication with hashed and salted passwords, the user database ships empty so no account and no guessable default exist in the published image, and on the first boot of every instance a unique administrator password is generated, hashed with deepstream's own settings and written to a root only file. The server itself is bound to the loopback interface with a reverse proxy as the single public listener, and the service is held back from starting until that first boot credential is actually in place, so an instance can never come up with an open user database. Every image ships with a self test tool that opens two independent connections and proves a message really travels between them, plus a paired deploy guide and 24/7 cloudimg support.