When to choose EMQX or NATS for edge messaging
Choose EMQX when your edge estate is built around MQTT devices and you need the broker to terminate those connections directly. EMQX supports MQTT 5.0, 3.1.1 and 3.1, MQTT over QUIC, and reaches constrained devices through its MQTT-SN, CoAP and LwM2M gateways. Its SQL-based rule engine and data integration cover more than 50 systems, including Kafka, PostgreSQL, MongoDB and Redis, so device telemetry can flow into your existing back end without a custom bridge. Choose NATS when the edge is mainly a service mesh of components that talk to each other, and devices are few, gateway-mediated or already using NATS clients. NATS with JetStream adds at-least-once delivery, replay from a sequence number or point in time, and a key-value and object store. Its accounts isolate messaging domains inside one cluster, which suits teams separating tenants or business units. Confirm which device protocols your hardware actually speaks before you pick either system.
Three factors usually decide the shortlist. The first is the clustering license. From EMQX 5.9.0, a cluster of more than one node requires a license file, and the Business Source License 1.1 governs the code, so read the grant against your hosting model, especially if you offer the platform to third parties. NATS server is Apache-2.0 licensed under the CNCF, so a multi-node design carries no license file requirement. The second is your device protocol mix. If most endpoints are MQTT or LwM2M, EMQX removes a translation layer. If they are mostly internal services, MQTT is an extra protocol you may not need. The third is in-house skill. NATS has Tier 1 clients for Go, Python, Java, Rust, C# and C, and its JetStream clusters follow Raft majority rules that your operators must understand, including R3 replication as the production floor.
Before committing, run a short proof of concept with your real topology. Measure message loss under a broker restart, failover time on a three-node JetStream cluster and EMQX cluster behavior when a node drops off a constrained network. Ask your EMQX representative to confirm the license terms for your exact deployment, and check your NATS client libraries against the Tier 1 and Tier 2 lists in the NATS documentation. A hybrid pattern is common: devices publish MQTT to EMQX, and EMQX forwards selected streams into NATS or Kafka for internal consumers. Document that bridge as a trust boundary, because each hop needs its own authentication and encryption controls.
Which scenarios favor EMQX and which favor NATS
This table maps common edge and IoT scenarios to the platform that fits better and the condition that makes that choice hold. Read each row as a starting point, then check the license and deployment conditions against your own topology before committing.
| Scenario | Better fit | Condition under which it holds |
|---|---|---|
| Device fleets that publish and subscribe over MQTT with QoS requirements | EMQX | The devices speak MQTT 5.0, 3.1.1 or 3.1 natively, and you need MQTT features such as QoS handling and session behavior without a translation layer. |
| Edge sites on constrained hardware with a small footprint goal | NATS | The nodes run a single small binary with a memory footprint typically around 15 MB, and devices do not need MQTT clients directly. |
| Mixed MQTT devices and internal microservices on one messaging layer | NATS | Services use NATS clients and devices can reach the system through NATS MQTT configuration on the same server process, so you avoid running a separate broker. Confirm MQTT feature coverage against your device requirements. |
| Device data routed into databases and analytics systems with SQL-based filtering | EMQX | You want a built-in SQL rule engine and connectors to systems such as Kafka, PostgreSQL or Redis without writing custom bridge code. |
| Multi-tenant SaaS isolating customers on shared infrastructure | NATS | Accounts isolate messaging domains within one server or cluster, which fits team or customer separation. Confirm that account isolation meets your tenancy and audit requirements. |
| Multi-node production clusters that must run under a permitted license | NATS | You need clustering without a license file requirement, since NATS is under Apache 2.0. EMQX clusters of more than one node require a license file from 5.9.0 onward under the Business Source License. |
| Hosted or embedded offerings to third parties | NATS | EMQX's Business Source License does not permit offering it to third parties on a hosted or embedded basis, while NATS is Apache 2.0 licensed. Have counsel review your distribution model. |
How EMQX and NATS are built and deployed
EMQX and NATS both run as self-hosted messaging layers for edge and IoT, but they package clustering, persistence and protocol support in very different ways. The cards below cover the architecture, node count, licensing gate and upgrade path that follow from those choices.
EMQX as a clustered broker
EMQX is designed as a clustered, masterless MQTT platform, so several nodes share device sessions and routing without a designated leader. Gateways for MQTT-SN, CoAP and LwM2M sit alongside the broker, and the SQL-based rule engine moves data to downstream systems. Confirm how many nodes your fleet needs, because a cluster of more than one node requires a license file from EMQX 5.9.0 onward.
NATS as one server process
NATS ships as a small single binary, and clustering, JetStream, leaf nodes, MQTT and WebSocket are all configuration on that same server process. A single node can serve edge sites with little footprint, and the same binary can be deployed as a leaf node that connects a site back to a central cluster. Check that your team is comfortable operating the configuration surface for each of these features.
Node count and quorum
NATS JetStream clusters use a Raft majority vote, and the NATS documentation recommends an odd number of servers, typically three or five, with R3 replication as the production floor. EMQX clusters are masterless, so the node count decision is driven by connection volume and availability rather than by leader election. Ask each vendor how replicas, quorum loss and rebalancing behave in your topology before you size the fleet.
Upgrades and release cadence
EMQX 6.3.2 was published on October 16, 2026, and nats-server v2.15.1 and v2.14.8 were both published on October 9, 2026. Upgrades in both systems should be rehearsed on a staging cluster that mirrors your node count and persistence settings. Confirm the supported upgrade path between minor lines with each vendor before you commit to a version.
Operations and tenancy model
NATS accounts isolate messaging domains within one server or cluster, which supports team isolation and multi-tenant SaaS layouts without running separate clusters. EMQX separates tenants and access through its authentication and authorization options, including JWT and X.509 certificates. Decide whether isolation must be enforced at the broker or at the platform layer, and test that boundary under load.
Client and protocol coverage
NATS lists Tier 1 clients for Go, JavaScript/TypeScript, Python, Java, Rust, C#/.NET and C, with Zig, Swift, Ruby and Elixir as Tier 2 clients that may lag on new server features. EMQX supports MQTT 5.0, 3.1.1 and 3.1, MQTT over QUIC and MQTT-SN. If your devices speak MQTT natively, confirm the client libraries on your device firmware before choosing a broker that would require a bridge.
Protocols, persistence, tenancy and identity compared
This table compares how EMQX and NATS handle device protocols, persistence, replication, tenancy, client languages and authentication. Read each row against your device fleet and your internal services: EMQX fits when MQTT and its gateways are the center of the design, while NATS fits when one messaging layer must serve devices and back-end services alike.
| Capability | EMQX | NATS with JetStream |
|---|---|---|
| MQTT versions | Supports MQTT 5.0, 3.1.1 and 3.1, so older device firmware can connect without a translation layer. | MQTT is available as a server-side protocol option set in configuration. Confirm the MQTT version coverage in the NATS documentation before relying on it. |
| Transports | Supports MQTT over TLS/SSL, secure WebSocket and MQTT over QUIC. | Supports WebSocket and TLS in configuration. Confirm QUIC support for MQTT clients with the vendor before planning around it. |
| Protocol gateways | Provides gateways for MQTT-SN, CoAP and LwM2M, which matters for constrained sensors and device management tooling. | No equivalent gateways for MQTT-SN, CoAP or LwM2M are listed in the supplied documentation. Confirm with NATS if these protocols are required. |
| Persistence | Persists device data through its data integration layer, which forwards messages to more than 50 systems including Kafka, PostgreSQL and Redis. | JetStream gives at-least-once delivery with streams bound to subjects, stored in memory or on disk, and consumers can replay from a chosen point. |
| Replication limits | Clustering is masterless. Confirm replication settings for your cluster size in the EMQX documentation. | JetStream recommends an odd number of servers, typically three or five. R3 is the production floor, and a stream can have at most five copies. |
| Multi-tenancy | Isolation is handled through authentication and authorization on connections, with options such as username and password, JWT, PSK and X.509 certificates. | NATS accounts isolate messaging domains within one server or cluster, which suits team isolation and SaaS platforms. |
| Client language tiers | Client support depends on the MQTT client library chosen by each device team, so confirm library maturity for your language and hardware. | Tier 1 official clients cover Go, JavaScript/TypeScript, Python, Java, Rust, C#/.NET and C. Zig, Swift, Ruby and Elixir are Tier 2 and may lag on new server features. |
| Authentication methods | Username and password, JWT, PSK and X.509 certificates over TLS/SSL and secure WebSocket connections. | Authentication and accounts are configured on the server. Confirm the exact credential types your device identity model requires. |
What the EMQX Business Source License and NATS Apache-2.0 allow
Starting with version 5.9.0, EMQX merged its former Open Source and Enterprise editions into one offering under the Business Source License 1.1. The license permits production use of a single node, provided the software is not offered to third parties on a hosted or embedded basis. Educational and non-profit users may use it in production without restriction for non-commercial purposes. Each release published under the license converts to Apache 2.0 four years after publication.
- Single-node production: A single EMQX node can run in production under the license terms, subject to the hosted and embedded limits.
- Clusters need a license file: From 5.9.0, running a cluster of more than one node requires loading a license file.
- Hosted and embedded limits: Offering EMQX to third parties as a hosted service, or embedding it in a product you sell, falls under restrictions that legal review must check.
- Four-year conversion: Each release converts to Apache 2.0 four years after its publication date, so the terms of older releases differ from the newest ones.
- Non-profit and education carve-out: Non-commercial educational and non-profit use has no production restriction under the license.
Confirm with EMQX and your counsel which license file your cluster needs, and whether your IoT service model counts as offering the software to third parties.
The NATS server is licensed under the Apache License 2.0, and its repository states that NATS is part of the Cloud Native Computing Foundation. The server is documented to run on premises, in the cloud, at the edge and on a Raspberry Pi. Apache-2.0 permits commercial use, modification and redistribution, and it does not impose a cluster size limit or a license file requirement in the server's own licensing. Read the license file in the release you deploy and confirm your obligations for notices and attribution.
- Permissive license: The server is Apache-2.0, so the license does not contain a node count or hosted-use restriction of the kind found in EMQX's terms.
- CNCF stewardship: NATS is a CNCF project, and the CNCF keeps the NATS.io domain and GitHub repositories.
- 2025 trademark move: On May 1, 2025, CNCF and Synadia announced that Synadia would assign its two NATS trademark registrations to the Linux Foundation, while development continues under Apache-2.0.
- Trademark use still applies: Apache-2.0 covers the code, but using the NATS name in a product or service is governed by trademark rules that your counsel should review.
- Client libraries: Client licenses are separate from the server, so check the license of every client your applications use.
Ask your legal team whether the trademark assignment changes any name usage in your product materials, and confirm the license of each client library you plan to ship.
The question that decides between these two licenses for many IoT vendors is whether the messaging layer is part of a service you sell or a product you ship. EMQX's Business Source License restricts offering the software to third parties on a hosted or embedded basis, while NATS's Apache-2.0 license grants those rights directly. The answer depends on the exact wording of the license and on how your product is packaged, so this is a question for counsel, not a conclusion to draw from a summary.
- Managed IoT service: If you run a broker for customers, ask whether that counts as offering EMQX to third parties on a hosted basis.
- Embedded device or gateway software: If the broker ships inside your hardware or edge software, ask whether that is embedding under the license.
- Internal use only: Use inside your own organization is the scenario the license is least likely to restrict, but confirm it against your deployment.
- Version boundary: Check which release you run, because the license terms depend on the version and its publication date.
- Written answer: Ask counsel for a written opinion tied to your product architecture, not a general reading.
Bring your architecture diagram and planned customer model to counsel before you commit to a broker, because the answer changes the license you need.
Licensing affects how you scale. Under EMQX's terms, the single-node grant covers one node in production, and a multi-node cluster needs a license file. Under NATS's Apache-2.0 license, the server carries no equivalent cluster license file. Clustering in NATS is configuration on the same server process, and JetStream replication is set per stream, so the cost difference lies in licensing and in what your team must operate, not in a separate cluster edition.
- EMQX cluster license: Each multi-node EMQX cluster requires a license file from 5.9.0 onward, so ask EMQX what that file covers and how it is renewed.
- Commercial terms: Ask EMQX for its commercial licensing terms in writing, since the license file is the gate for clusters.
- NATS support: NATS is open source with no license file, but commercial support, if you want it, comes from a separate agreement, so ask who supplies it.
- Operational cost: Your staff time for running clusters, upgrades and monitoring is a recurring cost on both sides, and it does not depend on the license.
- Quote scope: Ask for the license cost, support scope and renewal terms as separate line items.
Get both license terms in writing before you size a cluster, because the license file is the cost gate for EMQX.
What drives the running cost of each messaging stack
This table breaks down the cost components of running EMQX and NATS, showing who is paid for each item, whether it is one-time or recurring, and what drives it up or down. Use it to write a quote request that compares both stacks on the same terms, since licensing and operator skills often matter more than server count.
| Cost component | EMQX | NATS with JetStream |
|---|---|---|
| Licence for production clusters | From 5.9.0, a cluster of more than one node requires loading a license file under the Business Source License 1.1. Single-node production use is permitted under the license terms, but hosted or embedded offering to third parties is not. Confirm the terms with EMQX for your use. | The server is Apache-2.0 licensed and is part of the CNCF, so there is no licence fee for clustering. Confirm with the NATS project or a commercial support provider whether any paid support is needed for your organization. |
| Infrastructure per cluster | Cluster sizing depends on connection count, message rate and rule engine load. Ask for the recommended node count and resource profile for your device profile in the quote. | The server has a small footprint, with typical memory use around 15 MB per the NATS documentation. JetStream needs R3 replication for production, so plan for at least three servers per replicated stream group. Ask for a sizing estimate based on your message retention. |
| Operator skills | Operators need MQTT behavior, authentication setup (JWT, X.509, PSK), and rule engine configuration. Budget for training time on the EMQX specific features you will use. | Operators need subject design, JetStream stream and consumer configuration, and Raft cluster operations. Most teams find the mental model smaller, but JetStream tuning still requires dedicated time. |
| Data integration and bridges | The rule engine and data integrations cover more than 50 systems. Each connector you run adds configuration and testing effort, and sometimes third-party licensing for the target system. | NATS documents bridges to Kafka, JMS, Spark and Flink. Each bridge is a separate component you must build, host, and maintain, so count those effort hours in the quote. |
| Monitoring and upgrades | Confirm how EMQX exposes metrics to your existing monitoring stack and how rolling upgrades of a licensed cluster are handled. Plan for a regular upgrade window tied to your release cadence. | The NATS Prometheus exporter and the NACK and Helm charts for Kubernetes reduce custom tooling. Ask for the chart version you will pin, and budget for regular upgrades of the server and charts. |
| Support and vendor options | Ask EMQX for its commercial support tiers and what they include beyond the license file. Support is typically recurring annually, so confirm the term and renewal rules. | Support depends on whether you use the open project alone or a commercial provider. Ask any provider for response commitments in writing, since open-source support is usually not contractually defined. |
| One-time versus recurring | One-time: architecture, integration build, rule engine design, initial licence procurement. Recurring: licence renewals, infrastructure, upgrades, support and staff time. | One-time: subject design, JetStream topology, Helm and monitoring setup. Recurring: infrastructure, chart and server upgrades, support, and staff time. |
Moving device traffic from EMQX to NATS or back
This sequence gives an engineering team a tested path to move device traffic between EMQX and NATS one device group at a time, keeping topic design and payload schemas while rebuilding authentication, rules and session behavior on the new side.
Inventory topics, QoS and retained use
The platform team exports the current EMQX topic tree, the QoS level each device class uses, which topics rely on retained messages, and which clients depend on persistent sessions. Device firmware owners confirm the payload schema for each topic family. The step closes when every topic has an owner, a QoS value, a retained or non-retained flag and a schema reference in one inventory document, reviewed by both the platform and firmware teams.
Map MQTT topics to NATS subjects
Architects translate each MQTT topic filter into a NATS subject hierarchy, noting where MQTT single-level and multi-level wildcards map to NATS token wildcards and where a mapping is ambiguous. Topic design and payload schemas carry over unchanged in intent, so the mapping document records the subject for each topic family and any name changes. The step closes when a reviewer can trace every existing topic to exactly one subject and every subject to a documented owner.
Decide the bridge pattern
The team chooses whether NATS sits beside EMQX during migration, with a bridge carrying messages in one or both directions, or whether devices move without a bridge once they are cut over. The NATS documentation lists bridges to Kafka, JMS, Spark and Flink, and the team must confirm with its own engineers whether an MQTT bridge fits its topology, since the supplied facts do not describe a direct EMQX-to-NATS connector. The step closes with a written pattern, its failure behavior and the direction of traffic for each device class.
Rebuild rules as NATS consumers
EMQX rule engine SQL statements that route, filter or transform messages are rewritten as NATS consumers or stream subscribers that perform the same work. Authentication is also rebuilt, because EMQX username and password, JWT, PSK and X.509 settings do not move into NATS configuration automatically; the team defines NATS accounts, users and credentials for each device group. The step closes when each rule has a named consumer, each credential path is tested with a sample device, and the rule owner signs off on output equivalence.
Run dual publish with comparison
Devices or a gateway publish to both brokers for a defined test group, and the receiving services compare message counts, ordering, payload contents and retained-state results. Session state is not carried across, so the team checks how clients behave after reconnect, including any reliance on EMQX persistent sessions and retained messages, which must be rebuilt through JetStream streams or application logic. The step closes when the comparison shows no unexplained gaps for the test group over a period the team sets, and the discrepancies are documented.
Cut over device by device
The team moves one device group at a time by changing the broker endpoint, credentials and topic prefix in device configuration, starting with the least critical group. Each cutover is followed by monitoring of connection counts, delivery behavior and downstream consumer lag. The step closes for each group when the devices report stable connections, the downstream systems receive expected traffic, and the rollback path has been tested and recorded.
Decommission and confirm licensing position
After the last device group moves, the team retires the EMQX rules, retained messages and cluster configuration that are no longer used, and confirms what the EMQX license terms required for the deployment during the overlap period. Teams moving back from NATS to EMQX repeat the same mapping in reverse. The step closes when no devices connect to the retired broker, the license obligations for the period are recorded, and the final topic inventory matches the NATS subject map.
Where EMQX and NATS projects usually run long
EMQX projects tend to slow down at licensing and cluster design. From EMQX 5.9.0, a cluster of more than one node requires a license file, so procurement needs to happen before the cluster is sized, not after. Confirm with EMQX which license terms apply to your deployment model, including whether a single production node or a hosted offering changes the answer. Then design the rule engine and data integrations (Kafka, PostgreSQL, Redis and others) as a written inventory of SQL rules, target resources and failure handling, because rules scattered across the console become hard to review. Device authentication is the other common delay. Choosing between username and password, JWT, PSK and X.509 changes certificate lifecycle work, so decide early who issues device certificates, how revocation is handled and which identity source supplies JWT claims.
NATS projects tend to slow down at JetStream design and client choices. Each stream binds to subjects and stores messages in memory or on disk, so retention, replication and consumer replay policies need to be set per workload before anything goes live. The NATS documentation recommends R3 replication as the production floor on an odd-sized Raspberry-class or server cluster, which means planning node count and storage per site, not just per platform. Account setup is where multi-tenant isolation is either correct or quietly wrong, so map teams and device fleets to accounts and test that one tenant cannot see another's subjects. Client language is the last check. Go, JavaScript/TypeScript, Python, Java, Rust, C#/.NET and C are Tier 1, while Zig, Swift, Ruby and Elixir are Tier 2 and may lag on new server features, so confirm every device and back-end language against that list before committing.
Questions buyers ask before choosing EMQX or NATS
Does a single EMQX node need a license for production use?
No license file is needed for one node in production, but the Business Source License still applies. The EMQX license allows production use of a single node, provided you do not offer EMQX to third parties on a hosted or embedded basis. It also permits unrestricted production use by educational and non-profit users for non-commercial purposes. If you run EMQX inside a product you sell or as a managed service for customers, have counsel confirm the terms against your model before you deploy. Ask EMQX to confirm how the grant applies to your deployment.
When does an EMQX cluster need a license file?
From version 5.9.0, a cluster of more than one node requires a license file. Clustering is masterless and is central to high availability, so a three-node cluster for resilience (illustrative) would need one. Each EMQX release published under the Business Source License converts to Apache 2.0 four years after publication, which changes the terms for older releases over time. Ask EMQX for the license tiers, what each one covers and how node counts are measured, because the cost of a cluster license recurs and should appear in your total cost comparison next to NATS, which is Apache-2.0 licensed with no node-based license file.
Can NATS serve MQTT devices directly?
NATS documents MQTT as a configuration option on the same server process that handles clustering, JetStream, leaf nodes and WebSocket, so it can accept MQTT clients. Whether it covers your devices is a separate question. EMQX supports MQTT 5.0, 3.1.1 and 3.1, MQTT over QUIC, and MQTT-SN, CoAP and LwM2M through gateways. Confirm which MQTT features your fleet depends on, including QoS levels, retained messages, will messages, persistent sessions and the authentication methods your firmware uses. Test those against your device firmware in a lab before you commit, since the features you need decide whether NATS can replace the broker at the device edge.
How much effort does migrating from EMQX to NATS take?
Effort depends on how much of your logic lives inside EMQX. The main drivers are the number of device topics and subject hierarchies you need to map, the SQL rules in the EMQX rule engine that must be rewritten as subscriber code or stream configuration, and the authentication model, since EMQX uses username and password, JWT, PSK and X.509 certificates. Count your data integrations too, because EMQX lists more than 50 connectors while NATS documents bridges to Kafka, JMS, Spark and Flink. Ask for an inventory of topics, rules, connectors and firmware changes, and plan a parallel run before any device cutover.
What skills does the internal team need to run either broker?
Both brokers need engineers who understand TLS, certificate lifecycles and network segmentation, plus monitoring and capacity planning. EMQX adds broker tuning, cluster management, rule engine maintenance and license administration. NATS adds subject design, JetStream stream and consumer configuration, and an understanding of Raft quorum, which requires an odd number of servers, typically three or five, with R3 replication as the documented production floor. Teams new to NATS should plan time for subject taxonomy and replay semantics, which differ from MQTT topic handling. Map these skills against the people you have before you choose.
Can our own team run EMQX or NATS without outside help?
Many teams can, provided they have operations capacity for patching, backups, monitoring, upgrades and on-call response for a platform inside their own infrastructure. NATS has a Prometheus exporter, Helm charts for Kubernetes and an Apache-2.0 license under the Cloud Native Computing Foundation, which simplifies adoption. EMQX offers a broader rule engine and more device protocols out of the box, but a cluster needs a license file. Decide who owns each recurring task, how upgrades are tested, and who responds at night. If those owners do not exist yet, an outside partner can cover part of the work.
What does a DeployOpen engagement cover for EMQX or NATS?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a broker project, that can include architecture, cluster setup, device authentication, data integration and runbooks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports, attestations or certifications.
How is the cost of a DeployOpen quote for this work set?
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that matter are the device count and protocols, the number of topics and rules, the integrations to build, the authentication model, the environments to harden and the support level you need. One-time costs include planning, implementation, migration and testing. Recurring costs include retainers for support and upgrades, your own infrastructure, and any EMQX license for clusters. Ask for line items that separate one-time work from recurring support, and state which licenses you will buy directly.
How DeployOpen helps choose and implement a messaging platform
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For EMQX vs NATS, that starts with agreeing which messaging model your devices and services actually need before any installation begins.
How we scope
- Written scope lists device protocols, client counts, QoS needs and which gateways are in play, such as MQTT-SN, CoAP or LwM2M.
- Scope records whether clustering is planned, so the EMQX license file requirement for more than one node is priced into the decision.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Build a proof environment for the chosen broker, testing MQTT session behavior, retained messages and rule engine or JetStream persistence against your workloads.
- Configure authentication, such as X.509 certificates or JWT for EMQX, or NATS accounts and permissions, matched to your tenancy model.
- Connect downstream systems through the rule engine, the NATS bridges or your existing Kafka and database pipelines, then test failover in your topology.
How we hand over
- Deliver architecture notes, cluster topology, configuration baselines and runbooks covering upgrades, certificate rotation and backup of persistent streams.
- Document the license position in writing, including the Business Source License terms for EMQX or the Apache-2.0 terms for NATS, for your legal review.
- Run knowledge transfer sessions with your operations and security staff so your team can run the platform after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, covering version changes in your environment.
- Retainers can include periodic security testing of brokers, authentication paths and exposed device gateways.
- Confirm with your procurement team which support terms, and which vendor editions, you need before the retainer is signed.
