# zeromq/czmq: a high-level C binding that hides the raw ZeroMQ API

> CZMQ wraps the ZeroMQ core API in a set of C classes with sockets, messages, actors, timers and CURVE security helpers. It suits C developers who want ZeroMQ patterns such as REQ, REP and PUB without managing contexts, sockets and frames by hand.

**zeromq/czmq** — High-level C binding for ØMQ

- Repository: https://github.com/zeromq/czmq
- Website: czmq.zeromq.org
- Stars: 1,274 · Forks: 542
- Language: C
- License: MPL-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/zeromq-czmq

## The five goals that define the CZMQ API

CZMQ is the high-level C binding for ZeroMQ, and the project states its goals explicitly. The first is to wrap the ZeroMQ core API in semantics that lead to shorter, more readable applications. The second is to hide as far as possible the differences between ZeroMQ versions 2.x, 3.x and 4.x. The third is to provide a space for development of more sophisticated API semantics, which is the reason the binding is a set of classes rather than a thin wrapper.

The fourth goal is to wrap the ZeroMQ security features with high-level tools and APIs, and the fifth is to become the basis for other language bindings built on top of CZMQ. That last goal explains the presence of a `bindings/` directory in the repository and a Python `setup.py` that declares the package name `czmq` and points its package directory at `bindings/python`. The `model/` directory, the `api/` directory and the `project.xml` file point the same way, at a machine readable description of the classes that drives code generation, with `mkdoc` and the `src/` tree holding the generated and handwritten parts.

The project says it grew out of the concepts developed in the ZeroMQ Guide, which is the honest way to describe the design. What CZMQ adds over raw libzmq is not new messaging semantics but vocabulary: a class per concept, ownership handled for you, and a smaller number of steps between opening a socket and exchanging a message.

Contributions follow the C4.1 process, the collective code construction contract, and the code style follows the CLASS guide, the C Language Style for Scalability. Both are ZeroMQ RFCs, so the conventions are documented elsewhere rather than in the repository.

## The class surface: sockets, messages, containers and helpers

The class list in the documentation is the fastest way to understand the scope. The messaging core is `zsock`, a high-level socket API that hides ZeroMQ contexts and sockets, `zmsg` for multipart messages, `zframe` for single message frames and `zstr` for sending and receiving strings. On top of that sits a set of general purpose containers and utilities: `zhash` and `zhashx` as simple and extended generic hash containers, `zlist` and `zlistx` for lists, `zchunk` for memory chunks, `ztrie` for tokenizable strings, `zdir` for file system directories with a `zdir_patch` companion for directory patches, and `zfile` for portable file handling.

The remaining utilities cover the parts of a distributed system that every project ends up writing by hand. `zclock` provides millisecond clocks and delays, `ztimerset` is a timer set, `zconfig` reads config files written in the ZPL format, `zrex` handles regular expressions, `zdigest` provides hashing functions, `zuuid` handles UUIDs, `ziflist` lists the network interfaces available on the system, and `zsys` collects system level methods. `zgossip` provides decentralized configuration management, and `zbeacon` handles LAN discovery and presence.

That is a broad surface for a binding library, and it is the main argument for adopting it. A project that needs multipart framing, a timer wheel, a config parser and an event loop would otherwise end up with a private utility layer of roughly this size. The counter argument is equally visible: every class in that list is API you inherit and must track as the library changes.

## Actors, the reactor and the poller

The concurrency story in CZMQ has three pieces. `zactor` is a simple actor framework, `zloop` is the event-driven reactor, and `zpoller` is a trivial socket poller class, with `zmonitor` providing a socket event monitor and `zproxy` able to run a steerable proxy in the background.

The actor model is the distinctive one. A CZMQ actor is a thread with its own ZeroMQ socket pair, which means an actor can be addressed by address the way any other ZeroMQ peer is, and the framework handles the pairing, the shutdown and the message passing. The project documents a section on CZMQ actors separately from the class reference, which suggests the actor lifecycle, including how a thread signals that it is finished and how the framework reaps it, is worth reading before writing the first one.

`zloop` sits underneath that for programs that do not want the actor abstraction. It is a reactor with timers and file system polling, and it is the component most often reached for directly, since a single threaded event loop with a handful of timers covers a large share of message driven programs. `zpoller` is the smaller tool for waiting on a set of sockets with a timeout, and `zmonitor` attaches to a socket to observe events rather than to consume them.

For a reader deciding between CZMQ and raw libzmq, this is the deciding area. Raw ZeroMQ gives you a socket and a context and leaves every event loop to you. CZMQ gives you three levels of choice, and the documentation on error handling matters here too, because the binding decides how a failed operation is reported to the caller.

## The security layer: zauth, zcert and zcertstore

ZeroMQ's security mechanisms are exposed through three classes: `zauth` for authentication, `zcert` for working with CURVE security certificates, and `zcertstore` for working with CURVE security certificate stores. This is the goal of wrapping the ZeroMQ security features with high-level tools, and it is the part of CZMQ that has the most value per line of code saved, because CURVE certificate handling in raw libzmq means working directly with the underlying crypto library.

The repository's build configuration shows what that costs at the dependency level. There are find modules for libsodium, for libcurl, for libmicrohttpd, for lz4, for nss, for systemd and for uuid, alongside `Findlibzmq.cmake` for the ZeroMQ library itself. Several of those are optional capabilities rather than the core, but the list shows how far CZMQ reaches beyond plain socket messaging: HTTP based transports, Kerberos, DNS resolution through NSS and compression through lz4 all sit in the same dependency set.

