Overview
Generally speaking there are two major ways to add configuration for use in Beach:
- through environment variables and setting them as instance variables
- through settings files checked in with the code
Both approaches can of course be combined as you need.
Using environment variables
When you have something that you need to configure per instance or do not want to check in with the code into your VCS (e.g. credentials for something), you can define an instance variable and read that in your settings file from an environment variable.
Here is an example, where the settings file uses a variable named API_KEY that is set as an instance variable:
AcmeCom:
ApiIntegration:
accessKey: '%env:API_KEY%'
Using settings files
Of course you can check in configuration files with your code. The only thing you need to keep in mind: Beach itself provides some default settings (for the database) in a file that is automatically generated when building your project's container. Here is how it works:
- Configuration/Production/Settings.yaml can be used as you like to provide settings for the Production context in general.
- Configuration/Production/Beach/Settings.yaml is written by Beach, whatever you put there will simply disappear in the deployed instance.
- Configuration/Production/Beach/Instance/Settings.yaml is what the instance will use, if it exists. It can thus be used to provide settings specifically for Beach.
Using a custom sub-context
In case you have extensive settings you need to differentiate between instances, you can set the BEACH_FLOW_SUB_CONTEXT instance variable to override the default Instance sub-context. That way you can have larger blocks of settings per instance.