Architecture
DeviceChain is a set of stateless Go microservices over a shared core library, coordinated by a Kubernetes operator and connected by NATS JetStream. A single instance serves all tenants (a shared-microservice model), with tenant isolation enforced at the messaging and storage layers rather than by running separate pods per tenant.
Domain Model
DeviceChain models the physical world with a small set of composable concepts. The defining choice is that device context is expressed as a typed relationship graph rather than a fixed assignment record — which keeps the model open to new entity types over time.
Multi-Tenancy
DeviceChain runs a single shared set of microservices per instance that serves all tenants, rather than spinning up a separate stack of pods for each tenant. Isolation is enforced at the messaging and storage layers.
Dashboards
DeviceChain includes an embeddable, version-controlled dashboard system for visualizing live device data. A dashboard is a tenant-scoped resource authored in the console and rendered from a portable JSON definition — the same definition can be embedded in any React app or opened in the standalone reference viewer.
Event Processing & Alarms
DeviceChain turns raw device telemetry into meaningful signals. A dedicated event-processing service watches events as they flow through the pipeline: a DETECT stage evaluates streaming rules in real time, and a REACT stage runs the automated responses each firing declares — raising an alarm (a stateful condition with a lifecycle, a severity, and a path to notify a human) or issuing a command back to the device.
Outbound Connectors
Detection is only half of automation — the other half is acting on the outside world. When a detection rule fires, its REACT actions can reach beyond the platform: call a webhook, or publish a message to a broker or cloud queue. These outbound connectors are how DeviceChain fans processed events out to the systems you already run — an incident tool, a data pipeline, another application's message bus.
AI Access (MCP)
AI assistants — Claude Desktop and Claude Code, Cursor, VS Code — can operate a DeviceChain tenant on a user's behalf through a Model Context Protocol (MCP) server. An LLM client connects, discovers a set of tools, and calls them to answer questions about your fleet: "which devices in Building 3 haven't reported in the last hour?", "summarize today's alarms for the cold-storage assets", "what's the latest temperature on thermostat T-114?"
AI-Assisted Authoring
A detection rule can be authored three ways in DeviceChain — a typed form, a visual automation canvas, and, with the AI service enabled, a plain-English "Describe" door. You type "raise a high alarm when a freezer's temperature stays above -15°C for more than ten minutes" and the platform drafts a rule you can review, adjust, and publish.
Tenant Tiers & Packaging
A tenant tier is how an operator packages what a tenant gets. It is a first-class, operator-defined entity — gold / silver / bronze, or whatever an operator chooses to name and sell — that other parts of the platform read but never redefine. A tier answers the question "how much?": the governance ceilings a tenant inherits and the AI models a tenant may use.
White-Labeling & Branding
DeviceChain lets a tenant present the console under its own brand: a logo, a color palette, and a product title replace the DeviceChain defaults throughout the tenant's console session. White-labeling is part of the open-source core — there is no separate edition for it — so an operator can run one instance and let each customer tenant see their brand.
Object Storage
Some things a platform holds are neither rows nor time-series points — a tenant's logo, a dashboard background image, and eventually firmware packages. These are opaque binary assets, and they do not belong in the relational database. DeviceChain stores them in a pluggable object store: one interface in the shared core library, with swappable storage backends selected by configuration.
Governance & Quotas
DeviceChain runs one shared set of services for all tenants, and tenant isolation there is about correctness — one tenant can never see another's data. Governance is the other half of that bet: fairness. Per-tenant quotas ensure that one tenant's burst, reconnect storm, or misconfigured rule cannot exhaust the capacity every tenant shares. Data isolation without resource fairness still lets one fleet degrade everyone; governance closes that gap.
Device Presence
DeviceChain keeps a live presence signal for every device — whether it is currently online, and when it last connected, disconnected, or reported activity. Presence is part of a device's last-known state (the same projection that holds its most recent measurements and location), and it surfaces on the device's Connectivity tab in the console.
Sparkplug-B Ingestion
Many industrial and building-automation fleets already publish telemetry as Eclipse Sparkplug B over an MQTT broker they operate. DeviceChain can ingest directly from those networks without asking the devices to change anything: it joins your Sparkplug environment as a Host Application and translates the edge traffic into the same events every other transport produces.
LwM2M Ingestion
Constrained and cellular fleets often speak OMA LwM2M — a compact device-management standard over CoAP. DeviceChain terminates LwM2M directly: devices connect to it over CoAP/UDP secured with DTLS, and their registration, telemetry, and firmware all map onto the same one device model every other transport uses.