iotgateway and the industrial gateway you configure in a browser

Two sides, one browser tab

IoTGateway is an industrial IoT gateway with a browser/server architecture, and the description of it in the README is geometric. Southbound connections reach your devices and systems, things like PLCs, barcode scanners, CNC machines, databases, serial devices, host computers, non standard equipment, OPC servers, OPC UA servers and MQTT servers. Northbound connections reach IoT platforms, with IoTSharp, ThingsCloud, ThingsBoard, Huawei Cloud or your own platform such as an MES or SCADA, and the traffic is bidirectional.

The design decision is the B/S architecture with visual configuration. There is no configuration file format to learn and no scripting layer to debug, which is the difference between a gateway that a plant engineer can operate and one that needs a developer every time a production line changes. The project is built on .NET 10, is written in C#, and the repository is a solution with separate projects for the application, the data access layer, the model, the service layer and the view model, plus a Plugins/ directory and the WalkingTec.Mvvm framework the UI is built on.

The audience is a Chinese speaking industrial integration team, which is visible in the driver list and the platform list, and the enterprise version is sold separately, with the open source project and the commercial product sharing a name.

Edge computing is mentioned as a first class capability in the description, which is what separates a gateway from a protocol translator. A translator moves data from A to B, and a gateway can also compute on it, and the feature list backs that up with support for calculation expressions, change based upload and periodic archiving.

The southbound list is the product

The southbound drivers are what decides whether a gateway fits a plant, and the list is specific: Siemens PLC, Mitsubishi PLC, Modbus, Omron PLC, OPC UA, OPC DA, AB PLC, MT machine tools and Fanuc CNC.

Those are not arbitrary. They cover the three families that dominate Chinese industrial automation, Siemens, Mitsubishi and Omron, plus the Rockwell AB line, the two open protocols, OPC UA and OPC DA, Modbus as the universal field bus, and two machine tool vendors, MT and Fanuc, which is a signal that the project aims at discrete manufacturing and CNC cells rather than only at process plants.

The driver list is presented as extensible, with a link to documentation for driver extension and a TCP client page, so a plant with a device nobody supports is not automatically disqualified, but the extension path is a documentation topic rather than a plugin marketplace, and reading it is part of the evaluation.

Two capabilities apply across the drivers rather than to one of them. Device data can be written, not only read, which is what separates a gateway from a collector, and calculation expressions are supported, which is where the edge computing claim becomes concrete, since a computed value can be derived from several tags and uploaded as a variable of its own.

Northbound: telemetry up, RPC back down

The northbound side connects to IoTSharp, ThingsCloud, ThingsBoard, Huawei Cloud and other third party platforms, and the operations it supports are telemetry and property upload plus RPC reverse control.

The RPC direction is the one worth understanding properly, because it is what makes the architecture bidirectional in a meaningful sense. Uploading telemetry is a fire and forget operation. RPC means the platform can call back into the plant, through the gateway, to read or write a device variable. A cloud application can therefore command a machine, and the gateway is the component that translates that command into a southbound write.

The change based upload and periodic archiving features belong here too, since they describe when data moves rather than where it goes. Change based upload sends a value when it changes, which is what you want for a machine that is idle most of the day, and periodic archiving keeps a time series regardless, which is what you want for a compliance record. Together they are the difference between a gateway that floods a platform and one that costs a sensible amount to run.

The README lists all four platforms as northbound targets, which is worth noting for anyone deciding how tightly they want to couple to one vendor.

The gateway also serves MQTT, OPC UA and a Modbus slave

The services section describes something a pure northbound and southbound gateway would not need, and it is the part of the project that makes it usable inside an existing plant network.

There is a built in MQTT server, on port 1888, with an additional path at 1888/mqtt, and it supports websocket-mqtt. The stated purpose is direct connection to your MES, SCADA and similar systems, so a plant that already speaks MQTT can read the gateway's variables without a northbound platform in the picture at all.

There is a built in OPC UA server, reachable at opc.tcp://localhost:62541/Quickstarts/ReferenceServer, and the point of it is that your devices can then talk to other devices through the gateway using OPC UA, which turns the gateway into a protocol bridge for plant-to-plant traffic rather than only a cloud uplink.

And there is a built in Modbus Slave, described as a simulated device, on port 503. That is a testing and commissioning tool: a Modbus server you can point a client at to exercise a configuration before the real device is wired up.

