> I would hash some data to generate the

id

and ensure that I don't create twice the same resource (I think I was kind of abusing the API in that sense). I don't think our REST API ever let set the

id

directly, but maybe you were hitting the internal API endpoints directly, or maybe the yaml file allowed you to specify an

id

? > This means that I need to pull the "state" from the endpoint (e.g. the current list of projects), do the diff with the config in git and then adjust my call depending on whether I need to delete, create or update the items to reflect my new "state" (I'm basically creating a poor man's version of terraform to manage my configs). I agree that currently you have to check against what is already in the database and get the ID for the matching property (relying on names, probably for your own purposes) and then updating it rather than recreating it. Let me ask someone more familiar with this kind of system to chime in.

Hey Adrien, I had some general questions about your use-case that could be helpful for us to give the right recommendation: Could you say a little bit more about the motivation behind an IaC setup for your GrowthBook config? Are you needing to manage/provision many instances? Roll back configuration to previous points in time? Simply provide visibility into what the configuration is? What's the main use case you have in mind? When you say "redeploy", do you mean overwriting an existing instance or provisioning a new, separate instance? If the latter, will the two instances live in parallel or does the old instance get spun down after the new one is provisioned? Would creating the initial setup (metrics, settings, etc) in the dashboard's UI fit into your workflow? I.e. if you configured everything you needed manually one time, then were able to re-use that configuration, would that address your use-case or are you specifically trying to avoid any front-end configuration?

Many thanks to you both for your reply. @helpful-application-7107 I am indeed getting inspiration from this tutorial with github. I added my twist to maintain the code with Py objects instead of a YAML to avoid to have a very long file and to run some validation before pushing. @nutritious-easter-80486 At the moment I mostly use the experience analysis feature. In my setup of Growthbook, I have different deployment for testing purpose (preprod & prod) and localisation (Europe & North America). I want to keep a tight control over the db connections and the metrics definitions and manage these via git and a clean release process. The process I am developing is along the lines of:

add new definition & local test -> submit MR -> merge & deploy to preprod -> final QA -> release & deploy to prod

. This way I can audit and validate the creation and modification of metrics and ensure "stability" of prod (preprod would also be used to check upgrades of Growthbook). Another side effect that I appreciate is that I can ensure naming conventions, auto tagging/projects. I hope it clarifies my case which I know is quite convoluted 😅 PS: I'm hoping to be able to open source this project in case other folks are interested

Okay, I understand better now, thank you. It does seem like the other options we have available currently wouldn't fit your use-case (and aren't very well standardized anyway, e.g. dumping the mongo db and using that as a source of truth for your deployments). Looks like a terraform type setup is what's best for your case so you're on the right track for managing those. I'll put a terraform integration on our radar and see if there's appetite to take it on as a project anytime soon. That would be the best solution for what you're looking to do, but I can't speak to how long it might be until we have a chance to make one. In the meantime, your homebrew solution should work fine as long as you can work around not having an

id

field to create directly. I don't have a ton of guidance to add right now, it seems like it'll be a case of finding other fields per object type that you can use to ensure uniqueness. I'm personally not familiar enough with our metric related objects to have any easy answers to that initial question of yours, but I can agree that overall it seems like a reasonable approach to me.

@helpful-application-7107, I just realised that actually it is the bulk endpoint that has a special behaviour where you need to provide an

id

and pass the object as

data

. The other endpoints related to FactTable/FactMetrics/etc. are actually more classical if one can say

I noticed this myself when using the bulk endpoint myself! It might be easiest to build a system where you use that bulk endpoint in conjunction with our other APIs. That's what I'm doing for one of our own needs.