Crossbar.io: a WAMP application router for RPC, pub/sub and multi-protocol bridging

WAMP as the routing protocol: RPC and pub/sub over WebSocket, REST and MQTT

Crossbar.io implements the Web Application Messaging Protocol (WAMP), an open protocol that combines remote procedure calls and publish/subscribe messaging in one connection. A service behind a WAMP router can both call procedures on other services and subscribe to topics, without managing two separate messaging systems. That combination makes Crossbar.io suited to event-driven microservice architectures where services need to both issue commands and receive notifications.

Three protocol families are bridged in one router process: WAMP over WebSocket, HTTP REST endpoints, and MQTT. An embedded sensor publishing over MQTT, a browser client opening a WebSocket, and a REST service making HTTP calls can all exchange messages through the same Crossbar.io node. The pyproject.toml description names it a multi-protocol application router for microservices.

The README introduces the project as decentralised middleware. It is published on PyPI under the name crossbar, and Docker images are available for three CPU architectures. Documentation is hosted at https://crossbar.io/docs/, and a getting-started guide lives at https://crossbar.io/docs/Getting-Started/.

Twisted event loop under the hood: what drives I/O and the Python 3.11 floor

Crossbar.io runs on top of Twisted, the Python asynchronous networking framework. This is explicit in the Framework :: Twisted classifier in pyproject.toml, and it has real consequences for engineers extending or debugging Crossbar.io: the codebase uses Twisted's deferred chains, protocols and reactor, rather than asyncio. Developers unfamiliar with Twisted will need to read its documentation alongside Crossbar.io's to understand the execution model.

Python 3.11 is the minimum version, set in the requires-python field of pyproject.toml. Classifiers list Python 3.11, 3.12, 3.13 and 3.14 as supported. Both CPython and PyPy are listed as supported implementations.

Three environment variables are set during installation by setup.py. LMDB_FORCE_CFFI=1 forces CFFI for the LMDB binding instead of a native C extension. SODIUM_INSTALL=bundled includes libsodium inside the package. PYUBJSON_NO_EXTENSION=1 uses pure Python for py-ubjson rather than a Cython extension. Those choices make the package installable without a C compiler for those three dependencies, which simplifies deployment on locked-down or minimal build environments. They also mean the package bundles a copy of libsodium rather than relying on a system-installed version, so upgrading the system's libsodium does not affect Crossbar.io directly, and the bundled version is the one that was tested against the current release.

Installing from PyPI and wiring up the config.json JSON Schema in VSCode

Crossbar.io is available on PyPI under the name crossbar. From source, setup.py documents two installation modes. A standard install runs:

pip install .

An editable development install runs:

pip install -e .[dev]

The Makefile also shows a development install path that first upgrades from requirements-dev.txt before the editable install.

Configuration lives in a file named config.json. A JSON Schema for that format is available at the URL shown in the README. To use it in VSCode for auto-completion, add these lines to your VSCode settings.json:

"json.schemas": [
    {
        "fileMatch": [
            "/config.json",
            "/.config.json"
        ],
        "url": "https://raw.githubusercontent.com/crossbario/crossbar/master/crossbar.json"
    }
]

Alternatively, add a $schema line at the top of config.json:

{
    "$schema": "https://raw.githubusercontent.com/crossbario/crossbar/master/crossbar.json",
    "version": 2
}

The README notes that the JSON Schema is experimental but should give contextual auto-completion on all config.json syntax. CTRL+Space activates IntelliSense in VSCode once the schema is wired up.

Docker images for three architectures: amd64, armhf and aarch64

Three Docker images are listed in the README, one per CPU architecture: crossbario/crossbar for amd64, crossbario/crossbar-armhf for armv7, and crossbario/crossbar-aarch64 for armv8. All three are on Docker Hub. The README gives no detail on which image tags correspond to which builds, how to mount a config.json into the container, or which environment variables the container process reads. Engineers deploying via Docker should consult the Docker Hub listing and the documentation at https://crossbar.io/docs/ for container-specific guidance.

