Horizon: a realtime backend for JavaScript apps on top of RethinkDB

What Horizon is for, and who it leaves out

Horizon targets JavaScript front-end developers who want a realtime app without assembling a backend first. The README describes the problem it addresses directly: building realtime apps "requires understanding and manually orchestrating multiple systems across the software stack", and most of the early work is boilerplate unrelated to the app itself. Horizon's answer is to ship the backend as a platform, so the developer writes front-end code against a streaming API instead of wiring WebSockets, a database layer and an auth flow by hand.

The repository layout matches that pitch. There is a server/ directory for the middleware, a client/ directory for the JavaScript library, and a cli/ directory holding hz, the command-line tool for scaffolding, development and deployment. The README lists four services available to developers today: Subscribe (a streaming API usable from the browser), Auth (connecting to providers such as Facebook, Google and GitHub), Identity (listing and manipulating user accounts), and Permissions (a model for protecting data from unauthorized access).

Who it is not for is just as clear. Horizon is tied to RethinkDB as its data store, so a team already committed to Postgres or MongoDB is looking at a second database, not a drop-in layer. The README also frames the escape hatch honestly: because data lives in RethinkDB, once an app needs custom business logic "developers can incrementally add backend code at any time". That is a real advantage over a fixed backend-as-a-service, but it assumes you want RethinkDB in your stack at all.

Four components and the data flow between them

Horizon is four things, not one. The Horizon server is described as "a middleware server that connects to/is built on top of RethinkDB, and exposes a simple API/protocol to front-end applications". The client library wraps that protocol in a JavaScript API for front-end developers. The hz CLI handles scaffolding, development and deployment. GraphQL support is listed as a fourth component, but the README is explicit that it "will not ship in v1" and that a GraphQL adapter would follow after launch.

The data flow follows from that description: the browser talks to the Horizon server over its protocol, the server talks to RethinkDB, and a subscription is a stream the server keeps open rather than a request the client polls. The repository includes protocol.md at the top level, which is where the wire format between client and server is specified. That file is the reference to read if you plan to write a client in another language; the README does not claim any client other than JavaScript.

Because the server sits between the app and the database, permissions are enforced in the server layer rather than in the client. The README presents Permissions as "a security model that allows the developer to protect data from unauthorized access", which is the piece that makes it safe to let a browser subscribe directly to collections. The practical consequence is that your security rules live in Horizon configuration, not in application code you write yourself.

The README also lists services that are not there yet: session management, geolocation, presence, plugins, and a backend API for integrating custom server code. Treat those as roadmap items. The document says upcoming versions "will likely expose" them, which is not a commitment.

Installing Horizon and running a first server

The README points contributors at the Contributing guide and the repository carries a GETTING-STARTED.md at the top level, which is where the project keeps its setup instructions. The README itself does not spell out an npm install command, so the exact package names for the client and the hz CLI should be taken from GETTING-STARTED.md rather than guessed.

The repository does document a container path, and it is the most concrete install recipe available. The Dockerfile expects a RethinkDB URI passed at runtime and your app mounted at /usr/app:

docker build -t horizon .
docker run -e RETHINKDB_URI=HOST:PORT -v /path/to/app:/usr/app -p 8181:8181 horizon

The Dockerfile comments state the two requirements plainly: the container needs a RETHINKDB_URI environment variable with -e RETHINKDB_URI=HOST:PORT, and your Horizon app must be mounted into /usr/app using -v /path/to/app:/usr/app. The image exposes port 8181 and its default command runs hz serve with --bind all, --connect pointed at $RETHINKDB_URI, and /usr/app as the app directory.

If you would rather not use Docker, the same command is the thing to reproduce on your machine once hz is installed:

hz serve --bind all --connect HOST:PORT /usr/app

That is the server entry point. You should see the server start and bind to all interfaces, with your app directory served from the path you passed. There is also a Dockerfile.dev and a docker-compose.dev.yml in the repository for a development setup, and docker-compose.prod.yml alongside them for production; the README does not describe what differs between the two compose files, so read them before assuming the dev one is safe to expose.

The RethinkDB dependency is the constraint that shapes everything

