An IoT integrator or reseller managing multiple separate clients doesn’t need separate infrastructure per client. ThingsBoard’s built-in tenant and customer hierarchy lets one self-hosted VPS run every client’s devices, dashboards and data with genuine isolation between them, each client seeing only their own equipment, while the integrator retains full administrative visibility across all of them from a single platform.
The problem multi-client integrators actually face
An integrator deploying IoT solutions for multiple separate clients, a solar installer monitoring different customers’ systems, a building services company managing several clients’ BMS data, a reseller offering IoT monitoring as a value-add, faces a genuine architectural choice most single-deployment guides on this site don’t address directly: separate infrastructure per client, expensive and operationally heavy to maintain at scale, or one shared platform with real isolation between clients, which is exactly what ThingsBoard’s multi-tenant architecture was built for.
ThingsBoard’s tenant and customer hierarchy, explained
This builds directly on ThingsBoard Self-Hosted: Complete VPS Setup Guide and ThingsBoard VPS Sizing & Hosting Requirements, applying a specific feature of ThingsBoard’s data model that single-client deployments often never need to touch: a tenant administrator account, the integrator’s own top-level access, can create separate Customer entities within ThingsBoard, one per actual client. Devices, dashboards and assets are assigned to a specific customer, and customer-level users see only what’s assigned to their own customer record, genuinely unable to see another client’s devices or data, while the tenant administrator retains visibility across every customer simultaneously.
What this actually looks like in practice
- The integrator’s own login sees every client’s devices and dashboards, useful for support, troubleshooting and cross-client oversight.
- Each client’s login sees only their own devices, their own dashboard, branded and scoped to their installation alone, with no visibility into any other client sharing the same underlying ThingsBoard instance.
- Dashboards can be customised per customer, ThingsBoard supports assigning specific dashboard configurations to specific customers, so each client’s view can be tailored to their actual equipment and priorities rather than a generic one-size-fits-all layout.
White-labelling considerations
For integrators wanting each client’s experience to feel like their own dedicated platform rather than visibly shared infrastructure, ThingsBoard supports white-labelling at the customer level, custom logos, colour schemes and, on some configurations, custom domains per customer. This is worth setting up deliberately if client perception matters commercially, since the underlying shared infrastructure is otherwise invisible to clients by design, but the visual presentation still benefits from looking genuinely bespoke rather than obviously templated.
Sizing for a genuinely multi-client deployment
The sizing table in ThingsBoard VPS Sizing & Hosting Requirements applies directly here, with total device count summed across every client, not per client individually, since they’re all sharing the same underlying ThingsBoard instance and database. An integrator with ten clients each running 20 devices is sizing for 200 devices total, not treating each client as an independent small deployment.
Combining this with the multi-site aggregation pattern
For integrators whose clients themselves operate multiple sites, a facilities company managing several buildings for one client, for example, this multi-tenant pattern combines naturally with Multi-Site Industrial IoT Data Aggregation: ThingsBoard’s customer hierarchy handles client-level isolation, while each client’s own multiple sites are organised within their customer scope using the same consistent naming and asset-organisation discipline covered in that guide.
Billing and commercial considerations, briefly
Worth noting, though outside this guide’s technical scope: a shared multi-tenant platform like this is also the natural foundation for offering IoT monitoring as a recurring service to clients, since ThingsBoard’s customer structure maps cleanly onto a per-client billing relationship, each client’s device count and usage are already segmented and visible to the integrator for invoicing purposes, without needing a separate system to track this.
Where the ThingsBoard affiliate fits
For an integrator’s business genuinely outgrowing what makes sense to self-host and maintain directly, perhaps managing this infrastructure isn’t core to the business itself, ThingsBoard’s managed cloud offering supports the same tenant and customer hierarchy without the integrator needing to own the underlying VPS and database administration, worth comparing against the self-hosted total cost of ownership at your specific client count.
Frequently asked questions
Can a client accidentally see another client’s data through a misconfiguration?
ThingsBoard’s customer-scoping is enforced at the platform level, not just hidden in the interface, meaning a properly configured customer account genuinely cannot query another customer’s devices via the API either, not just the dashboard. Care during initial customer and device assignment is still worth double-checking, since the isolation depends on devices being correctly assigned to the right customer in the first place.
How many clients can realistically run on one VPS before needing to split infrastructure?
This follows the same device-count-driven sizing covered in the ThingsBoard sizing guide, dozens of clients with modest device counts each comfortably fit the same sizing tiers as a single larger deployment, since ThingsBoard doesn’t meaningfully care whether 500 devices belong to one client or fifty.
Can each client have multiple users with different permission levels?
Yes, ThingsBoard supports multiple users per customer, useful for a client with several staff needing dashboard access, with role-based permissions available within that customer’s scope for finer control over who can do what.
Is this approach suitable for a reseller who didn’t build the underlying devices or sensors themselves?
Yes, ThingsBoard’s device integration doesn’t care about device origin, any MQTT or Modbus-speaking hardware, regardless of manufacturer, integrates the same way covered throughout this site’s other guides, making this a viable platform for a reseller assembling solutions from third-party hardware.
Does adding a new client require any infrastructure changes, or just configuration within ThingsBoard?
Purely configuration in the normal case, creating a new customer record and assigning devices and dashboards to it, no infrastructure change needed unless the new client’s device count pushes the total past the current VPS tier’s comfortable capacity.
Can clients export their own data if they eventually want to leave the platform?
Yes, ThingsBoard supports data export at the customer level, worth knowing as a genuine point in favour of this approach commercially, since being able to offer clients honest data portability, rather than locking them in, is generally a stronger trust position for an integrator’s business relationship than the alternative.
A realistic growth path for an integrator adopting this pattern
Most integrators don’t start with this architecture fully built out, they grow into it. A common, sensible path: build a single-tenant ThingsBoard deployment for the first client, following the standard setup guide directly, then introduce the customer hierarchy covered in this guide the moment a second client signs on, migrating the first client into a proper customer record rather than continuing to treat the deployment as single-purpose. Retrofitting multi-tenancy onto an already-running single-client ThingsBoard instance is straightforward, since the customer structure is a native part of ThingsBoard’s data model, not a separate add-on requiring a different platform entirely.
What this looks like for backup and disaster recovery specifically
Worth connecting directly to Backup Strategies for Self-Hosted IoT Infrastructure: a multi-tenant deployment concentrates more business risk into a single VPS than a single-client setup would, since a serious failure now affects every client simultaneously rather than just one. This makes the layered backup approach covered in that guide, not merely VPS provider snapshots alone, a genuinely more pressing priority for a multi-tenant integrator deployment than for a smaller single-deployment project, worth treating as non-negotiable infrastructure rather than an optional extra once real client businesses depend on the platform staying available.
Frequently asked questions
Can a client accidentally see another client’s data through a misconfiguration?
ThingsBoard’s customer-scoping is enforced at the platform level, not just hidden in the interface, meaning a properly configured customer account genuinely cannot query another customer’s devices via the API either. Care during initial customer and device assignment is still worth double-checking, since the isolation depends on devices being correctly assigned to the right customer in the first place.
How many clients can realistically run on one VPS?
This follows the device-count-driven sizing in the ThingsBoard sizing guide, summed across every client. An integrator with ten clients each running 20 devices is sizing for 200 devices total, not treating each client as an independent small deployment.
Can each client have multiple users with different permission levels?
Yes, ThingsBoard supports multiple users per customer, useful for a client with several staff needing dashboard access, with role-based permissions available within that customer’s scope.
Does adding a new client require infrastructure changes or just configuration?
Purely configuration in the normal case, creating a new customer record and assigning devices and dashboards to it. No infrastructure change needed unless the new client’s device count pushes the total past the current VPS tier’s comfortable capacity.
Can clients export their own data if they want to leave the platform?
Yes, ThingsBoard supports data export at the customer level. Being able to offer clients honest data portability is generally a stronger trust position for an integrator’s business relationship than locking them in.
Dashboard templates and white-labelling in practice
ThingsBoard’s dashboard sharing model lets the integrator build a template dashboard once and assign it to multiple customers with a single configuration operation. The template displays each customer’s own devices automatically through ThingsBoard’s entity alias system, which resolves “all devices belonging to the current customer” dynamically at render time rather than being hardcoded to specific device IDs. This means building one well-designed dashboard template, getting the layout and panels right once, and deploying it across all clients as a consistent, branded experience without rebuilding it per client. The white-labelling layer, custom logos and colours configurable per customer, sits on top of this, so while the underlying dashboard structure is shared, each client’s visual experience can feel genuinely tailored to their own brand.
GDPR and multi-tenancy
Running multiple clients’ data on shared infrastructure raises a data protection question worth addressing directly, covered in more depth in UK GDPR and IoT Data: as the integrator, you are typically the data processor for each client’s data, with each client being the data controller for their own devices and telemetry. This controller/processor relationship should be documented in a data processing agreement with each client. ThingsBoard’s customer isolation, where properly configured, provides the technical segregation that supports this arrangement, but the legal documentation sits alongside it, not inside it. For integrators managing business clients rather than consumers, this is worth addressing at the point of first engagement rather than retrofitting later.
Pricing and billing architecture for integrators
One practical advantage of the customer hierarchy covered in this guide: ThingsBoard’s data model already segments usage by customer, meaning the per-client device count and data volume are directly visible in the admin interface without needing a separate tracking system. For an integrator offering IoT monitoring as a monthly service and billing clients based on device count or data volume, this visibility is built into the platform structure they’re already using, rather than being something to instrument separately. Whether that maps to per-device pricing, a flat per-site fee, or a tiered service model depends on the integrator’s commercial approach, but the data needed to support any of these billing models is readily available from ThingsBoard’s own admin views.
When to graduate to ThingsBoard Professional Edition
ThingsBoard Community Edition, the version covered throughout this site’s self-hosting guides, is entirely free and covers everything described in this guide including the full multi-tenant customer hierarchy. ThingsBoard Professional Edition adds advanced rule chains, white-labelling features that go beyond what Community Edition supports, and enhanced reporting tools. For an integrator whose business grows to the point where those specific additions earn their licence cost, the migration path from Community to Professional is documented and supported. Starting with Community Edition, which is what most projects on this site use, is the right default; moving to Professional is an option when genuinely needed rather than a prerequisite. The migration path from Community to Professional Edition is well-documented and supported by the ThingsBoard team when the time comes, and retaining all existing data and configuration throughout the transition. There is no practical reason to start with Professional Edition when Community Edition covers the full multi-tenancy use case this guide describes.