The docker-compose.yml at the repository root does not start Crossbar.io. It defines a single ganache service for Ethereum testing, using trufflesuite/ganache-cli:v6.2.4 on port 1545 with a mounted data volume at ${PWD}/test/ganache/.data. This compose file is for the blockchain-related test suite rather than a deployment template. An engineer wanting a Crossbar.io container setup will need to write a compose file from scratch based on the Docker Hub image and the documentation at https://crossbar.io/docs/.

Development builds only: what the release history says about deployment risk

All three visible releases in the repository are tagged as development builds: master-202610061808, pr2301-null-dependabot_uv_ujson_6_0_0-202610050522, and pr2300-null-dependabot_uv_pip_26_2_1-202610050518. No release carries a plain stable version tag distinct from the automated build identifiers.

The current version in pyproject.toml is 26.9.1.dev1, a development pre-release marker. The Makefile contains a publish target that runs twine upload dist/*, which shows that stable PyPI releases are part of the workflow. Whether the most recent stable release is on PyPI and how to identify it is not shown in the repository listing.

For a production deployment that requires a reproducible build, pinning to a specific Git commit is the practical approach given the development-build release pattern, since no conventional stable version tag appears in the repository listing. The last push to the master branch was on 2026-10-06, and the repository is not archived. A community forum is available at https://crossbar.discourse.group/ and there is a StackOverflow tag for crossbar alongside the wamp tag for protocol-level questions.

EUPL-1.2 license, the legal/README.md, and three trademark claims

The pyproject.toml declares EUPL-1.2, the European Union Public Licence version 1.2. GitHub displays the license as Other because its automatic classifier does not recognise EUPL-1.2. The LICENSE file at the repository root holds the full licence text.

The legal/ directory contains a README.md. The README copyright notice in the main README reads Copyright (C) 2013-2021 typedef int GmbH. It also states that WAMP, Crossbar.io and XBR are trademarks of typedef int GmbH. The 2021 date in that copyright line reflects the date range in that specific notice; it does not indicate the project is unmaintained.

EUPL-1.2 is a copyleft licence with source disclosure requirements that activate when you redistribute a modified version of the software, and those requirements differ in scope and trigger conditions from what MIT or Apache-2.0 demand. An engineer planning to embed Crossbar.io in a product distributed to third parties should read the LICENSE text and the legal/README.md directly before making that decision, since the exact obligations depend on the distribution scenario. This article does not constitute legal advice.

When Crossbar.io is the wrong router: MQTT-only services or non-Twisted stacks

Crossbar.io suits teams that need both RPC and pub/sub in one router and can commit to the Twisted Python runtime. For applications using only MQTT pub/sub with no RPC and no browser WebSocket clients, a dedicated MQTT broker drops the Python 3.11 and Twisted requirements entirely, and such a broker is a more direct fit for that problem.

WAMP is also a constraint on every connected service. Clients that need WAMP for RPC or subscriptions must use a WAMP client library on their side, and while WAMP libraries exist for several languages, the requirement adds a dependency to every service that connects. Services built around gRPC, AMQP or plain WebSocket framing without WAMP would need a protocol adapter or a different message bus entirely.

The repository top-level entries include .ai and .gemini/ directories alongside CLAUDE.md and two documents named MODERNIZATION.md and MODERNIZATION_REVIEW.md. These indicate the project is using multiple AI coding tools for a codebase modernisation effort that is ongoing. An engineer reviewing the source for a production adoption should read MODERNIZATION.md before committing to specific internal APIs, since modules under active restructuring may change between commits. The OVERVIEW.md and DEVELOPERS.md files at the repository root are the other starting points for understanding the codebase structure.

Editorial conclusion

Use Crossbar.io if you are building distributed services that need both RPC and pub/sub messaging, and where you want one process bridging WAMP over WebSocket, REST and MQTT without separate brokers. Skip it if you need a stable versioned release, since all published builds are tagged as development builds with no stable version tag visible in the repository. Before deploying, read the EUPL-1.2 license in the LICENSE file and the legal/README.md, because EUPL-1.2 carries redistribution conditions that differ from permissive licenses like MIT or Apache-2.0.

Frequently asked questions

Official sources

1. crossbario/crossbar on GitHub
2. Issues
3. Project website
4. README
5. Releases