Agent configuration
All agents use the same method of configuration which is a multi-layered config approach which allows for easy overriding of default configs. Each layer overrides overlapping values in the previous.
Config layers
- Base configuration from "default deployments" are in the monorepo and all of these are loaded automatically.
- Config files passed in via the
CONFIG_FILES
env var are loaded next; this env var should be a comma separated list of paths to json files that should be loaded in order from first to last. HYP_
prefixed env vars will be read next.HYP_<AGENT>_
prefixed env vars are then read and apply ONLY for the current agent. I.e.RELAYER
,VALIDATOR
, andSCRAPER
will only read their respective prefixes.- Command line arguments will be read last
Command line arguments
Command line arguments are added after the application name, such as./relayer --originChainNames="test1,test2,test3"
The following formats are supported:
--argName argValue
--argName "argValue"
--argName 'argValue'
--argName=argValue
--argName="argValue"
--argName='argValue'
Argument names are case-insensitive, so in this guide we may show them in camel-case for easier reading, but --argName
is equivalent to --ARGNAME
and --argname.
Examples:
{ "db": "/path/to/dir" }
can be set with--db "/path/to/dir"
{ "chains": { "ethereum": { "name": "ethereum" } } }
(abbreviated aschains.ethereum.name
orchains.<chain_name>.name
) can be set with--chains.ethereum.name ethereum
{ "chains": { "avalanche": { "customRpcUrls": "https://some-url.com" } } }
(abbreviated aschains.<chain_name>.customrpcurls
) can be set with--chains.avalanche.customrpcurls "https://some-url.com"
Environment variables
The config file format is the preferred way to set things which are not secret and do not need to change for each run as it is the easiest format to inspect and edit. Every config value in the file can be set as an env var if you use the correct name, however, there are a few env vars that cannot be set in the config such as CONFIG_FILES
.
HYP_
and HYP_<AGENT>_
are equivalent prefixes with the only difference being which order they are loaded in and can refer to all of the config values in the config files.
The env name will be one of those two prefixes, and then the underscore-separated path of the uppercased path components to the config value.
For example:
{ "db": "/path/to/dir" }
can be set withHYP_DB="/path/to/dir"
orHYP_RELAYER_DB="/path/to/dir"
{ "chains": { "ethereum": { "name": "ethereum" } } }
(abbreviated aschains.ethereum.name
orchains.<chain_name>.name
) can be set withHYP_CHAINS_ETHEREUM_NAME="ethereum"
orHYP_VALIDATOR_CHAINS_ETHEREUM_NAME="ethereum"
orHYP_RELAYER_CHAINS_ETHEREUM_NAME="ethereum"
...{ "chains": { "avalanche": { "customRpcUrls": "https://some-url.com" } } }
(abbreviated aschains.<chain_name>.customrpcurls
) can be set withHYP_CHAINS_AVALANCHE_CUSTOMRPCURLS="https://some-url.com"
orHYP_VALIDATOR_AVALANCHE_CUSTOMRPCURLS="https://some-url.com"
and so on...
Config files with Docker
Running with the agent in Docker adds an extra layer of complexity because the config files need to be accessible from within the Docker container. The base configs that can be found in the repo are already part of the provided Docker image and will all be loaded by default.
Mounting a single config file can be done with the flag --mount type=bind,source=$LOCAL_CONFIG_PATH,target=/config/$CONFIG_NAME,readonly
and then adding the config file to CONFIG_FILES
so it is loaded.
Mounting an entire directory can be done with the flag --mount source=$LOCAL_CONFIG_DIR_PATH,target=/config,readonly
then adding the individual config files to CONFIG_FILES
that you want so they are loaded.
For example, suppose you have a config file at your local machine's path /home/workspace/ethereum.json
and want to run the validator with it.
docker run -it --mount type=bind,source=/home/workspace/ethereum.json,target=/config/ethereum.json,readonly -e CONFIG_FILES=/config/ethereum.json $DOCKER_IMAGE ./validator
The source
path is the path on your local machine, the target
path is where the source path contents will be made available within the Docker container, and the CONFIG_FILES
should specify config(s) from the target path.