Skip to main content

Configuration

Memorose reads runtime configuration from config.toml, MEMOROSE__* environment overrides, and a small set of legacy environment variables. The current runtime config is defined by AppConfig in crates/memorose-common/src/config.rs. That is the source of truth for what the server actually reads.

Main files

  • config.toml: runtime configuration file loaded by the server
  • .env: local environment variables loaded by helper scripts such as ./scripts/start_cluster.sh
  • .env.example: example provider keys and common environment overrides
  • crates/memorose-common/src/config.rs: current runtime config schema and defaults

Current top-level config sections

The current server config is organized around:
Notes:
  • sharding is optional.
  • reranker is optional and defaults to the built-in weighted reranker.
  • Treat config.example.toml and config.toml.example as examples; crates/memorose-common/src/config.rs remains the canonical schema.

Minimal working example

Reranker modes

Reranking is a server-side runtime setting. SDK clients do not choose the reranker mode per request.

Arbitrator mode

arbitrator reuses the main [llm] provider, API key, base URL, and embedding settings. If reranker.model is set, it overrides only the generation model used by the arbitrator.
Important fields:
  • model: optional generation model override for arbitrator mode. If omitted, Memorose uses [llm].model.
  • max_candidates: maximum number of retrieval candidates sent to the model for arbitration. This is not a fixed result count.
  • fallback_to_weighted: falls back to weighted reranking if the arbitrator cannot be built or fails at runtime.
  • include_metadata: includes fields such as importance, level, user, org, domain, and namespace in the arbitrator prompt.
For Docker, enable arbitrator mode with environment variables:

HTTP reranker mode

HTTP mode is for external plugins. top_n applies only to HTTP mode.

Environment variables

There are two supported patterns:

1. Nested runtime overrides via MEMOROSE__

Use MEMOROSE__SECTION__KEY=value to override nested config fields.

2. Legacy direct overrides

The server still reads these directly:
Operational helpers also use:
Important:
  • LLM_PROVIDER appears in .env.example, but the current server config loader does not directly map that variable into llm.provider.
  • If you want to switch provider through env only, prefer MEMOROSE__LLM__PROVIDER=OpenAI or MEMOROSE__LLM__PROVIDER=Gemini.

What each section controls

  • [llm]: provider, API endpoint, model names, embedding settings, optional STT settings
  • [storage]: root data directory and index commit / recent-overlay behavior
  • [raft]: node identity, raft address, election timing, snapshots, bootstrap behavior
  • [worker]: consolidation cadence, forgetting, insight generation, task reflection, and auto-link tuning
  • [sharding]: multi-shard deployment settings and physical node mapping
  • [reranker]: weighted reranking, internal arbitrator mode, or external HTTP reranker

Guidance

  • Treat crates/memorose-common/src/config.rs as the canonical schema.
  • Treat .env.example as an example convenience file, not as a complete description of all runtime behavior.
  • Be careful with older docs or examples that refer to [server], [database], [consolidation], [forgetting], [graph], /health, or /api/v1/*; those do not represent the current server config and API surface.