Summary
Extend the blueprint to support a centralized configuration service so that settings can be managed across multiple agent instances without duplicating config files — while retaining Dynaconf as the local configuration layer.
Motivation
When running multiple blueprint-based agents in a shared environment, each service currently maintains its own local config. A centralized config service allows shared settings (e.g. model endpoints, feature flags, environment-specific values) to be managed in one place, with local Dynaconf config serving as a fallback or override layer.
Proposed Approach
- Introduce a
CentralizedConfigSource abstraction that can be plugged into the existing Dynaconf setup as an additional loader
- Support at least one concrete backend out of the box (e.g. AWS AppConfig, Consul, or a simple HTTP-based config endpoint)
- Merge order: remote centralized config → local Dynaconf files → environment variables (standard Dynaconf precedence applies for overrides)
- Config is fetched at startup and optionally refreshed at a configurable interval without restart
Acceptance Criteria
- AC-01: The blueprint can be configured to pull settings from a centralized config source at startup in addition to local Dynaconf files.
- AC-02: Local Dynaconf configuration (settings files, environment variables) continues to work without modification when no centralized source is configured — the feature is fully opt-in.
- AC-03: At least one centralized backend is supported and documented with a working example in the blueprint.
- AC-04: Merge/override precedence between remote config and local Dynaconf settings is clearly defined and tested.
- AC-05: The blueprint supports a configurable refresh interval; updated remote values are picked up without a service restart.
- AC-06: If the centralized config source is unreachable at startup, the service falls back to local config and logs a warning — it does not crash.
- AC-07: Sensitive values retrieved from the centralized source are not printed to logs.
Summary
Extend the blueprint to support a centralized configuration service so that settings can be managed across multiple agent instances without duplicating config files — while retaining Dynaconf as the local configuration layer.
Motivation
When running multiple blueprint-based agents in a shared environment, each service currently maintains its own local config. A centralized config service allows shared settings (e.g. model endpoints, feature flags, environment-specific values) to be managed in one place, with local Dynaconf config serving as a fallback or override layer.
Proposed Approach
CentralizedConfigSourceabstraction that can be plugged into the existing Dynaconf setup as an additional loaderAcceptance Criteria