How to Choose an Open-Source IoT Platform
Platform Selection · Open Source IoT · Private Deployment | FastBee Technical Team | First published: October 26, 2026 | Facts checked: October 28, 2026
Choosing an open-source IoT platform starts by confirming device protocols, the data and control loop, private deployment conditions, and license boundaries; then validating capacity and recovery with representative load; and finally deciding the architecture and edition. Begin by turning requirements into acceptance criteria: whether devices can connect, whether data can be queried, whether command execution can be confirmed, and who restores service after a failure. This article keeps that evaluation thread and uses the official FastBee documentation to describe the evaluation entry point for each edition.
An open-source IoT platform is IoT software whose source code is public and which grants rights such as use and modification under a corresponding license; it usually organizes device access, identity management, data processing, and business APIs. Available source code does not mean there are no license obligations, nor does it mean the platform already meets the project's security, capacity, or availability requirements.
Selection Criteria: Turn Requirements into Acceptance Criteria
A PoC (Proof of Concept) tests whether a key approach holds under defined devices, environments, and processes. A selection PoC must agree on pass conditions in advance and keep message payloads, logs, and recovery records; one successful demo cannot replace continuous-operation and failure-recovery validation.
| Dimension | Verification question | PoC evidence |
|---|---|---|
| Device access | Which protocols do real devices use? How are authentication, reconnection, and gateway sub-devices handled? | Verify registration, reporting, command delivery, and reconnection with real devices or message payloads. |
| Data and rules | Are properties, events, and commands modeled clearly? How is historical data retained and exported? | Trace a message's full path from access through rules, alarms, and queries. |
| Operations and security | Can the team control permissions, audit, keys, backups, and upgrades? | Rehearse access control, backup recovery, and upgrade/rollback. |
| Scale and reliability | What are the device count, reporting frequency, peak concurrency, and recovery targets? | Load-test at the target load and record resource use, latency, loss, and recovery behavior. |
| Openness and cost | Which databases, messaging components, and commercial licenses are involved? How is data exported on exit? | Review the license, dependency boundaries, and the migration/export path. |
How Common Architectures Differ
An architecture's name alone does not decide whether it is better; it has to match the team's operations capability, load pattern, and failure-isolation goals.
| Pattern | Strengths | Cost and applicable scenarios |
|---|---|---|
| Modular monolith | Fewer components, straightforward development and deployment; suits fast validation and a small-to-midsize start. | Modules share resources and release cadence; validate boundaries and capacity under the target load. |
| Separate message access layer | The broker can handle connections, authentication, and message distribution, and the access layer can scale independently. | Adds cluster operations, monitoring, upgrade, and consistency duties; evaluate it when connection pressure or protocol needs are clear. |
| Microservices | Services split along business boundaries can be deployed and scaled separately, which helps multiple teams collaborate. | Adds network calls, observability, and release complexity; splitting alone does not guarantee failure isolation. |
| Cluster deployment | Deploy the relevant components across multiple nodes to share load or design failover. | Verify node discovery, state consistency, and failover; a monolith can also be clustered, and a cluster is not the same as microservices. |
| Edge plus center | The edge side can perform protocol conversion, caching, or local decisions; suits sites with unstable networks or low-latency needs. | Requires managing edge lifecycle, versions, and offline synchronization; usually combined with the central platform. |
These patterns can be combined; they are not mutually exclusive product categories. When evaluating, draw the real data path across devices, gateways, the broker (message broker), business services, the relational database, the time-series database, and visualization. FastBee's Open Source Edition overview lists a Java backend, a Vue frontend, MySQL/Redis, and an optional time-series database; the Cluster Edition documentation provides reading paths for the service cluster and the Web cluster. A documentation entry point does not constitute a performance commitment for a specific project.
Private Deployment Checklist
Private deployment means installing the platform on infrastructure the organization manages itself or entrusts to a manager, with data, access permissions, and operations responsibilities made explicit. It is not automatically the same as being fully offline or keeping data in-domain; confirm external dependencies such as maps, notifications, and image pulls item by item, and who is responsible for patches, certificates, backups, monitoring, capacity, and recovery.
- List required and optional components, ports, domains, certificates, image sources, and external network dependencies.
- Confirm where configuration, database, uploaded files, and message data are persisted, and the backup frequency.
- Rehearse installation, device access, alarm notification, and service restart recovery in a clean environment.
- Test pre-upgrade backup, database migration, application rollback, and operations handover.
- Load-test at the business's expected load; default deployment instructions cannot replace a capacity test.
FastBee officially provides the Open Source Edition Docker deployment documentation. The minimum environment it lists is 2 CPU cores and 4 GB of memory, with Docker 20.10+ and Docker Compose 2.0+; these are official deployment prerequisites, not a measured production capacity or a guarantee of device access scale. Check configuration and security steps against the target edition, and do not use test default credentials as-is in production.
Choosing a FastBee Edition
FastBee documentation covers the Open Source, Commercial, and Cluster editions separately. According to the feature comparison in the Open Source Edition overview, the open-source edition includes MQTT, products/devices/Thing Models, Scene Linkage, and rule scripts; multi-tenancy, the alarm center, and OTA firmware upgrade are listed as commercial-edition features. When you need these features, check the corresponding edition first rather than applying a generic IoT platform feature list to the open-source edition. Web SCADA is listed as an add-on module in the current comparison and should not be treated as included by default in the commercial base license.
Licensing should be checked against the official website statements and the code license separately. FastBee's official pages state AGPL v3; its commercial licensing page separately uses the phrase "non-commercial use" for the open-source edition. AGPL v3 itself is not a synonym for "commercial use prohibited"; GNU's description of the AGPL stresses its copyleft terms and the network-interaction source-availability condition. Projects should check the LICENSE and additional terms of the specific release and the FastBee official licensing statement, and obtain written clarification where the scope of application is inconsistent; this article does not draw a licensing conclusion for any specific project.
| Documentation entry | Evaluation starting point | Confirm before deciding |
|---|---|---|
| Open Source Edition V2 documentation | MQTT access, devices/Thing Models, rule scripts, installation, and secondary development. | AGPL v3 obligations, whether the intended use is permitted, required protocols, and operations responsibilities. |
| Commercial Edition documentation | Device access, platform operations, extensions, hardware, and licensing material for the commercial platform. | Licensing party, deployment environment, delivery and customization rights, upgrade and service scope. |
| Cluster Edition V2 documentation | FMQ, service/Web clusters, Kafka, load balancing, and load-testing material. | Cluster components, topology, capacity boundaries, failure drills, and operating cost. |
Find the platform's positioning on the FastBee website; for a trial installation of the open-source edition, see the Open Source Edition V2 documentation and the Open Source Edition feature overview. Confirm commercial licensing and delivery boundaries with the supplier; do not infer them from the edition name alone.
Design a Reviewable PoC
- Pick one real device type, one representative protocol, and one critical alarm flow.
- Verify device authentication, data mapping, historical queries, threshold rules, notifications, command delivery, and operational audit.
- Install in the target private environment and check network loss, restarts, backup recovery, and the upgrade path.
- Record load, latency, failures, and manual operations steps, and decide to scale or stop against the criteria agreed in advance.
For example, when validating warehouse temperature monitoring, you can use one sensor or a message simulator and check in sequence: "report temperature → historical query → trigger notification when the condition is met → deliver control → device reports the result". This is only a proposed test scenario, not a FastBee customer case; notification and alarm behavior must be configured for the chosen edition, and open-source Scene Linkage is not directly equivalent to the commercial alarm center.
A capacity estimate can first be written as: average reporting rate = number of online devices × reports per second per device. For example, if 1,000 devices report once every 10 seconds, the average is 100 messages/second (an arithmetic estimate, not a measurement, and not a FastBee performance figure). Load testing should also cover burst reconnection, payload size, QoS, rule processing, and storage writes, and distinguish the counts sent by devices, received by the platform, successfully stored, and completed by business execution.
Record for each round the platform edition, deployment topology, hardware resources, device or simulator version, connection count, payload size, QoS, test duration, latency statistics, failure/duplicate counts, and the failure-recovery process. Acceptance thresholds are set by the project owner before testing; do not reuse vendor load-test numbers that omit their conditions.
Conclusion: start from the real access loop and operational responsibilities. First use a minimal PoC to validate devices and deployment, then decide the architecture and edition against quantifiable scaling, isolation, or licensing needs.
FAQ
Can an open-source IoT platform be used directly in production?
You cannot decide from the "open source" label alone. Check the license, maintenance activity, security updates, dependency components, deployment process, and the team's operations capability, and complete validation in the target environment.
Do we need microservices or a cluster from the start?
They are worth introducing only when load, availability, isolation, or team-collaboration needs outweigh the added operations complexity. Measure the bottleneck first, then choose the scaling path.
What is the licensing difference between the FastBee open-source and commercial editions?
FastBee states that the open-source edition uses AGPL v3, while the commercial and cluster editions are delivered under commercial licensing. The website's usage statement and the license must be checked separately; the name AGPL does not by itself imply "commercial use prohibited". Check the LICENSE, additional terms, and contract of the target release, and obtain written clarification where statements are inconsistent.
Official Resources
- FastBee website
- FastBee documentation
- Open Source Edition V2 documentation
- Open Source Edition Docker deployment and minimum requirements
- Cluster Edition V2 documentation and acceptance guidance
- FastBee commercial licensing statement
- GNU's description of AGPL v3
This article is a platform selection reference; the warehouse flow is a proposed PoC and the capacity example is an arithmetic estimate; no device load testing or customer project measurements were performed for this article. Verify features, licensing, support, and deployment requirements against the official documentation for the chosen edition, the actual release files, and the parties' written agreement.