The example files are put in place by Terraform, so they will get overwritten next time `terraform apply` is run. You can of course change the example flag files as you're kicking the tires or testing out your app, but to really use the system you'll want to create new flags as documented here: https://github.com/dorklyorg/dorkly/wiki/3.-Common-Tasks#add...
These new flags won't be managed by Terraform thus won't get reset to the default values.
It's worth noting that there is no architectural limitation preventing an HA topology: multiple Dorkly servers can be deployed behind one or more load balancers for HA + lower latency where it matters (ie web and mobile apps).
If this is a limitation for anyone I'm happy to work with you on modifying the terraform module to support HA.
The PR is optional, but governance often requires documented peer approval for all production changes.
Flag changes can be pushed directly to the main branch with the correct repo permissions. When using the GitHub UI this involves just a little bit of typing and a few clicks.
>might as well just change the code at that point
If changing the code, running tests, building, and deploying is quicker and less risky then yes that makes more sense.
I have mostly seen developers in charge of changing flags, but there is also great value in empowering other roles to change flags (One example: sales people can unlock features as they sell them).
Thankfully GitHub has an easy web-based Pull Request process. It's not as simple as a custom UI, but could be used by non-engineers to change flags.
LaunchDarkly - ONSITE in Oakland, California.
Not currently hiring remotes workers
Unable to sponsor visas at the moment.
Posting as an engineer who has been working here one year. This is a fantastic team and product. The business is very healthy- not just good growth, but very satisfied customers who are sticking around.