IoTSharp Platform: Installation and Architecture

What IoTSharp Is Designed To Manage

IoTSharp addresses the server-side work of building an IoT platform rather than a single protocol connector. The repository describes device access, telemetry collection, rule-chain processing, visualization, product and asset management, alarms, and multi-tenant operations. Its intended users include engineers building a control plane for connected devices, operators managing products and assets, and teams that need to process incoming data before presenting it to applications or users.

The platform supports HTTP, MQTT, and CoAP connectivity. The repository also describes extensible protocol integration, which is useful when a deployment needs a protocol adapter beyond the named built-ins. Data models cover telemetry, attributes, alarms, products, assets, and tenants. This combination is more substantial than a plain message broker because the project includes application-level entities and workflows around device data.

IoTSharp is presented as a product matrix rather than a single executable. The main repository is the platform and control plane. IoTEdge is a separate edge gateway runtime with Modbus, OPC UA, PLC drivers, scripting, registration, heartbeat, and configuration rollout functions. IoTEmbedded is a separate firmware-level runtime for MCU and RTOS targets, with Modbus RTU, MQTT, and a BASIC script engine. Tomur is described as a local model runtime for AI-related APIs. These components can be combined, but the README does not imply that every application needs all four pieces.

How Data Moves Through IoTSharp

Based on the repository layout, the main application is a .NET 10 service with a separate ClientApp front end. The application receives device data through the platform's connectivity layer, stores and organizes it through data and telemetry components, and exposes management functions through the web console. The repository includes separate projects for relational data, JSON-backed data, time-series storage, event buses, dependency injection, REST extensions, scheduling, interpreters, SDKs, and task actions.

The documented storage choices are more than one database label. The SonnetDB profile is intended to provide relational data, telemetry, cache, object storage, and the platform event queue as one data dependency. The traditional Compose file uses PostgreSQL with TimescaleDB, sets `DataBase` to `PostgreSql`, selects `TimescaleDB` for telemetry storage, and uses `CAP` with in-memory event bus stores for that deployment. The repository therefore supports alternative topology choices, but the exact behavior of every storage adapter is not documented in the README.

Rule chains are the processing layer between collected data and business behavior. The README names transformation, notification, automation, and business actions as rule-chain purposes. That means the platform is designed to let a device event trigger application logic, although the README does not provide a rule-chain file, node configuration, or execution example. The repository's many storage, event-bus, interpreter, and task-action projects indicate a modular backend, but the README does not document a public extension API for implementing a new protocol or rule node.

Docker Compose And First Initialization

The documented first run uses SonnetDB as the default local profile. Docker Compose starts the services in the background, after which the Installer is opened in a browser. The README states that the web console is available at port 2927 for this profile. The front-end development server is a separate workflow and is documented at port 27915.

The following command starts the SonnetDB profile. The README gives this exact command for a first local run:

docker compose -f docker-compose.sonnetdb.yml up -d

After Compose starts the services, open `http://localhost:2927` and complete the Installer initialization described in the README. The profile sets `ASPNETCORE_ENVIRONMENT=SonnetDB` and mounts `appsettings.SonnetDB.json`. Those details indicate that the selected configuration changes which data services and application settings are used. The README does not document the Installer's fields, default administrator behavior, or how to verify that initialization completed, so those points cannot be confirmed from the project documentation.

The repository also contains `docker-compose.yml` for the PostgreSQL and TimescaleDB topology. Its excerpt configures the IoTSharp service with `ASPNETCORE_URLS=http://+:8080`, waits for the database health check, and exposes connection strings for the main IoTSharp database, telemetry storage, and event bus store. The file is truncated, so the complete published port mapping and any remaining services cannot be reproduced here. The SonnetDB command should therefore be treated as the documented quick-start path, not as a complete production deployment guide.

Protocol Support Versus Edge Collection

