Configuration Options
Relevant source files
The following files were used as context for generating this wiki page:
Memory Context Browser (MCB) utilizes a structured configuration system based on the Loco framework, primarily driven by YAML files for runtime settings and TOML files for architecture validation rules. The system is designed to provide strict environment-specific configurations while ensuring that operational defaults are not hardcoded within the application logic.
The configuration scope encompasses embedding providers, vector stores, database connections, system limits, and architectural enforcement rules. MCB supports different profiles including development, test, and production, with the AppConfig struct serving as the primary deserialization target for settings defined under the settings: key in YAML files.
Sources: AGENTS.md:310-315, crates/mcb-infrastructure/tests/integration/config/strict_config_tests.rs:205-215, README.md:40-55
Runtime Configuration (YAML)
MCB's runtime behavior is governed by Loco YAML configuration files. Operational settings are housed under a top-level settings: key, which is deserialized into the AppConfig model. The system strictly forbids hardcoded fallbacks for sensitive identifiers like project_id or repo_id, requiring them to be auto-detected or explicitly configured.
Configuration Profiles
The system maintains distinct profiles to manage environment-specific behaviors:
| Profile | Purpose | Primary Characteristics |
|---|---|---|
| Development | Local development | Port 3000, SQLite, Ollama embeddings, Milvus vector store. |
| Test | Automated testing | Dynamic port 0, FastEmbed, EdgeVec, destructive DB flags enabled. |
| Production | Live deployment | Port 8080, admin API key enabled, strict identity validation. |
Sources: AGENTS.md:316-322, crates/mcb-infrastructure/tests/integration/config/strict_config_tests.rs:260-275
Config Loader Architecture
The configuration loading process involves reading YAML files and validating the resulting AppConfig through a ConfigProvider.
The system employs #[serde(deny_unknown_fields)] to ensure that configuration files do not contain unrecognized keys, preventing configuration drift or typos from going unnoticed.
Sources: crates/mcb-infrastructure/tests/integration/config/strict_config_tests.rs:88-100, crates/mcb-infrastructure/tests/integration/config/strict_config_tests.rs:125-130
Validation Rules Configuration (TOML)
MCB uses a specialized validation engine, mcb-validate, to enforce Clean Architecture principles and code quality standards. This is configured via TOML files.
Global vs. Internal Configuration
- mcb-validate.toml: The default configuration embedded in the binary. It defines standard thresholds like
max_file_lines(default 500) andmax_function_lines(default 50). - mcb-validate-internal.toml: Project-specific overrides that define the actual layer boundaries for the MCB workspace.
Sources: config/mcb-validate.toml:1-40, config/mcb-validate-internal.toml:1-20
Architecture Layer Boundaries
The internal validation configuration explicitly defines allowed dependencies between crates to ensure the Clean Architecture flow (Dependencies flow inward only).
| Crate | Allowed Internal Dependencies |
|---|---|
| mcb-server | mcb-domain, mcb-infrastructure, mcb-utils |
| mcb-infrastructure | mcb-domain, mcb-providers, mcb-utils |
| mcb-providers | mcb-domain, mcb-utils |
| mcb-domain | mcb-utils (Leaf crate dependency only) |
Sources: config/mcb-validate-internal.toml:15-22, AGENTS.md:285-300
Core Configuration Categories
Embedding & Vector Storage
Settings for semantic search capabilities are configured via the embedding_provider and vector_store sections.
// Derived from crates/mcb-server/src/controllers/web/config.rs:40-60
let body = format!(
r#"<h3>Embedding Provider</h3>
<tr><td>Provider</td><td><strong>{provider}</strong></td></tr>
<tr><td>Dimensions</td><td>{dims}</td></tr>
<h3>Vector Store</h3>
<tr><td>Provider</td><td><strong>{vp}</strong></td></tr>
<tr><td>Host</td><td>{vh}</td></tr>
<tr><td>Port</td><td>{vport}</td></tr>"#
);
Sources: crates/mcb-server/src/controllers/web/config.rs:40-60
System Limits and Operations
The AppConfig includes critical operational parameters that must be non-zero when enabled:
- Cache:
default_ttl_secsmust be greater than 0 if caching is enabled. - Limits:
memory_limitandcpu_limitare mandatory for resource management. - Backups:
interval_secsdefines the frequency of automated data backups. - Daemon:
max_restart_attemptsgoverns the resilience of the operations daemon.
Sources: crates/mcb-infrastructure/tests/integration/config/strict_config_tests.rs:490-530, crates/mcb-infrastructure/tests/integration/config/strict_config_tests.rs:560-575
Enforcement Policies
The project maintains a "Strictness Policy" for configurations:
- No Direct Env Reads: Direct calls to
std::env::varare banned in production code paths to prevent hidden configuration dependencies; all environment interaction must go through the config loader. - No Default Impls: Operational config types must not implement
Defaultin code; defaults must be explicitly defined indevelopment.yaml. - Fail Fast: The configuration provider will fail the application startup if required keys (like
auth.password_algorithm) are missing or if security-sensitive fields (like JWT secrets) are empty when enabled.
Sources: crates/mcb-infrastructure/tests/integration/config/strict_config_tests.rs:180-200, crates/mcb-infrastructure/tests/integration/config/strict_config_tests.rs:220-230, crates/mcb-infrastructure/tests/integration/config/strict_config_tests.rs:455-470
Summary
MCB's configuration system is a robust framework that combines YAML-based runtime settings with TOML-based architectural enforcement. By centralizing settings in environment-specific YAML files and utilizing a strict validation layer, the project ensures consistency, security, and adherence to Clean Architecture principles across development and production environments.