Is there a proper mechanism for seeding a new open-balena instance with orgs, users, api-keys, fleets, and fleet-wide config/env variables? For our local machine test environment we'd like to always seed open-balena with the exact same details, and for dev/prod environments we'd like to automate as much as possible (rather than having human driven run-book actions).

Things I've tried:

• balena CLI
  • no ability to create orgs
  • no ability to create users
  • no ability to specify a pre-created api-key when creating api-keys
• open-balena-api migration scripts
  • not run on a clean (new) environment
• extending https://github.com/balena-io/open-balena-api/blob/master/src/balena-init.sql and injecting the new one in through a volume mount in docker-compose
  • causes a bit of mayhem with foreign keys and SEQUENCES ... can probably be fixed, but just feels dirty
• extending https://github.com/balena-io/open-balena-api/blob/master/config.ts to add a customServerCode entry (also injected via a volume mount in docker-compose)
  • pinejs isn't clear whether this runs before or after all the route setup functions are called and looking through https://github.com/balena-io/open-balena-api/blob/master/init.ts I'm still not really clear
• Could replace all unit tests with a single postInit test via docker-compose volume mount that does the initialization ... but, again, feels dirty
• could replace https://github.com/balena-io/open-balena-api/blob/master/entry.sh via volume mount to spawn a second process that waits for /ping to return OK and then makes a bunch of curl calls to localhost to set things up?

Really what I'm looking for is something like migrations that is guaranteed to run once on any new API cluster (uninitialized DB)... and none of the above seem like "the right way".