How to Choose Commercial or Cluster IoT Editions: A FastBee Self-Hosting Guide
A practical FastBee edition decision starts here: use Open Source for non-commercial learning and technical validation; evaluate Commercial for typical small and midsize business projects; evaluate Cluster for horizontal scaling, greater device and message concurrency, or cluster high availability. Licensed Commercial and Cluster editions provide corresponding source code through private Git for organizations that need self-hosting and customization.
This is not a rigid price table based on device counts. The right boundary depends on business features, commercial rights, stable capacity, failure objectives, operational skills, and total cost.
1. Confirm What You Are Buying: Rights, Not Just Features
IoT selection often begins with “How many devices can it connect?” while more fundamental questions are missed: Can it be used in a customer project? Can the brand and business flows be changed? Is source code delivered? How are updates obtained? Do third-party components require separate licenses?
The FastBee Commercial License page lists the three main editions and optional modules. Open Source uses AGPL 3.0 and is marked for non-commercial use. Commercial and Cluster editions use perpetual commercial licenses with installation certificates and include first-year source updates. Web SCADA and smart speakers are optional modules and should not be assumed to be part of a base license.
Commercial delivery teams should include the following in procurement and acceptance:
- The target edition, deployment environment, and licensed entity match the contract.
- The exact platform, visualization, mobile, and other source-code scope is documented.
- Private Git access, build documentation, first-year updates, and renewal terms are clear.
- Customization, software-copyright rights for modifications, and source redistribution boundaries are understood.
- Responsibility for maps, weather, TDengine, and other third-party licenses is assigned.
- Custom development, deployment support, training, and incident support are priced or excluded explicitly.
These items prevent more hidden costs than comparing purchase prices alone.
2. Edition Positioning at a Glance
| Dimension | Open Source | Commercial | Cluster |
|---|---|---|---|
| Typical use | Personal learning and non-commercial validation | SME commercial projects and self-hosted delivery | Larger device fleets, concurrency, and cluster availability |
| License | AGPL 3.0; official matrix says non-commercial | Perpetual commercial license with installation certificate | Perpetual commercial license with installation certificate |
| Source and updates | Public repositories and community updates | Corresponding source through private Git after licensing, with first-year updates | Corresponding source through private Git after licensing, with first-year updates |
| Deployment model | Fast single-node validation | Single-node commercial deployment with simpler operations | FMQ service clusters, web clusters, Kafka, load balancing, and related components |
| Protocols and business features | Bounded by the official open-source matrix | Adds multiple protocols, multi-tenancy, alerts, reports, data bridging, and more | Follows Commercial business capabilities with a stronger scaling and availability path |
| Operational complexity | Low | Moderate for smaller teams | Higher; requires cluster deployment, monitoring, and failure exercises |
| Expansion | Intended for validation, not a commercial capacity commitment | Optimize the single node and resources first | Add nodes to scale access and web capacity horizontally |
| Suitable teams | Learning and prototype teams | Delivery teams with Java/Vue or implementation skills | Teams with explicit capacity targets and cluster operating skills |
Use the Commercial platform overview and license matrix for complete protocol and feature boundaries. No fixed “device limit” is listed because connected devices alone do not define business capacity. Reporting frequency, message size, rule complexity, historical writes, and query patterns all change the result.
3. When Commercial Is the Better Fit
For a typical small or midsize project that needs fast self-hosted delivery, Commercial is a direct starting point when a single node has passed stable connection, throughput, latency, backup, and recovery tests.
Commercial is particularly appropriate when:
- Commercial delivery rights are required: the system will run in an enterprise or customer production environment and needs explicit licensing, contracts, and invoices.
- Source customization is required: business logic, pages, mobile apps, or APIs must change beyond standard SaaS configuration.
- Broader protocols and business features are needed: examples include Modbus, TCP, CoAP, HTTP, multi-tenancy, alerts, reports, data bridging, and OTA.
- Operations staff is limited: the team is not ready to operate multi-node Brokers, Kafka, load balancing, and web clusters, and can first implement sound single-node monitoring and backup.
- Capacity has headroom: CPU, memory, network, disk, and database retain reasonable margins under peak rather than average load.
Commercial does not mean a compromised small-project product. It provides a comparatively simple single-node path for SME delivery. Whether it is sufficient must be established through stable benchmarks and failure exercises on the actual workload.
4. When to Evaluate Cluster
Include Cluster when any of these explicit constraints appears, rather than waiting until a single node reaches its limit:
- Additional access nodes are needed to scale device connections and message concurrency horizontally.
- The web administration and business-request layer also needs multiple nodes and load balancing.
- Maintenance or failure of one node must not cause a prolonged whole-system outage.
- Peak reporting, rule execution, or historical writes are approaching single-node resource limits.
- Expansion windows, service levels, and recovery objectives are defined.
- The team can operate Kafka, FMQ, load balancing, monitoring, and cluster upgrades.
FastBee Cluster Edition builds its scaling path around FMQ service clusters and web clusters. The Cluster documentation covers FMQ deployment, web clustering, load balancing, system optimization, and go-live acceptance. After selecting Cluster, validate session, subscription, message, data, and web-request behavior during node changes; merely starting several services is not acceptance.
5. Do Not Replace a Capacity Model with One Device Count
“We have ten thousand devices” is not enough to select an edition. How many are online? How often does each report? How large is each message? What are the QoS and retention policies? Are there bursts? Do rules call external services? How long is history retained, and how many queries run concurrently?
Start with a simple model:
Average message rate ≈ online devices × reports per device per second.
Then assess startup storms, mass reconnection, simultaneous scheduled tasks, and historical backfill. Peaks often expose connection-pool, thread-pool, disk, and database bottlenecks before averages do.
FastBee publishes Commercial Edition and Cluster Edition benchmark reports that explain test methods and metrics. Their hardware, message sizes, Brokers, clients, and objectives differ. They are not capacity commitments for your project, and dividing two figures does not produce a meaningful performance multiplier.
A project report should include stable connections, sustained throughput, P95/P99 latency, errors and disconnections, CPU, memory, network, disk, database, backlog, and recovery time. Procurement should be based on the gap between these measurements and business objectives.
6. What Licensed Source Enables
Long-term self-hosting cost usually comes from adaptation rather than first installation. Licensed source allows teams to implement requirements beyond the standard product: custom device records, approval and alert flows, ERP/MES integration, mobile and visualization changes, organizational permissions, or internal single sign-on.
FastBee Commercial uses Spring Boot and Vue, which suits teams with Java and frontend skills. Customization should follow three boundaries:
- Prefer configuration, open APIs, and data bridging before modifying core code.
- When core changes are unavoidable, maintain reviewable module boundaries and automated tests so upgrades do not create widespread conflicts.
- Record official versions, patches, private branches, build parameters, and third-party dependencies from day one so builds are repeatable.
Source delivery does not permit resale or redistribution. Licensed users must follow the official terms and must not directly sell or distribute commercial source code. Third-party licenses require separate review.
7. Compare Total Cost, Not Only License Price
Compare Open Source, Commercial, and Cluster over three years rather than looking only at license fees.
| Cost item | What to estimate |
|---|---|
| Licenses and modules | Base edition, optional modules, update subscriptions, third-party licenses |
| Implementation | Device access, protocol adaptation, data cleansing, page and rule configuration, training |
| Customization | Source changes, integrations, testing, builds, version maintenance |
| Infrastructure | Servers, load balancing, storage, backup, bandwidth, monitoring, disaster recovery |
| Operations | Inspection, incident response, security fixes, upgrades, expansion, recovery exercises |
| Risk | Data loss, downtime, delivery delays, learning curves, unclear vendor boundaries |
Commercial can reduce cluster operating costs. Cluster can reduce downtime and scaling risk in large deployments. Open Source has no license fee but still creates implementation, compliance, and maintenance costs. Compare complete solutions that meet the same business objective.
8. An Executable POC Acceptance Matrix
| Stage | Commercial focus | Cluster focus | Shared evidence |
|---|---|---|---|
| Features | Multiple protocols, rules, alerts, multi-tenancy, visualization, optional modules | Confirm business behavior matches the commercial deployment | Real-device and business-loop records |
| Source | Obtain licensed source, build independently, make one small change | Verify cluster-related source and deployment-script boundaries | Private repository, build log, change record |
| Capacity | Remain stable at single-node peak with resource headroom | Load-test multiple nodes and observe capacity and bottlenecks after expansion | Raw scripts, monitoring, latency, error rate |
| Availability | Service and server restarts, backup and restore | Node failures, load-balancer failover, Kafka/storage fault exercises | Fault injection and recovery time |
| Security | Authentication, permissions, certificates, vulnerability fixes, audit logs | Inter-node communication, entry points, internal-component permissions | Test report and remediation |
| Operations | Single-node monitoring, backup, upgrade, rollback | Cluster monitoring, rolling upgrades, expansion, rollback | Runbook and hands-on operator evidence |
Write acceptance thresholds before testing. Do not lower throughput, recovery-time, or data-integrity requirements after seeing the results.
9. Recommended Decision Sequence
- Eliminate non-compliant options: do not estimate a commercial project as zero-cost Open Source.
- Validate features with real devices: protocols, rules, alerts, history, and business flows must pass.
- Validate delivery with licensed source: actually pull, build, modify, and deploy it rather than viewing directory screenshots.
- Benchmark one consistent model: test stable capacity using project message models and peak scenarios.
- Compare availability and operating cost: decide whether a single point of failure is acceptable and whether the team can operate a cluster.
- Preserve an expansion path: even when starting with Commercial, record Cluster triggers, data backup, and migration exercises.
To compare other platforms, read the 2026 China open-source IoT platform comparison. For existing industrial equipment, continue with the industrial IoT platform selection guide for SMEs.
10. FAQ
10.1. Is FastBee Commercial suitable for typical small and midsize projects?
Yes, it is a strong candidate for initial evaluation. It supports commercial self-hosted delivery with multiple protocols, device management, rules, alerts, multi-tenancy, and visualization. Corresponding source is provided through private Git after licensing. Real devices and project loads must still confirm single-node capacity and operational objectives.
10.2. Does Cluster only support more devices?
No. Cluster also addresses horizontal access and web-node expansion, concurrency, load balancing, and high availability. Device and concurrency growth is important, but message flows, data storage, and operations must be accepted together.
10.3. Do Commercial and Cluster both include source code after licensing?
The official license matrix lists private Git updates and first-year source updates for both. Procurement should confirm the exact edition and module source list, repository access, and update period in the contract. Commercial source may not be directly sold or distributed.
10.4. Can we start with Commercial and upgrade to Cluster later?
Yes, Cluster can remain a later expansion path, but capacity metrics, backup and restore, and migration exercises should be planned from the start. Upgrading involves FMQ, Kafka, web clusters, load balancing, and operating procedures rather than merely adding servers. Evaluate before reaching a capacity emergency.