Every Horizon deployment needs a reachable RethinkDB instance, and the Dockerfile makes that a hard runtime requirement rather than a default. There is no documented storage adapter for anything else. If you cannot run RethinkDB, Horizon is not a candidate, regardless of how well the realtime API fits your app.

The second limitation is the release history. The repository lists v1.1.3 as its most recent release, dated 2016-06-15. The default branch is next, and the last push to the repository was on 2026-09-10, so the code has moved since that release, but the README's own framing of GraphQL as something that "will not ship in v1" still stands in the document. Anyone evaluating Horizon should read the README's feature list as the v1 surface and treat the upcoming services section as unshipped.

There is a third, quieter issue: the Dockerfile is built on node:5-slim. Node 5 is an old base image, and the Dockerfile installs git with apt before copying the repository and running test/setupDev.sh during the build. That build step means the image is not a clean runtime image; it runs a test setup script as part of construction. If you adopt the Dockerfile, that line is worth reading before you put it in a pipeline.

Finally, Horizon is the wrong tool when your app is not realtime. If you need request-response CRUD with an ORM and a migration tool, the streaming protocol and permission model are overhead you will pay for and never use. The README's own pitch is aimed at "engaging realtime apps", and nothing in it claims Horizon is a general-purpose backend framework.

How Horizon compares with a plain RethinkDB plus WebSocket stack

The honest alternative is not another backend-as-a-service. It is the stack Horizon is built on: RethinkDB with its changefeeds, plus your own WebSocket layer and your own auth. That is what the README says developers do today, and it is the approach Horizon is trying to replace.

The difference in approach is where the work lives. With a hand-rolled stack, you write the server that opens the WebSocket, decides which changefeed each client is allowed to follow, maps incoming messages to queries, and handles reconnection and auth token refresh. With Horizon, that server is the Horizon server, and the client library is what your front-end code calls. Your job shifts from writing transport and authorization plumbing to configuring permissions and calling the Subscribe and Auth APIs.

The trade-off is control. A hand-rolled stack lets you put arbitrary logic between the client and the database, in whatever language you like. Horizon's server is the middleware, and the README's answer to needing custom logic is to add backend code later, since data is already in RethinkDB. That works, but it means the first version of your app is constrained to what Horizon's four services expose. If your app's core value is the logic between request and response, Horizon adds a layer you will eventually route around.

A second alternative is to skip the realtime requirement. If a short polling interval is acceptable, a conventional HTTP API over any database is simpler to operate, easier to hire for, and has no dependency on a middleware server whose latest listed release is from 2016. Realtime is a feature you should be able to justify before taking on Horizon's operational surface.

Licence, maintenance and upgrade cost

The README answers the licence question in one line: "The Horizon server, client and cli are available under the MIT license". The repository's LICENSE file is at the top level, and the metadata confirms MIT. MIT is permissive, so embedding Horizon in a commercial product is not restricted by the licence itself. The usual caveat applies and is not legal advice: if you modify and redistribute the code, the licence's notice requirements still apply, and any third-party dependencies pulled in by the server, client or CLI carry their own terms.

On maintenance, the repository is not archived, and the last push was on 2026-09-10. The most recent release listed is v1.1.3 from 2016-06-15, so the gap between the last release and the last commit is wide. That pattern means fixes may exist on the next branch without a tagged release to pin to, which raises the cost of depending on a stable version.

Upgrade cost has two parts. The first is Horizon itself: with one listed release, there is little version history to reason about, and no documented migration path between versions in the README. The second is the platform underneath. The Dockerfile uses node:5-slim, and the CLI runs on Node.js, so keeping the runtime current is your problem, not something the project's release cadence will do for you. Before adopting, check whether the npm packages for the client and hz CLI resolve at the versions you intend to use, and read GETTING-STARTED.md for the install steps the README omits.

Editorial conclusion

Horizon fits front-end developers who want live queries and auth without writing a server, and who are willing to run RethinkDB as the only data store. It is the wrong pick if you need a mature, widely adopted platform: the latest release listed is v1.1.3 from 2016-06-15, and the README says the GraphQL adapter will not ship in v1. Before committing, check that the npm packages for the client and hz CLI still resolve, and run hz serve against a RethinkDB instance to confirm the server starts.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. rethinkdb/horizon on GitHub