The `examples/security/` directory in the repository is the place to look for how these pieces are meant to be combined. A reader evaluating the binding for a secured deployment should read those examples before designing a certificate workflow, since the difference between a certificate held in memory and a certificate in a store is exactly the kind of thing that decides whether key rotation is possible later.

## Installing from packages or building the sources

Deb packages are available for Debian and Ubuntu, and for other distributions the project points at pkgs.org. Prebuilt binaries for the latest git `master` are also published through the openSUSE Build Service, in two channels: one marked as master only stable APIs, and another as the master draft. The presence of both badges in the project header is worth understanding, because it means the packages track the development branch rather than a tagged release, and the two channels differ in which APIs they are allowed to expose.

Building from source is a conventional autotools project. The repository has `configure.ac`, `Makefile.am`, `acinclude.m4`, `autogen.sh`, `CMakeLists.txt` and `project.gyp`, and the Dockerfile in the repository root shows the full sequence used for the container build:

```bash
RUN ./autogen.sh 2> /dev/null
RUN ./configure --quiet --without-docs
RUN make
RUN make install
RUN ldconfig
```

The Dockerfile is based on `ubuntu:latest` and installs the toolchain with `apt-get`, including `build-essential`, `libtool`, `autotools-dev`, `autoconf`, `automake`, `pkg-config`, `cmake` and `libkrb5-dev`, and it adds `libzmq3-dev` in a separate step, so the ZeroMQ library is a system dependency rather than something vendored in the tree. It also creates a `zmq` user and gives it passwordless sudo, which is a convenience for a development image rather than something to copy into production.

A CMake path exists alongside the autotools one, and the Windows build is described in two ways: with CMake, and with MSBuild, which the project marks as out of date and possibly no longer working. There is also a `Dockerfile`, a `Vagrantfile`, `Jenkinsfile`, `.travis.yml`, `appveyor.yml` and a `ci_build.sh`, so the continuous integration history spans several generations of tooling, which is a clue about the age of the build scripts.

## The release state a new user inherits

The most recent tag is v4.2.1, published on 2021-01-17, with v4.2.0 from 2019-02-10 and v4.1.1 from 2018-03-22 behind it. The repository is not archived and the last push was on 2026-04-15, so the branch has received commits since the last tag, even though no new release has been cut in years. The practical reading is that the master branch is where current work lands, and the openSUSE channels exist precisely because there is no recent tag to package.

That has consequences for anyone starting a new project. The stable API guarantee in the package channel refers to the master branch rather than to a versioned release, so pinning means pinning a commit. The version hiding goal, which promises to smooth over differences between ZeroMQ 2.x, 3.x and 4.x, is a promise about a library family whose latest major version is old, and the ZeroMQ version your distribution ships is likely newer than anything the binding was written against.

Some corners of the repository also look untended. The Python binding's `setup.py` still uses `distutils`, which is deprecated in modern Python, and it declares version `0.1` for a project whose release tags are at 4.2.1, so the Python path is a sketch rather than a maintained package.

The licence is MPL v2, with the terms in the LICENSE file, and the contributor list is in AUTHORS. For a binding library that other language bindings are built on, MPL v2 is a workable choice: modifications to the library files stay under the same licence, while applications that merely link against it are not forced to adopt it. Whether that reading matches your deployment is a question for whoever handles compliance, and this article does not give legal advice.

## Conclusion

Adopt CZMQ when you are writing C or C++ code against ZeroMQ and want the socket, message, timer and actor patterns already expressed as classes, especially when CURVE security or LAN discovery is part of the design. Do not adopt it for a new project if you need an actively released binding, since the most recent tag is v4.2.1 from 2021-01-17 even though the last push was on 2026-04-15, and check the libzmq version your distribution ships before relying on the version hiding claims. Before building, confirm that libzmq, libsodium and the other dependencies the CMake find modules expect are present, and decide whether the autotools or the CMake path fits your build.

## FAQ

### What is CZMQ?

It is the high-level C binding for ZeroMQ. It wraps the core API in classes such as `zsock` for sockets, `zmsg` for multipart messages and `zactor` for actors, and hides the differences between ZeroMQ versions 2.x, 3.x and 4.x as far as possible.

### How do I install CZMQ on Linux?

Deb packages are published for Debian and Ubuntu, other distributions are covered through pkgs.org, and prebuilt binaries for the latest git master are available from the openSUSE Build Service in a stable APIs channel and a draft channel.

### How do I build CZMQ from source?

The project uses autotools: run `./autogen.sh`, then `./configure --quiet --without-docs`, then `make` and `make install`. A CMake build is also described, while the MSBuild path for Windows is marked as out of date.

### How does CZMQ handle ZeroMQ security?

Three classes cover it: `zauth` for authentication, `zcert` for CURVE security certificates and `zcertstore` for certificate stores. Examples for these are kept in the `examples/security/` directory of the repository.

### What is the most recent CZMQ release?

The latest tag is v4.2.1, published on 2021-01-17, with v4.2.0 from 2019 and v4.1.1 from 2018 behind it. The repository is not archived and the last push was on 2026-04-15.

### What licence does CZMQ use?

The project uses the MPL v2 licence, with the terms in the LICENSE file in the repository.

## Sources

- [Issues](https://github.com/zeromq/czmq/issues)
- [License: MPL-2.0](https://github.com/zeromq/czmq/blob/master/LICENSE)
- [README](https://github.com/zeromq/czmq/blob/master/README.md)
- [Releases](https://github.com/zeromq/czmq/releases)
- [zeromq/czmq on GitHub](https://github.com/zeromq/czmq)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zeromq-czmq