MQTT and CoAP are named in the repository topics and overview, while the platform overview also lists HTTP. These protocols address server-side device access. They do not automatically mean that IoTSharp can collect from every industrial controller. Industrial collection belongs to the separate IoTEdge runtime, whose documented drivers include Modbus, OPC UA, and mainstream PLC collection drivers.

That separation creates an architectural decision. A team that only needs to receive MQTT telemetry can use the platform's device connectivity path. A team that must poll a PLC over Modbus or OPC UA needs to decide whether IoTEdge belongs between the controller and IoTSharp. The README says IoTEdge handles registration, heartbeat, capability reporting, collection-config rollout, and task receipts with the platform. It does not document how those steps are configured in the main repository, so a production design still depends on the separate edge documentation and configuration files.

IoTEmbedded addresses another boundary. It is aimed at MCU and RTOS targets and includes Modbus RTU, MQTT, a BASIC script engine, and dual-slot script storage with failure rollback. That runtime is not interchangeable with a server deployment. Selecting IoTEmbedded means designing firmware integration and script rollout, while selecting IoTSharp means operating a platform service and web console. The repository makes both options available, but it does not provide a single installer that bundles the entire matrix.

Deployment Scope, Limitations, And Upgrades

The main application targets .NET 10, which is a concrete adoption constraint for teams that have not yet standardized on that runtime. The README lists Docker, Windows service, Linux service, installer flows, and release artifacts as delivery modes. It does not give a single matrix of supported operating-system versions, container versions, database migrations, or rollback procedures. The README also does not document how to roll back a platform release.

The feature scope creates operational cost. A platform with device access, telemetry storage, rule processing, event buses, visualization, products, assets, alarms, and tenant management has more configuration surface than a point-to-point collector. The repository includes `CHANGELOG.md`, `ROADMAP.md`, and release artifacts, but the README does not state a supported upgrade path or compatibility policy for existing tenants and stored telemetry. Those details must be checked before an upgrade is scheduled.

The README reports recent releases v3.6 on 2026-04-23, v3.5 on 2025-09-28, and v3.3 on 2025-07-01. The repository's last push was on 2026-10-14. That supports the conclusion that the project has recent repository activity, but the README does not promise a particular response time for defects or security fixes. The roadmap also describes AI workbench, MCP tools, agent-assisted operations, and an ontology engineering track. Those are roadmap items or planned capabilities, not documentation of completed functionality. The ontology application track explicitly remains pending implementation and domain validation.

IoTSharp is released under Apache 2.0. That license identifies the project's licensing basis and permits review of its terms for the intended use. This article does not interpret legal obligations. Teams should review the repository `LICENSE` file and any dependency or separate-component licenses before redistribution or commercial integration.

Comparing A Platform With A Focused Collector

A focused alternative approach is to use a narrow broker or collector and keep device protocols, storage, dashboards, and automation in separate components. Such an arrangement can be simpler when the device fleet uses one protocol, telemetry has one destination, and no product, asset, alarm, or tenant model is required. It also gives the operator fewer platform-level concepts to configure.

IoTSharp takes the opposite approach at the application layer. It combines device access with management models, rule chains, visualization, multi-tenancy, storage choices, and platform operations. The SonnetDB profile makes the first run more compact by using one data dependency, but that does not remove the broader feature set. The main question is whether the team values a shared IoT application model more than a minimal data path.

The separate IoTEdge runtime is not an identical substitute for IoTSharp. IoTEdge focuses on gateway collection and has documented Modbus, OPC UA, PLC, and scripting capabilities. IoTSharp focuses on the control plane and application data model. They may be combined, but the README does not state that one replaces the other.

Editorial conclusion

IoTSharp fits engineers who need a broad platform with MQTT, CoAP, telemetry, rule chains, and tenant-aware administration. It is a poor fit for a narrowly scoped device collector or a deployment that requires only a lightweight gateway. The first checks should be the required .NET 10 target, the SonnetDB initialization profile, the documented Installer step, and whether the separate IoTEdge or IoTEmbedded runtime is part of the intended architecture.

Frequently asked questions

Official sources

1. IoTSharp/IoTSharp on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases