Just joined and am trying to gain an understanding...
# announcements
e
Just joined and am trying to gain an understanding of the self-hosted option so that I can advise my boss on whether this is a good solution for us (only been on the job for two-and-a-half weeks, so don't want to screw up). In particular I am trying to get my mind around feature flags and what is the environment to get them to work. Running it locally seems pretty straightforward, as everything runs in a docker container and presumably I just need to have one of these in my local docker environment. Things get a little murkier when I think about how this would work in our qa environment and then again in our production environment. Ours is a web app running in the cloud. So would we then need to have a docker container also running in our qa cloud environment and our production environment? And would the feature-flag-enabled application interact with these at run-time? Or is it somehow possible to put all feature-flag information in a configuration file of some kind that the application could consult to know how to manage the features? Please excuse my ignorance, but I really just started looking at this this morning and am trying to get an overview as quickly as possible. Thanks much.
f
Hi
So you wouldn’t need multiple instances of GrowthBook, just the one. Inside GrowthBook you can set environments, which allows you to customize the features per those environments. So you can enable a feature for QA first, and then roll it out as an A/B test on production (or whatever you want).
each environment has its own SDK endpoint, so it will only pull the rules for that environment
e
Thank you, Graham. But if I am setting up GrowthBook in my local Docker Desktop, how is the qa enviornment going to reach that one instance of GrowthBook? Or is it not needed at Application runtime? What I was sort of imagining would be useful is having the full GrowthBook set up locally in my Docker desktop and then any rules that are defined for feature flags are actually persisted in objects that are part of my git push. So wherever I push code to will be self sufficent and the fetaure flag mechanism will just work through executing my code (no need for further interaction with whatever was running inside of Docker). Is this how it works?
f
you can cache the results of the features, but you should either set up GrowthBook in an accessible place where QA or whatever environment can reach, or use the Proxy server in a it’s place, and connect to it via your laptop or whatever - GrowthBook works best when running on your own infrastructure or using our Cloud (laptops are great for testing or for just doing experimentation analysis)
e
Okay Great. Thanks for the clarification. So just to make sure I am understanding what you are saying, the application will be communicating with GrowthBook as it is executing and will need the GrowthBook server to provide feature flag info dynamically. Thus we need to set up GrowthBook in our QA environment as well as on my local laptop. And in production, I presume, as well? THis is a correct understanding? (Sorry, just have to be sure. Stakes are high for me.)
f
you could put 1 GrowthBook instance accessible to both QA and Production. (have two instances would be confusing). This instance could be just our Proxy server if for some reason you didn’t want to run the full GrowthBook platform there, and you could run the platform from where ever you like and connect to the proxy. It is recommended for simplicity to host GrowthBook more permanently (like in AWS) for production deployments using our feature flags