Remote Config
Serve every profile's config from one central config plane instead of config.yaml, with layered settings and keys administrators can lock.
Remote config mode replaces config.yaml with the config plane. The plane builds each profile's config in layers: global, tenant, group, owner and agent settings, with the profile's own settings applied last, and administrators can lock a key at an upper level so the agent cannot change it. It is built for fleet deployments such as Hermes Cloud; a single machine with one user should keep config.yaml. You turn it on in the environment, ~/.hermes/.env or the managed /etc/hermes/.env (which wins), never in config.yaml, by setting HERMES_CONFIG_BACKEND=remote and HERMES_CONFIG_INSTANCE_ID. The agent authenticates as itself: the Nous access token in auth.json on Hermes Cloud, or an OAuth2 client-credentials token on-prem. Startup fetches config and fails closed after about 30 seconds of retries, there is no local file or cache, and each process polls for changes every 5 minutes. Writes such as hermes config set and /model send only the changed keys to the profile's own level, locked keys are refused, and secret-shaped keys accept only a ${VAR} reference. Commands that copy or edit config.yaml are refused, /etc/hermes/config.yaml is ignored, and hermes doctor reports the plane instead of the file.
New words here · Plain English
one sentence each · full glossarySources · What this video distills
1 docs page · every command below traces to itCommands shown · Copy and paste
each shows the source doc it came fromHERMES_CONFIG_BACKEND=remotehermes config set model.api_key '${OPENROUTER_API_KEY}'hermes doctor