Wondering what the recommended way to handle device specific configuration files is?
For example a device specific license or calibration file that needs to be applied. Looking for a way to apply unique versions to each device that will persist across application upgrades.
Wanting to avoid baking them into the Balena-OS image.
Considering putting them in balena environment variables…
Two ways I can think of doing this are via environment variables, like you indicated, or running different builds for each unique unit, and pinning devices to builds accordingly. Each build would include the necessary files for the device/config/whatever you need
Environment variables are a cleaner approach, but harder to manage, because you can’t easily apply the same environment variables to multiple devices without applying to the entire application fleet. You’d have to apply to each device individually, and/or set overrides.
Separate builds are a little messier, but easier to manage in balenaCloud, because you can select multiple devices and pin them to a specific build all at once.
Another thing you could do, is to have your own service on each device which talks to your own cloud - could be AWS IoT, or something similar - through which you manage your licenses. But this way you’d be adding a bit more complexity to your application.
That would be the logical place. I assume you have found a downside to this, which is why you are asking?
You can manage the variables using the API, if that helps, as well as use a hashed URL stored in a variable which your application could download on boot, for example.
I’m interested in your experiences because I may need similar files in my application.
Something I usually do when deploying Docker or Kubernetes applications in the cloud is to place a skeleton utility in the application that knows its own identity and pulls files or scripts from some place like AWS S3 or GCP Cloud Storage, which provide the necessary info to customize an instance/device and give it its personality/role within the application. We use those services extensively as a central repo for misc application resources.