I noticed that OpenBalena has containers for a database and s3 server.
For one of my applications, we manage our own file upload server for device data and CMS for storing device metadata, but if open-balena already provides scaffolding to perform those tasks, it’d be great to reduce redundancy in the system. Are the open-balena database and s3 servers intended for application use? or are they just meant to be used internally?
And is it feasible to associate custom information with a deployment? (things like name, location, pics, deployment stage, date deployed, etc.)
Hi @bea.steers – thanks for your question. The database and S3 servers are intended strictly for openBalena use, and we don’t support using them for other things. It’s best to treat the entire set of containers as a single unit.
As for the custom information – this sounds a lot like release tagging. Can you have a look at our Fleet Management Masterclass and let me know if this matches what you’re after?
Release tagging seems like a nice feature! and probably covers some of the cases that we use (deployment stage, etc.) but we still have things like location, deployment images, general notes about the deployment, that don’t quite fit into the definition of “tags”.
I think I’m just trying to work around the issue of having two databases of devices (balena and our own) and having to keep them in sync. Does open-balena have any sort of webhooks/callback interface that would be able to notify another service that a device was registered or tagged?
Have you considered having your internal database reference Balena devices as a pseudo-foreign-key? In your internal screens, you could use the Balena API to retrieve information about devices “owned” by the current record (I’m guessing you have some form of object that would be appropriate in this case.)