NNG: a brokerless messaging library in C, and what it replaces

The problem NNG solves: messaging without a broker

Most messaging stacks assume a broker process: your application connects to it, it routes, and it becomes another thing to deploy, monitor and keep alive. NNG takes the other route. It is a library, not a service, and the README describes it as "a lightweight, broker-less library, offering a simple API to solve common recurring messaging problems, such as publish/subscribe, RPC-style request/reply, or service discovery." The connection management, retries and reconnection logic live inside the library, so the application code deals with messages rather than sockets.

The audience is narrow and specific: developers writing C or C++ services who want messaging primitives without a broker and without pulling in a runtime. NNG is implemented in C, requires C11 and CMake, and can be built as a shared or a static library. It is designed to be embedded. If you are writing Python or Go, you would normally reach for a binding rather than the C library itself, and the README notes that some API capabilities useful for foreign language bindings are not implemented yet.

How the scalability protocols are wired into the library

NNG is a rewrite of the Scalability Protocols library known as nanomsg, and the README says it retains compatibility with the original while adding capabilities. That compatibility is two-sided: the project offers both wire compatibility and API compatibility, and existing nanomsg and mangos applications can interoperate with NNG applications automatically. In practice this means you can replace one endpoint at a time rather than rewriting a whole topology.

The internal design is what separates it from the original. The README states that NNG "scales out to engage multiple cores using a bespoke asynchronous I/O framework, using thread pools to spread load without exceeding typical system limits." It also avoids tying itself to file descriptors, which the README gives as the reason new protocols and transports are easier to add; TLS is cited as the demonstration. The security section lists TLS 1.2 and optionally 1.3 transports.

One design decision worth calling out: NNG separates protocol context and state from sockets. The README argues this makes concurrent applications "vastly simpler than previously possible." That is a real structural difference from nanomsg, and it is also the part most likely to trip up code being ported.

Building NNG with CMake and running a request/reply demo

The README does not walk through installation, so the concrete starting points are the repository itself and the demo directory. NNG is built with CMake and a C11 compiler; the README states it can be produced as a shared or a static library. The top level of the repository contains CMakeLists.txt and a cmake/ directory, and the demos live under demo/, with subdirectories including demo/reqrep/, demo/pubsub_forwarder/, demo/async/, demo/rest/, demo/stream/, demo/http_client/ and demo/raw/.

A typical out-of-tree configure and build looks like this. The commands below follow the standard CMake workflow; the README does not spell out individual options, so check CMakeLists.txt for the switches your build needs.

Where NNG is the wrong tool

The compatibility section is unusually candid about gaps. Legacy nanomsg still offers capabilities NNG lacks: enhanced observability with statistics, and tunable prioritization of different destinations. The README says these "are missing, but will be added in a future release." If your operational model depends on per-socket statistics or on steering traffic toward preferred peers, NNG is not a drop-in replacement today.

Performance is the second caveat, and it cuts against the usual assumption. The README states that "some simple single threaded, synchronous applications may perform better under legacy nanomsg than under NNG," explaining that NNG's internal design is slightly less efficient in those scenarios but benefits greatly when concurrency or multiple sockets or network peers are involved. So a small synchronous tool that talks to one peer is exactly the case where the rewrite buys you nothing.

There is also a branch question. The main branch is the development branch. The README warns that its content "is under development and may not be suitable for production use" and directs users to the stable branch for the latest stable release. As a major release, NNG 2.x carries breaking API changes relative to 1.x, though a migration guide exists at docs/ref/migrate/nng1.md. Pin to a released tag rather than tracking main.

NNG against ZeroMQ and legacy nanomsg

The obvious alternative is ZeroMQ, and the README positions NNG relative to it directly: NNG, like nanomsg "(and to some extent ZeroMQ)", is a lightweight broker-less library solving recurring messaging problems. The shared idea is the same, sockets with messaging patterns instead of raw TCP. The difference in approach is what the pattern layer is built on. NNG avoids ties to file descriptors and uses its own asynchronous I/O framework with thread pools, which the README presents as the reason new transports such as TLS were straightforward to add. ZeroMQ has a far larger ecosystem and language surface; NNG's answer is a smaller C core with a context model that separates protocol state from the socket.

The second alternative is legacy nanomsg itself, which is still maintained as a separate repository (libnanomsg). Choosing between them is mostly a question of which gaps you can live with: nanomsg has the statistics and destination prioritisation, NNG has TLS transports, the thread-pool design and the context API. For a new project the README's framing points toward NNG; for an existing nanomsg deployment that relies on the missing observability features, staying put is defensible.

Licence, maintenance and the cost of upgrading to 2.x

NNG is licensed under MIT, which the README describes as "a liberal, and commercial friendly, MIT license" whose goal is to minimize friction in adoption, use, and contribution. For most teams that means no copyleft obligation and no separate commercial agreement; the LICENSE.txt file in the repository root is the authoritative text, and anything beyond that is a question for your own counsel.

Maintenance looks healthy on the evidence available. The repository is not archived, and the last push was on 2026-09-21. Releases include v1.12.3, described as a bug fix release, alongside v2.0.0-beta.1 and v2.0.0-beta.2, both marked pre-release. The practical consequence is that the 1.x line is where the bug fixes are landing while 2.x is still in beta, so the upgrade cost is not just code changes: it is the risk of running a pre-release. The README points to docs/ref/migrate/nng1.md for the API changes, and that document is the thing to read before you commit to 2.x. Note also that the README does not document rollback or downgrade steps, so plan the branch and tag you pin to before you start.

Editorial conclusion

Adopt NNG if you are writing a C or C++ service that needs pub/sub, request/reply or service discovery and you do not want to operate a broker. Do not adopt it if you need the statistics and destination prioritisation that legacy nanomsg still has, or if you are on the main branch expecting production stability. Check the stable branch, read the migration guide at docs/ref/migrate/nng1.md, and confirm the API you plan to use is implemented rather than left for a future release.

Frequently asked questions

Official sources

1. License: MIT
2. nanomsg/nng on GitHub
3. Project website
4. README
5. Releases