CloudlyPulse: An Edge-First Industrial IoT Platform
A typical plant runs compressors, chillers, boilers, CNCs and presses from different makers, each with its own controller and protocol. Their data stays locked in PLCs and local HMI panels, servicing is tracked in paper logbooks, and teams usually find a problem only after a shift is lost.
Many of these sites also have unreliable internet, so a cloud-only dashboard isn't enough. The software has to run next to the machines and keep working when the connection drops.
See it live
Live dashboards and trends for every machine, process-flow diagrams that show each component's state as it changes, energy use and estimated cost, and production efficiency (OEE) by shift.
Act on it
Alarms with email and webhook notifications and escalation, tickets raised automatically from events like an alarm or a service coming due, a full maintenance logbook, and scheduled PDF/Excel reports.
Control it safely
Setpoint and configuration changes with role-based permissions, two-factor sign-in, and a full audit log of who changed what, and when.
Add machines without code
14 machine types ship today, each described in a configuration file covering its tags, alarms, setpoints and diagram, plus a built-in simulator to demo a site before any hardware is connected.
CloudlyPulse runs on a small computer inside the plant. It talks to each machine in its own language, records every reading, and serves a web app that operators, engineers and managers use from any browser. An optional cloud tier brings many plants together and pushes software updates to them.
Three layers, each useful on its own
Machines. PLCs, drives and controllers, read over the protocol they already speak, read-only by default.
Edge server, in the plant. Collects readings, runs alarms and maintenance rules, stores history, serves the web app. Works with no internet.
Cloud, optional. Brings many plants together, keeps a device registry, and pushes software updates over the air.
How we built it
Configuration over code. Machine types, alarm rules and the rules that turn events into tickets are written as configuration files. Supporting a new kind of machine is mostly authoring a file, not changing the platform.
Offline first. The edge server needs no cloud, database server or message broker to run. When one is missing it carries on without it, which is what a plant with patchy connectivity needs.
Tested against the real thing. Beyond unit tests, features are proven with end-to-end runs on a live stack and against live protocol simulators, which caught integration bugs unit tests couldn't.
Small team, steady cadence. Three engineers, every change through a pull request into a protected branch, with CI on each one. Work shipped every month from February to September 2026.
We do not have a measured customer outcome yet. The first plant pilot, on a roll-forming production line, is being commissioned now. We'll publish a before-and-after figure (downtime or response time) once it has run long enough to measure. Until then, no number beats a guessed one.
What we can state exactly, counted straight from the project's own repository:
- 322 pull requests merged in 7.5 months
- 589 automated test files across the backend and web app
- 14 machine types, each added as configuration rather than new code
- 6 industrial protocols supported: Modbus, OPC UA, EtherNet/IP, BACnet, IO-Link and MTConnect
Discovery
Understand the problem, the users, and the real constraints before any design work starts.
Design
Architecture and UX decisions made deliberately, before a line of production code is written.
Build
Iterative development with regular check-ins, so direction can be corrected early and cheaply.
Test
QA and hardening against real-world edge cases before anything reaches production.
Ship & Support
Launch, then stay involved: monitoring, fixes, and iteration as the product keeps growing.
