One configuration engine, the same semantics in Rust, Python and Node.js. Files, environment, remote stores and command-line flags merged into one typed value, re-read when they change, served to every thread as a single atomic load — with hot reload, a last-known-good cache and provenance for every value, and no daemon to run.

📖 The books · one site, seven sections

#[dynamic_config]
#[derive(Debug, Deserialize)]
struct Database { host: String, port: u16 }

let builder = Database::builder("db").file("config.toml").env("APP_");
builder.init()?;                                     // load once, fail fast
builder.watch(Duration::from_millis(250))?.detach(); // and stay current

Database::current().host;                            // one atomic load, any thread

• Layered, with a stated order. Defaults, discovered files, files, remote documents, .env, a secrets directory, the environment, bound variables, CLI assignments, overrides — each one wins over the last, and explain() says which layer supplied a value.
• Hot reload that cannot corrupt. A document the schema refuses installs nothing and leaves the previous one serving — from the watcher exactly as from an explicit reload.
• Lock-free reads. current() is an arc-swap guard: 85 instructions and zero allocations, measured by a benchmark rather than asserted.
• Secrets are paths and types, never values. Diffs, reports and error messages name the key and the expected type; the value stays out.
• The same engine in three languages. The bindings are thin: Rust resolves, your schema validates, and the host language reads a cache.

Each names the engine with a caret, so a patch release reaches it without a release of its own — and each is released, tested and versioned in the repository that owns it.

Stability says what a version bump may break; a tier says how much of this we carry. Everything below is Beta — these are two different axes.

Every crate and package is Beta, with two named exceptions: the Robyn and django-bolt adapters in dynamic-config-py-web are Experimental, because those frameworks are young and their process models are the part an adapter depends on most. Pre-1.0 a breaking change bumps the minor version and a patch never breaks, so pinning the minor and taking patches automatically is the intended way to depend on this.

The engine's surface is finished for 0.x: no new sources, no new stores, no new methods on the settled types. That is a decision, not a pause — nothing new lands there until the current surface has been used enough to know what is wrong with it.

The bindings are younger than the engine, and where using one turns up a missing piece, it is added and announced as an addition rather than smuggled in as a hotfix. Both bindings grew their concurrency surface once — dynamic-config-python 0.2 and dynamic-config-node 0.0.3 — and each stability page says what it added and why.

What happens before 1.0 in either case is evidence — conformance across the three languages, soak and chaos runs, fuzzing, and whatever real use turns up.

Each repository carries its own CONTRIBUTING.md, its own gate (just check) and its own book. Security reports go through the private advisory form of the repository that owns the code — the address is in each SECURITY.md.

_{MIT licensed. Released from github.com/ctolon/dynamic-config until 0.6.1, and from this organisation since.}