Is any feature held back for a paid edition of infinimesh?

No. The open source core is complete and free. infinimesh is Apache-2.0 and the whole platform, including per-customer and per-partner access, is in the open source repos.

Can devices send data without MQTT?

Yes. Devices can send their own JSON with POST /v1/ingest and a device token, and read desired state with GET /v1/ingest/desired. It lands in the same shadow as MQTT and reaches the same addons.

Is the infinimesh API stable?

Yes. The v1 API is stable. REST paths are under /v1 and the protobuf packages are infinimesh.*.v1. Breaking changes are checked in CI against the proto v1.0.0 tag. See the API versioning policy in the core repo.

Does infinimesh include dashboards?

No. infinimesh streams device data through addons to tools you already run, such as Kafka, Postgres, InfluxDB or a webhook. Use Grafana or your own app on top.

Does infinimesh make my product EU Data Act compliant?

No software does that by itself. infinimesh gives you an access model where each customer and partner sees only their devices, which helps you build data access.

Apache-2.0 · self-hosted · written in Go

The device layer for your IoT and AI stack.

infinimesh handles device identity, access and state. Your data goes to the tools you already use: Kafka, Postgres, InfluxDB, a webhook. No dashboard you have to adopt. The open source core is complete and free. No feature is held back for a paid tier.

Run it in 5 commands Device examples Source on GitHub

How it works

Devices connect over MQTT 3.1.1 or 5, or send their own JSON over HTTP with POST /v1/ingest and a device token. The bridge checks the device certificate and topic. The shadow keeps reported and desired state. Addons read the stream and write it where you want it.

Access is the data model

Accounts, namespaces and devices form a graph. Share a namespace with a customer at READ, and with their service partner at MANAGE. Each one sees their devices and nothing past them. This is in the open source core, not a paid tier.

Relevant if you sell connected products in the EU and need to give customers access to their device data under the Data Act. infinimesh gives you the access model. It does not make you compliant by itself.

Who it is for

Device makers

You run your own backend and need each customer, and their partners, to see only their devices.

Teams with a data stack

You already have Kafka, Postgres or a warehouse and want devices to feed it, not a second dashboard.

Self-hosters

You want the backend on your servers, under Apache-2.0, without a price list per device.

Stable v1 API

REST under /v1, gRPC and Connect from one proto schema. Breaking changes are checked against the v1.0.0 tag. Versioning policy, API reference.

When not to use it

You want an all-in-one UI

No dashboards. Rules and alarms on device state are in core, but charts are up to you. Use Grafana on top of an addon, or ThingsBoard.

You need OTA inside the core process

Firmware delivery is a separate addon you build: hawkBit, Mender, or a signed webhook. None of them is a published image.

You need an HA broker cluster now

Bridge sessions can live in Redis, so a restart keeps them. A tested multi-replica broker cluster is not there yet.

New in 3.4

3.4.3: current release. Core, inf-cli, platform-operator and the Helm chart are at v3.4.3. The Go module path is now github.com/infinimesh/core/v3, so Go code imports core with the /v3 suffix. See the Go reference. The OTA addons stay at addons v3.4.2.
3.4.2: OTA addons released. The hawkBit, Mender and signed webhook addons are released in addons v3.4.2. You build them from source. There are no published images. Core 3.4.2 lets the webhook addon token read its namespace webhook URL, so the webhook addon needs core 3.4.2 or newer.
3.4.1: OTA requests and a reliable stream. An account asks for a firmware version and the OTA addon sets the target. On reported state the addon token can write only reported.ota, and inf plugins rotate replaces it. The shadow stream keeps every update across reconnects, with a 256-event replay window per namespace and a full resync after a larger gap. Changelog.
3.4: Rules and alarms. A CEL condition on device state, such as reported.temp > 70, raises an alarm. Ack and clear it in the console, the API or inf alarms. Cooldown and repeat stop alarm storms. Rules docs.
3.4: OTA contract. Core stores the target version per device and the status the device reports back. An OTA addon registers through the plugins API first, then the namespace switch turns on. hawkBit, Mender, and the signed webhook addon do the delivery. You build them. OTA docs.
3.4: Audit and quotas. Alarm, plugin and OTA actions are logged with who did them. Each namespace can cap devices and messages per second. Zero means no limit.
3.4: CoAP and Redis sessions. A CoAP gateway takes JSON on UDP 5683 for small devices on a private network. MQTT_SESSION_STORE=redis keeps bridge sessions across restarts. CoAP docs.

See it

The console from the 3.4 release, running on one laptop with Docker Compose.

Console devices list — Devices in a namespace with their tags and latest reported state.

Console device page showing the desired OTA version — One device with the OTA target version set in its desired state.

Console rules page — Rules: a CEL condition, a clear condition and a cooldown per rule.

