Config Reference
Complete config.toml schema with all fields, types, and defaults
merod init defaults
Running merod init generates a config.toml with these CLI-controllable defaults:
Top-Level Structure
[identity] — Node Identity
Ed25519 keypair for the node. Generated automatically on merod init.
[swarm] — libp2p Swarm
Multiaddrs the libp2p swarm listens on for peer connections.
[bootstrap] — Bootstrap Nodes
List of bootstrap peers to connect to on startup for peer discovery.
[discovery] — Peer Discovery
Configures mDNS, rendezvous, relay circuit, autonat, and address advertisement.
[discovery.rendezvous]
[discovery.relay]
[discovery.autonat]
[server] — HTTP Server
HTTP/WebSocket/SSE API server for meroctl and external clients.
[server.embedded_auth]
Embedded authentication settings (used when auth_mode = "Embedded").
[sync] — Sync Engine
Timeouts and intervals for the state synchronization engine.
[datastore] — RocksDB Storage
Path for the RocksDB persistent storage engine.
[blobstore] — Blob Storage
Path for binary blob (WASM applications, large files) storage.
[context] — Context Client
Configuration for the context management subsystem.
[tee.kms.phala] — TEE / KMS
Optional Trusted Execution Environment and Key Management Service configuration. Only nodes with a [tee] section perform the KMS key-fetch and attestation flow at startup; other nodes use libp2p as usual without KMS. The section is nested: [tee] contains [tee.kms], which contains the provider block [tee.kms.phala] (Phala Cloud KMS / mero-kms-phala is currently the only provider). There is no flat enabled / kms_url key — presence of the [tee] block enables TEE mode, and the endpoint is tee.kms.phala.url. See TEE Mode for the full startup flow.
merod run --mock-tee
Dev/test only. Pass --mock-tee (or set MEROD_MOCK_TEE=1) to merod run to make the fleet-join and attest handlers produce and accept mock attestation quotes without real TDX hardware. merod will refuse to start (bail!) if the node's [tee.kms.phala.attestation] has real attestation configured (TeeConfig::has_real_attestation returns true). A loud warning is emitted on startup whenever --mock-tee is active; an additional warning fires if a Phala KMS provider is configured but real attestation is disabled (likely misconfiguration). The flag is threaded through NodeConfig::mock_tee → AdminState::mock_tee at runtime and is never persisted to config.toml. Never use in production.
[tee.kms.phala]
[tee.kms.phala.attestation]
KMS self-attestation verification policy (verified via POST /attest before key requests).
[tee.kms.phala.tls]
Optional TLS hardening for KMS transport. All paths must be absolute and point to existing PEM files; setting any TLS path requires tee.kms.phala.url to use https://.
[specialized_node] — Specialized Node
Settings for specialized node roles (e.g., TEE nodes that handle key shares).
Complete Example
A typical production config.toml with commonly customized fields:
Governance Migration
Guide for migrating between group governance modes.
Default Configuration
Local governance is the default (and only) governance mode. Group operations are signed locally and propagated via gossip.
Backup
Back up the node data directory (RocksDB store path in config.toml) regularly. The group_store contains all governance state and can be rebuilt from the persistent op log, but a backup provides faster recovery.