finds.dev← search

// the find

iot-ecology/rust-iot-platform

★ 306 · Rust · Apache-2.0 · updated Oct 2025

A high-performance IoT development platform built with Rust, designed for multi-protocol support and real-time data processing. This platform supports MQTT, WebSockets (WS), TCP, and CoAP protocols, making it highly flexible for diverse IoT applications.

A multi-service Rust IoT platform that handles MQTT, WebSocket, TCP, and CoAP protocols with a separate data processing worker and REST API layer. Aimed at developers building IoT backends who want something beyond a single-protocol broker. Primarily authored by a Chinese team, with documentation in both Chinese and English.

The architecture is genuinely well-separated: protocol handlers, data processing, API, and notifications are distinct binaries that communicate via Redis/RabbitMQ, which means you can scale or restart the MQTT handler without touching the HTTP API. The transmit layer supports an unusually wide set of sinks out of the box — Kafka, ClickHouse, Cassandra, InfluxDB, MongoDB, MySQL, and RabbitMQ — so you are not forced into a single storage opinion. CoAP support is rare in open-source IoT platforms and its inclusion is a genuine differentiator for constrained device use cases. Prometheus metrics endpoint exists, which means you can drop this into a standard observability stack without wiring it yourself.

No Cargo workspace at the root — each subdirectory is its own independent crate, so you cannot do a single `cargo build` or `cargo test` across the whole platform; this is a real friction point for contributors and CI. The `migrations` folder under `api/` contains only a `.keep` file, meaning there is no migration tooling actually set up despite the platform clearly needing a schema. Documentation is sparse in English and architecture diagrams are embedded as untranslated Chinese JPEGs, which will slow down anyone not reading Chinese. Test coverage appears near zero — `api/src/ut/` exists but the structure suggests it is scaffolding rather than actual test coverage of protocol handling or data processing paths.

View on GitHub →

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →