hydra-node
Safe HaskellSafe-Inferred
LanguageGHC2021

Hydra.Config

Description

YAML-based configuration file support for hydra-node.

This module provides a user-friendly configuration file format that mirrors the CLI flag names (kebab-case). A configuration file can be used instead of CLI flags by passing --config FILE to hydra-node.

Example configuration:

node-id: hydra-node-1
listen: "0.0.0.0:5001"
peers:
  - address: "peer1:5001"
    cardano-verification-key: peer1.cardano.vk
    hydra-verification-key: peer1-hydra.vk
api-host: "127.0.0.1"
api-port: 4001
hydra-signing-key: hydra.sk
persistence-dir: "./"
ledger-protocol-parameters: protocol-parameters.json
chain:
  mode: cardano
  network: preview
  cardano-signing-key: cardano.sk
  contestation-period: 43200
  deposit-period: 3600
  backend:
    mode: direct
    testnet-magic: 2
    node-socket: node.socket
Synopsis

Documentation

loadConfig :: FilePath -> IO RunOptions Source #

Load RunOptions from a YAML configuration file.

Keys use kebab-case matching the CLI flag names, e.g. node-id, api-host. Missing keys fall back to the same defaults as the CLI.

Relative file paths in the config are resolved relative to the directory containing the config file, not the current working directory.

resolvePaths :: FilePath -> RunOptions -> RunOptions Source #

Make all relative FilePath fields in RunOptions absolute by resolving them against dir (the directory containing the config file). Absolute paths are left unchanged.

renderConfig :: RunOptions -> Value Source #

Render RunOptions as a JSON document whose structure matches the YAML config file format (kebab-case keys, same hierarchy). This is the inverse of loadConfig and is served at the GET /config HTTP endpoint so operators can inspect the effective configuration the node is running with.

isSelfAddress :: Host -> Maybe Host -> Host -> Bool Source #

Does the given peer address refer to the same node as us, given our $sel:listen:RunOptions and optional $sel:advertise:RunOptions hosts?

The comparison normalizes wildcard/loopback variants:

  • If $sel:advertise:RunOptions is set, the peer must match it exactly (same host, same port) — we trust the operator's explicit choice.
  • Otherwise, same-port peers are self when:
  • the host string is identical to the listen host (even if it's 0.0.0.0, matching the "self-entry with same address" convention);
  • the listen host is a wildcard (0.0.0.0, ::, *) and the peer host is a loopback (127.0.0.1, localhost, ::1); or
  • both are loopback in some combination.

We deliberately do *not* treat wildcard listen as matching arbitrary remote peers on the same port — those may be legitimate other-host participants.