Support for config file

[eenagy]

Problem description

Lodestar lacks support for a dedicated config file, unlike other Ethereum clients. Currently, configurations must be passed through command line flags or wrapper scripts.

Currently, users need to specify multiple CLI arguments when running Lodestar, which can become unwieldy and difficult to maintain. Configuration files would:

• Make it easier to manage multiple node configurations
• Reduce the chance of typos in command-line arguments
• Allow for better version control of node configurations
• Improve the experience when running nodes in production environments
• It helps integrate lodestar with system.d services, as lodestar would not need a wrapper script to load the config values

Solution description

Allow users to specify a config file path using the --config-file flag:

# Beacon node
lodestar beacon --config-file beacon-config.yaml

# Validator client
lodestar vc --config-file validator-config.yaml

The config files would support all existing CLI options in their YAML/TOML representation. Example:

# beacon-config.yaml
network: mainnet
dataDir: ./beacon-data
eth1:
  provider: http://localhost:8545
rest:
  enabled: true
  port: 9596
metrics:
  enabled: true

Technical Details

• Support either YAML (.yaml, .yml) or TOML (.toml) file formats
• Each CLI option should map directly to its configuration file equivalent
• Maintain the same option names and structure as CLI arguments
• Allow mixing of config file and CLI arguments (CLI takes precedence)

YAML/TOML are preferred due to their human-readable format and widespread use in configuration management.

Additional context

I maintain eth-nodes (https://github.com/eth-pkg/eth-nodes), a project that enables native installation of Ethereum clients (execution, consensus, and validator) via Debian packages, eliminating the need for Docker containers. While the project currently generates configuration files for Lodestar options through wrapper scripts, I'm seeking to implement native configuration file support.

[nflaig]

We already support this via --rcConfig config.yml on both beacon node and validator client, it currently work with YAML and JSON format. The key names are the same as the CLI flag names.

eg.

network: mainnet
rest: true
rest.address: 0.0.0.0
rest.port: 9596
# ...

We don't support nesting as we just handle it with the same parser we use for CLI args, although this could probably be supported somehow to achieve a format like in your example (with nested objects).

[eenagy]

Fantastic! I don't need nesting, that was just an example.

Can you please update the documentation? I always check there and existing GitHub issues before opening an issue.
This option doesn't seem to be in the docs: https://chainsafe.github.io/lodestar/run/beacon-management/beacon-cli

[nflaig]

Yeah, it's a bit tricky with that one because it works differently than other CLI flags, and the documentation for those is generated from the code. I can look into how we can display that on the docs page.

[eenagy]

Yeah, it's a bit tricky with that one because it works differently than other CLI flags and the documentation for those is generated from the code. I can look into how we can display that on the docs page.

Thank you! I would appreciate it. I think there are a couple of more of those that are not in the docs (devnet config values). I'm working on node setup, would be good if those are documented as well, so the users know what they stand for.

[nflaig]

I think there are a couple of more of those that are not in the docs (devnet config values)

There are a lot of flags which are intentionally hidden, mostly because we might change their behavior in the future or they are too technical, can be easily misconfigured or just not meant to be used by normal users (ie. just used for testing by us).

If you have some specific flags in mind we cna unhide them on a case by case basis.

[nflaig]

I think there are a couple of more of those that are not in the docs (devnet config values).

I have opened a PR for this #7271, feel free to chime in if there are additional flags that might be useful to display