Config Management
Read & hot-patch config at runtime
configManagement exposes a small, godmin-only API for inspecting and adjusting the running configuration without a redeploy. It's the operator's window into the live service: see exactly what's configured (with secrets masked), patch a hot-reloadable section, or trigger a graceful restart.
The implementation is fully generic — sections are derived from the live config's keys at runtime, and sensitive fields are detected by name patterns rather than a hard-coded list, so it stays correct as the config evolves.
Enabling#
Two fields turn the feature on and choose its route prefix. It's off by default because it's a privileged surface.
1{2 "configManagement": {3 "enabled": true,4 "basePath": "/nucleus/config"5 }6}enabledbooleanOptionalMount the config-management endpoints. Off by default — enable deliberately, and only behind godmin auth.
falsebasePathstringOptionalRoute prefix for the management endpoints.
"/nucleus/config"What it exposes#
With the feature enabled, the following godmin-only routes are mounted under basePath. Reads always mask secret-bearing fields; writes deep-merge into the named section and persist to disk.
Under the hood — the runtime config API#
The routes operate on the live, resolved config object. Reads are always masked; writes choose between an instant hot-reload and a restart, and persist as durably as the environment allows.
godmin guardheader + DB fallbackOptionalEvery route checks for the godmin role in x-user-roles, and if the JWT predates the role assignment, falls back to the user's isGod flag in the database — otherwise 403. There is no non-godmin path in.
masking & env diagnosticsGET / · /envOptionalGET / returns the whole config with sensitive fields masked; GET /env walks the tree for UPPER_SNAKE_CASE env-var references and reports which resolved and which are missing — the fastest way to debug a bad deploy's environment.
hot-reload vs restartisRestartRequiredOptionalPATCH /:section deep-merges into object sections (arrays like entities are replaced). Hot-reloadable sections fire an onConfigUpdate callback and apply immediately; restart-required sections are saved and flagged, taking effect only after a restart.
persistence fallbackdisk → Redis → memoryOptionalAn update is written to the config file on disk if a path is known; if that fails it's stored as a Redis override (merged on next restart); if Redis is also unavailable it stays in-memory only, and the response says so. GET/DELETE /overrides inspect and clear those Redis overrides.
graceful restartPOST /restartOptionalSchedules process.exit(0) after a short delay and relies on the orchestrator (K8s/PM2/systemd) to bring the process back — the supported way to apply restart-required changes without a manual deploy.
Related sections