Multi-Tenant IoT Platform
There is a specific kind of engineering challenge that surfaces only when you try to bring IoT hardware, cloud infrastructure, and multi-tenant SaaS into a single coherent system. Each of those domains carries its own conventions, latency constraints, and failure modes. Real-time device telemetry cannot wait for synchronous HTTP round-trips. Multi-tenant isolation demands that no workspace ever leaks data into another. Network-layer access control — VPN provisioning, custom domains, device authentication — operates at a fundamentally different level from application-layer role management. This platform was built to bridge all three layers cleanly, from the embedded device endpoint to the customer-facing analytics interface.
The architecture is a Turborepo monorepo, dividing concerns across five applications and twenty shared packages. That split was deliberate: packages contain all business logic, typed interfaces, and infrastructure clients, while applications consume them as lightweight entry points. The result is that device service code, telemetry processing, and authentication logic are written once and referenced everywhere — no drift between the auth portal, the dashboard, and the MQTT broker.
Real-Time Telemetry at the Core
The heart of the system is an Aedes MQTT broker (the mqtt-api application), which handles inbound telemetry from connected devices. Devices publish to structured topic namespaces:
DEVICE_TELEMETRY— time-series sensor readingsDEVICE_ATTRIBUTES— device metadata and configuration stateGATEWAY_TELEMETRY— aggregated readings from gateway-class hardwareGATEWAY_ATTRIBUTES— gateway-level attributes
The telemetry-service package processes these payloads, normalizing them through TelemetryData and TelemetryPayload types before routing them downstream. Persistence and fan-out run through a Redis queue + BullMQ worker layer rather than inline in the broker, keeping message ingestion non-blocking regardless of downstream load.
Three device archetypes are modeled — INTERNAL, INTEGRATION, and EXTERNAL — each carrying location coordinates, configuration state, and status metadata. This taxonomy lets the platform treat first-party hardware, third-party sensor integrations, and external data feeds through a unified device interface.
Multi-Tenant Cloud Workspaces
Every customer operates inside a cloud — the platform's term for an isolated workspace. Clouds carry a full membership model with four roles: OWNER, ADMIN, MEMBER, and VIEWER, each scoped to a distinct permission surface. The cloud-service package manages the full lifecycle — creation, settings, member invitations, and soft-deletion — while cloud-auth-service handles session binding so that a user's active cloud context is always consistent across applications.
Custom domains are first-class. Each cloud can map a custom domain through CNAME verification plus a token-based DNS record check, managed by cloud-domain-service. This is not a bolted-on feature; it is a core part of the tenant identity model, allowing enterprise customers to serve their own teams from their own branded URLs.
Dashboard and Observability
The dashboard-web application gives each cloud a widget-based analytics interface scoped under [cloudId]/dashboard/[dashboardId]. Dashboards are composed from a DashboardGrid with WidgetCard slots, making it straightforward to add new widget types without restructuring the layout engine.
Behind the scenes, a dedicated async logging pipeline (log-service) captures distributed operations across all applications through a Redis queue. Nine log categories and trace ID propagation make it possible to reconstruct the full lifecycle of any device message, authentication event, or workspace action without coupling log writes to the hot path.
Network Access Control
A less visible but critical component is the OpenVPN management API (openvpn-api), an Express application that provisions and manages VPN access for devices and users. This layer ensures that device traffic can be routed through controlled network tunnels — relevant for deployments where devices are behind NAT, on restricted networks, or require secure mesh connectivity before telemetry can reach the MQTT broker.
Supporting Infrastructure
The twenty shared packages cover every cross-cutting concern:
| Domain | Packages |
|---|---|
| Auth | auth-service, sso-service, cloud-auth-service |
| Device & Telemetry | device-service, telemetry-service |
| Workspace | cloud-service, cloud-domain-service, cloud-member-service |
| Messaging | mail-service, sms-service |
| Infrastructure | redis-queue, log-service |
| Frontend | ui-elements |
| Users | user-service |
This package structure means that when the authentication model changes, every application that consumes auth-service picks up the update from a single source — no per-app patches, no diverging session schemas.
Newsletter
Stay updated! Get all the latest and greatest posts delivered straight to your inbox