Zetta: an API-first Node.js platform for talking to devices over hypermedia

Everything is a resource, and the API is the interface

Zetta is an open source, API-first, Node.js-based platform for the Internet of Things, and the design commitment that defines it is that the HTTP API is the interface rather than a side door into one. The key concepts are explained on the Zetta doc wiki, which the readme points to for a conceptual overview, getting started tutorials including a mock device project, and the API reference. The package keywords give the flavour of the approach: zetta, iot, internet of things, api and hypermedia, and the dependency on argo, argo-formatter-siren and api-media-type shows that the responses follow the Siren entity format for hypermedia APIs. That choice has consequences. A client does not get a bespoke JSON shape for a device but a generic envelope carrying entities and their relations, which means a client can traverse from a device to its resources to a stream without the server inventing a new endpoint for each hop.

The dependency list names the whole architecture

The package.json is worth reading closely, because for a project like this the dependencies are the architecture. There are the Zetta modules themselves, zetta-device for the device model, zetta-http-device for talking to HTTP devices, zetta-scout and zetta-auto-scout for finding and automatically connecting devices, zetta-streams for the streaming layer, zetta-events-stream-protocol at version 5 for the event protocol, and zetta-scientist, which is the library for scientific measurement and control. Then there are the substrate pieces: argo and argo-formatter-siren for the hypermedia routing and formatting, calypso with calypso-level and calypso-query-decompiler for the key value store and query compilation, levelup for the storage layer, rx for the reactive streams, revolt for the HTTP server, medea and medeadown for media handling, titan for the logging setup, ws for WebSockets, spdy for HTTP/2, and zetta-rels for relations. The presence of zetta-cluster in the dev dependencies tells you the clustering work is a separate library, tested against this one rather than folded into it.

Installing from GitHub or from npm, and both routes are one command

The install is short, and the readme offers two routes. Cloning from GitHub gets you the source, which you then install with npm.

git clone [email protected]:zettajs/zetta.git && cd zetta

npm install

Or you take the published package.

npm install zetta

The package name is zetta, the main entry point is zetta_runtime.js, and the repository description points at the project site at zettajs.org. The tree matches a Node project with a lib directory for the implementation, a bin directory for the command line entry points, a test directory, and both zetta.js and zetta_runtime.js at the root. The scripts section names the test command, which runs mocha with the spec reporter and the exit flag, a coverage script pointing at bin/_coverage, and a tag script pointing at bin/_tag, which is the routine that cuts a release and tells git what the version is. That last one is a small detail that dates the project, since automating version tags through a shell script in bin was common before release-please and semantic-release became the default.

The CLI, the scout and the cluster are separate pieces

The platform is presented as a set of cooperating tools rather than one monolith, and the dependency list shows how they divide. The scout is the discovery mechanism, and zetta-auto-scout is the variant that connects devices automatically rather than having you point it at a device address. The cluster library provides multi-node support and lives outside this repository as a dev dependency, so you pull it in alongside Zetta when you need it. The event stream protocol, at version 5, is the piece that lets a client subscribe to changes rather than poll, and the ws and spdy dependencies indicate the transport underneath, with WebSockets for the event channel and spdy for HTTP/2 on the API. The siren formatter is what turns the internal model into the hypermedia responses a client consumes, and the api-media-type dependency is the piece that declares the media type of those responses. If you are building a client in another language, that media type is the contract you code against.

Zetta is for devices that have to be reachable as resources

The mock device tutorial on the wiki is the clearest statement of the model. You describe a device, its resources and the relationships between them, and the platform addresses them over HTTP. The Quick Start is described as the quintessential Hello World project for Zetta, covering how to install Zetta, create a new Zetta project, fire up a Zetta server and call a Zetta API, and it is said to take a few minutes. That is the useful entry point for an evaluation, because a mock device needs no hardware and tells you whether the resource model fits the way you think about your devices. The key question the platform answers is where the boundary sits. Zetta assumes that a device has state, that its state is addressable, and that the relationships between resources are worth modelling explicitly, and that is a good fit for sensors and actuators with meaningful internal structure. It is a worse fit for a fleet of identical endpoints that only differ by URL, where the modelling buys you nothing and the HTTP overhead is pure cost.

An old release line, and a repository that still moves

The version picture needs stating carefully, because the two signals disagree. The published releases are old: v1.5.1 from 2017-11-01, v1.5.0 from 2017-07-07 and v1.4.0 from 2017-01-17. The repository is not archived and the last push was on 2026-06-20, and the package.json declares version 1.6.0, which is a version that has no corresponding tag in the release list. So the source tree is being worked on while the published tags have not moved since 2017, and the version you would get from npm is the 1.5 line rather than the manifest you see in the repository. The build status badge points at a Travis CI configuration on the master branch, and the dependencies are pinned in a package-lock.json. The community channels are a Google group for discussion and a Gitter chat, and issues go to the GitHub issues page. The project is MIT licensed, with the LICENSE file at the top level and the licence field in the manifest, and the author is listed as Kevin Swiber.

Editorial conclusion

Zetta fits a developer who wants physical devices and software services to be addressable through one HTTP resource model, since that is the whole premise of the platform, and who is willing to work in the Siren and hypermedia style its API uses. It does not fit a team that wants a maintained framework with a current release cadence, because the most recent published tags are v1.5.1 from 2017-11-01 and v1.5.0 from 2017-07-07 even though the last push to the repository was on 2026-06-20, so you are building on a package manifest that still declares version 1.6.0. Before you start, read the Zetta doc wiki rather than the readme, because the documentation lives there, and check the dependency set for the Rx, Argo and LevelUp era it targets, since those are the packages that will age first on a modern Node install.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zettajs/zetta on GitHub