The front end matches the same practical bent. The web interface updates over websocket without a page refresh, there is a 3D digital twin demo, and the project supports connecting to web based SCADA configuration projects, with a webscada-project.json file in the repository root. For an integrator, that means the gateway can be shown to a plant manager as a live view rather than as a service on a command line.

Four ways to run it, and what the container exposes

The documentation offers four deployment routes, and they are linked separately in the README: running the release package, running with Docker, running from source, and a publish deployment for a hosted environment.

The Dockerfile in the repository shows what the container looks like, and it is short enough to read at a glance:

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
COPY app /app
EXPOSE 518
EXPOSE 1888
EXPOSE 503
ENV TZ=Asia/Shanghai
ENTRYPOINT ["dotnet", "IoTGateway.dll"]

Three ports are exposed and they line up with the features described above. 1888 is the built in MQTT server, 503 is the Modbus slave, and 518 is the web interface the browser configuration runs on. The timezone is pinned to Asia/Shanghai, which matters for a product that schedules archiving by local time, and the entry point runs the compiled IoTGateway.dll.

There is one inconsistency here that a reader should notice. The README describes the project as built on .NET 10, while the container base image is aspnet:8.0. Those are not the same runtime, so the image in the repository is not necessarily the image the current source expects, and anyone building from source should check which runtime their build output actually targets rather than assuming the Dockerfile is current.

The repository also carries an exported device settings spreadsheet, a Chinese document describing the database, and the WalkingTec.Mvvm framework directory, which tells you the UI layer is a third party framework rather than something bespoke.

The declarations are part of the contract

The README has a section of declarations, and two of them are conditions on use rather than marketing.

The first is that if you use the OPC UA protocol you must contact the OPC Foundation for authorisation, and that any resulting dispute is unrelated to the project. This is not the project's invention, since the OPC Foundation licenses its specifications, but it lands on whoever deploys the built in OPC UA server, and it is the kind of clause that belongs in a legal review rather than in a readme.

The second is about money. The project accepts funding and sponsorship in any form but explicitly does not promise or guarantee anything in return, and it asks that anyone who profits from IoTGateway contribute something back, whether code, documentation, opinions or sponsorship. The README also says to follow the MIT licence strictly, and there is a separate enterprise version described at its own documentation page.

That split is the usual shape for this kind of project. The open source gateway is complete enough to run a plant integration, and the commercial edition is where the support commitment and the additional features sit. An organisation evaluating it should decide early which of the two it is buying, because the two have different terms and different expectations.

The demo instance is also published with its credentials in the README, admin and the password iotgateway.net, and it is worth being explicit that those are for the shared demo. Anyone who installs the gateway should change the defaults before the first connection, because an industrial gateway with a published default password is a very attractive target.

MIT, a v3 line, and a quiet few months

The licence is MIT, with the licence text in the LICENSE file at the root, and the README asks users to follow it strictly.

The release history shows a v3 line landing in April 2025, with v3.0.0 on 2025-04-05 and v3.0.1 on 2025-04-07, two days later, and before that v2.1.1 from 2024-06-02. The repository is not archived, and the last push was on 2026-06-22, so work has continued after the v3.0.1 tag without a further release.

That gap between the newest tag and the newest commit is the normal state for a project whose releases track a documentation and packaging cycle rather than a fixed schedule, and the repository also carries an English README alongside the Chinese one, a CHANGELOG-less root but a large amount of release-note material in the readme itself, and the community channels for support, a WeChat group, a WeChat public account and a QQ group.

For an adopter, the practical points are these. The code is permissively licensed and the components are separated into application, data access, model, service and view model projects, so a specific piece can be replaced without rewriting the gateway. The driver set is the product, so check it against your device list before anything else. And the built in MQTT, OPC UA and Modbus services are the reason the gateway can be useful even if you never connect it to a cloud platform.

Editorial conclusion

Adopt iotgateway if you are integrating plant equipment with an IoT platform and your team would rather configure drivers and mappings in a browser than maintain a collection of protocol adapters. Do not adopt it if your estate is not built on OPC UA, Modbus, the named PLC families or the named cloud platforms, since the driver set is the product and the documentation does not cover a general extension path without reading the driver extension notes. Verify three things first: that the northbound platform you already run is on the list, that the demo credentials published for the online instance are not what you deploy, and that your OPC UA usage is authorised, since the project states that using the protocol requires permission from the OPC Foundation. The last push was on 2026-06-22 and the newest release is v3.0.1 from 2025-04-07.

Frequently asked questions

Official sources

1. iioter/iotgateway on GitHub
2. License: MIT
3. Project website
4. README
5. Releases