Console alarms list with raised and acked alarms — Alarms raised by those rules, ready to ack or clear.

Console namespace OTA settings — The namespace OTA switch. It turns on only after an OTA addon is registered.

Addons

Each addon is a small separate service that reads device state and writes it out. Writing your own is mostly reading one stream: one stream per account or namespace, with device added and removed events, and an event id on every message so retries can drop duplicates. A read-only streaming token lets a long-running addon follow it without a per-device token. Stream docs, addons repo.

All addons ship as source in the addons repo. You build them yourself. There are no published images and no Helm entries. The latest addons release is v3.4.2.

Data sinks and connectors

Kafka / KafScale

One JSON record per shadow update on a Kafka topic, keyed by device id. Works with Apache Kafka and KafScale.

Postgres / TimescaleDB

One row per shadow update in a Postgres table, optionally a TimescaleDB hypertable.

InfluxDB 2 and 3

One point per shadow update, written with the official v2 client. Works with InfluxDB 2, Cloud and 3.

Webhook

One HTTP POST with a JSON body per shadow update, with retries and backoff.

MQTT bridge

Publishes shadow updates as JSON to an MQTT broker you already run, such as Mosquitto, EMQX, HiveMQ or AWS IoT Core.

RedisTimeSeries

Writes every number in reported state to RedisTimeSeries. The compose file also starts Grafana.

Redis stream

Writes reported state to the Redis stream objects, which the Elasticsearch, Snowflake and SAP HANA sinks read.

Elasticsearch

Writes device state from the Redis stream into the Elasticsearch index infinimesh. Runs next to redisstream.

Snowflake

Writes device state from the Redis stream into a Snowflake table. Runs next to redisstream.

SAP HANA

Writes device state from the Redis stream into a SAP HANA table. Runs next to redisstream.

Cloud Connect

Writes reported state to CSV files per device and minute, then uploads them to S3, Google Cloud Storage or Azure Blob.

OTA

hawkBit OTA

Connects a namespace to a hawkBit update server and assigns the distribution set for a requested version.

Mender OTA

Connects a namespace to a Mender open source server and creates one deployment of the requested artifact.

Signed OTA webhook

Posts OTA and membership events to your endpoint, and accepts a target or a report back. Needs core 3.4.2 or newer.

AI ready

AI agents and LLMs need device data with the same access rules as people. infinimesh has that model already. Device state will be available to AI agents over MCP and to any LLM through addons, scoped by the same permission graph. An agent sees only the devices its token can see.

You can run models locally with vLLM or Ollama, so device data stays on your servers. Hosted APIs work too, if you choose them.

MCP server coming soon

Read device state and set desired state from an AI agent, within the token's permissions. Not built yet.

LLM addon coming soon

Send device state to any OpenAI-compatible API: vLLM, Ollama, Mistral, OpenAI, Anthropic, Gemini. Not built yet.

Neither exists today. Until they ship, use the webhook or MQTT bridge addon to feed your own agent.

How it compares

Feature	infinimesh	ThingsBoard CE	Magistrala CE	EMQX
License	Apache-2.0, complete core, nothing held back	Apache-2.0, paid PE	Apache-2.0, paid EE	BSL for recent versions
Per-customer device access	Graph in core	Customer hierarchy in PE	Yes	No device registry
Device shadow	Yes	Attributes	No	No
Dashboards and rules	Rules and alarms, no dashboards	Yes	Moved to EE	Rules engine
OTA firmware updates	OTA contract in core, delivery through addons you build yourself (hawkBit, Mender, signed webhook)	Built in	Not in core, the separate edge Agent does binary updates	Not a device backend
Stack	Go services	Java	Go, many services	Erlang

Sources: ThingsBoard CE vs PE, Magistrala CE/EE, EMQX license. Checked 2026-10-12. Magistrala Agent and Magistrala docs for OTA, checked 2026-10-16.

Quickstart

One machine with Docker Compose.

git clone https://github.com/infinimesh/core.git
cd core
cp .env.example .env
docker compose up -d

.env.example pins INFINIMESH_VERSION=v3.4.3. On Kubernetes, the Helm chart is helm install infinimesh oci://ghcr.io/infinimesh/charts/infinimesh --version 3.4.3.

Open http://console.127.0.0.1.nip.io

CLI:

brew tap infinimesh/inf-cli https://github.com/infinimesh/inf-cli
brew install inf
inf login api.127.0.0.1.nip.io:443 infinimesh infinimesh --insecure-skip-verify

The local certificate is self-signed, so the CLI skips the check. Use a 3.4 CLI with a 3.4 core. The CLI guide covers quotas, rules, OTA and audit.

Then connect a device: ESP32 over MQTT, ESP32 over HTTP, Pico W, or curl. Small boards that time out on TLS: read the small-device TLS guide.