Hi all,
I’m looking for a way to manage devices that are deployed at various client sites. What is the best way to keep client devices (and configs, data) separated from each other? Should I manage this in metadata on the devices, or is there a more native capability?
I’ve also considered creating separate resin.io accounts per client, but then I don’t seem to be able to reuse applications across those account.
Any input is appreciated!
Regards,
Tom.
Hi, what sort of configs and data are you trying to store? By default devices don’t know about each other at all, and don’t share any information, they just share the deployed application, ie. the same code is deployed across all devices within an application (that’s one “fleet” 
).
If you want to completely separate clients, you could use a separate application for each. But if you are just trying to avoid data from one site to show up in another, that already that way.
Can you give us a bit more info on what do you mean in practice by keep client devices (and configs, data) separated from each other ? What exactly are you trying to separate (with some example) and what access do you give to your separate clients on resin.io?
Consider a new website that allows clients to manage their on-site devices. Under the hood, this website uses resin APIs to implement the management functions.
If client A comes to the website, I need to display his devices, which are a subset of the total fleet I’m managing. Do I use metadata on the devices to figure out which devices belong to client A? Or are there more native ways to create groups of devices, with different access policies?
The configuration of the application on the devices might also be customized on a per-Client basis. So 2 devices for client A might have one config, 3 devices for client B might have another config. I can differentiate config based on the aforementoned metadata, but am interested in more native ways.
Hope this clarifies.
Yeah, it does clarify, cheers! 
I think at this point resin.io assumes that a single “fleet” is under a single access, thus if you have access to one device, then you’d have access to all in the same application. Thus technically, if you keep one application for all the devices, the client separation is indeed needed to be done in your overlay system/database - for example keeping lists of UUIDs associated with the different users, and create access control for your clients based on that.
A bit more complex setup would probably be creating a separate application for each customer. That way you can have finer control over the devices as well, and they are more “firewalled” between each other as well. In that case IMHO you would still need to use your own system/database, while e.g. associating the application ID with the specific customer.
But that’s all on your side, each device has it’s own set of environment variables and you could apply configuration to each device as you see it fit. To automate that, maybe keeping track of the device UUIDs for each customer and using the API to update env vars would enable you to have sufficient separation whether it’s one application or one-application-per-customer approach you take.
If you are not giving access to your clients on resin.io directly, but always through your site/service, then you have a lot of leeway regarding how to manage your applications, devices, and associated data.
Is this any help?
Yep, thanks for the insight. It confirms my current thinking. I’ll consider the suggestion of one app per client… might indeed add some additional separation.
Would be very happy to know how it goes, and if you have any feedback for us based on your experience!