Manifesto
Why PNeX exists — and why we rebuilt everything in Rust.
Why Rust, why from scratch
PNeX is written from scratch in Rust — not a port of an existing stack. We chose a ground-up build because the industrial IoT status quo is a glue stack: a distributed SQL database, a search engine, a message bus, a task queue, workers, a separate web UI. Every brick adds its configs, its security updates, its operational traps. The result: gigabytes of RAM burned moving sensor points, fragile deployments, three languages to master.
PNeX takes the opposite path: one language, one workspace, a server that does only two things — data and authoring — and devices designed to regulate on their own. The client-server contract is checked at compile time, both ways.
Principles
Three ways to coordinate devices. Today: the server-mediated loop — device to server to device — carried by the flow engine, for uses that can tolerate an outage. The server never writes a pin on its own initiative. Next: autonomous devices, which PNeX casts a configuration onto and which regulate on their own, in flash, keeping their metrics through a server or internet outage. Later (in design): the resilient M2M mode — device to device, with no center — where each actuator node carries its own rule on a self-healing IPv6 mesh (OpenThread) with peer-to-peer pub/sub (zenoh-pico). The hub only configures and collects: losing the server does not freeze the field, by construction.
One language. Server, web app, flow engine, firmware builds, thermophysics: everything is Rust in one workspace. The same types compile natively and to WebAssembly — the client-server contract is checked at compile time.
Fewer bricks. Typical IoT stacks run five storage and messaging bricks — a distributed SQL database, Elasticsearch, NATS, Redis, a task queue. PNeX runs on three: PostgreSQL, OpenObserve and Valkey. The rest is covered by Postgres-backed workers and the flow engine.
Frugality. A complete self-hosted stack fits in a few hundred megabytes of RAM. It is a product of its time: modern hardware and AI make frugality possible, and cheap hardware makes the edge genuinely autonomous.
AI as an authoring aid. An integrated assistant reads telemetry, drafts flows and functions. Devices stay strictly read-only for the assistant: AI helps humans, it never touches the field.
Thank you
PNeX crosses ideas from ThingsBoard, ESPHome, Node-RED and every open IoT platform we learned from — rebuilt in Rust. But it exists because people contributed. This debt of gratitude will never be settled.
The flow programming model PNeX follows — nodes, wires, and the confidence that operators can program.
Device management and dashboards for IoT fleets, and a benchmark we aim at.
The firmware experience we wanted: configure, build, flash, update — without a toolchain.
Single-binary observability that carries PNeX telemetry and logs.
A full-Rust identity provider — OIDC without a JVM.
Rust for UI: one codebase for web, Linux, Windows and Android.
The Rails-on-Rust server framework that carries the whole API.
Async ORM beneath the server, from migration to query.
Thermophysical properties, embedded in-process instead of a service.
The open map rendering that powers the POI map.
Lightweight 360 panorama viewer behind the media previews.
The firmware build and flashing toolchain behind server-side builds and browser flashing.
The vendored flow runtime PNeX supervises — our thanks to its authors.
Templates behind notifications, faithful to Jinja.
The async runtime under everything.
Every crate we stand on. PNeX exists because people contributed.
And thank you — if you use it, criticize it or contribute. That is how free software grows.