LogoLogo
  • ⏩Introduction
    • Hyperlane Introduction
    • Getting started
    • Why Should You Use Hyperlane?
  • Permissionless Interoperability
    • Overview
    • Deploy Hyperlane
    • Warp Routes
      • Deploy a Warp Route
      • Deploy a UI for your Warp Route
    • Modular Rollup Interoperability
  • Build With Hyperlane
    • Quickstarts
      • Messaging
      • Accounts
      • Queries
      • hyperlane-quickstart repo
    • Guides
      • Finding my messages
      • Automatically pay for interchain gas
      • Manually pay for interchain gas
      • Choosing an interchain gas paymaster contract
      • Unit testing
      • Specifying an ISM
      • V2 migration guide
    • Explorer
      • Debugging messages
      • Configuring PI Chains
      • REST API
      • GraphQL API
    • Troubleshooting/Developer FAQ
    • Example apps
  • APIs and SDKs
    • Messaging API
      • Send
      • Receive
    • Accounts API
    • Queries API
    • Warp Route API
    • Interchain gas paymaster API
    • Hyperlane App Framework
      • Example usage
        • HelloWorld
        • Interchain Token
      • Solidity SDK
        • HyperlaneConnectionClient
        • Router
      • NodeJS SDK
        • RPC Providers
        • Deployment
        • Interchain testing
        • Quoting gas payments
        • App Abstraction
    • Hooks API
      • Contract addresses
  • Protocol
    • Overview
    • Mailbox
    • Interchain security modules
      • Interface
      • Multisig ISM
      • Routing ISM
      • Aggregation ISM
      • Optimistic ISM
      • Wormhole ISM
      • Hook ISM
      • CCIP-Read ISM
    • Interchain gas payments
    • Staking and slashing
    • Agents
      • Validators
      • Relayers
      • Watchtowers
    • Warp Routes
    • Implementation Guide
  • Operators
    • Validators
      • Guide
      • AWS setup
      • Monitoring and alerting
    • Relayers
      • Guide
      • Message filtering
    • Agent keys
      • Hexadecimal keys
      • AWS KMS keys
    • Agent configuration
      • Configuration reference
    • Running with docker compose
  • Resources
    • FAQ
    • Glossary
    • Contract addresses
      • Permissionless Deployment Contract Addresses
    • Domain identifiers
      • Permissionless Domain Identifiers
    • Default ISM settings
    • Coming Soon: Hyperlane v3
    • Token sources & faucets
    • Latencies
    • Github
    • Discord
    • Website
Powered by GitBook
On this page
  • Config layers
  • Command line arguments
  • Environment variables
  • Config files with Docker
  1. Operators

Agent configuration

PreviousAWS KMS keysNextConfiguration reference

Last updated 1 year ago

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

  1. Base configuration from "default deployments" are in the and all of these are loaded automatically.

  2. 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.

  3. HYP_BASE_ prefixed env vars will be read next.

  4. HYP_<AGENT>_ prefixed env vars are then read and apply ONLY for the current agent. I.e. RELAYER, VALIDATOR, and SCRAPER will only read their respective prefixes.

  5. 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 as chains.ethereum.name or chains.<chain_name>.name) can be set with --chains.ethereum.name ethereum

  • { "chains": { "avalanche": { "connection": { "url": "https://some-url.com" } } } } (abbreviated as chains.avalanche.connection.url or chains.<chain_name>.connection.url) can be set with --chains.avalanche.connection.url "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_BASE_ 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 with HYP_BASE_DB="/path/to/dir" or HYP_RELAYER_DB="/path/to/dir"

  • { "chains": { "ethereum": { "name": "ethereum" } } } (abbreviated as chains.ethereum.name or chains.<chain_name>.name) can be set with HYP_BASE_CHAINS_ETHEREUM_NAME="ethereum" or HYP_VALIDATOR_CHAINS_ETHEREUM_NAME="ethereum" or HYP_RELAYER_CHAINS_ETHEREUM_NAME="ethereum" ...

  • { "chains": { "avalanche": { "connection": { "url": "https://some-url.com" } } } } (abbreviated as chains.avalanche.connection.url or chains.<chain_name>.connection.url) can be set with HYP_BASE_CHAINS_AVALANCHE_CONNECTION_URL="https://some-url.com" or HYP_BASE_VALIDATOR_AVALANCHE_CONNECTION_URL="https://some-url.com" and so on...

Config files with Docker

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.

Example
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.

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 are already part of the provided Docker image and will all be loaded by default.

monorepo
the repo