Skip to main content

dynamic-config-py-web

Native web-framework integrations for dynamic-config-py: the wiring, the request scope, the health surface and the test doors — already written.

The Book · The engine · The Python binding


pip install "dynamic-config-py[fastapi]"      # or [litestar] [flask] [quart]
pip install "dynamic-config-py[django]"       # …[drf] and [ninja] for its API layers
pip install "dynamic-config-py[robyn]"        # Experimental
pip install "dynamic-config-py[django-bolt]"  # Experimental, Python 3.12+
from fastapi import Depends, FastAPI
from dynamic_config import DynamicConfig
from dynamic_config_web.fastapi import config_dependency, setup

config = DynamicConfig(Database, key="db").file("config.toml").env("APP_")
app = FastAPI()

setup(app, config)
database = config_dependency(config)


@app.get("/")
def index(db: Database = Depends(database)):
    return {"host": db.host, "pool": db.pool_size}

That is the whole integration. setup loads before the first request, watches while serving and stops on the way out; /healthz, /readyz and /metrics are mounted; and every handler reads the configuration the request began with.

What it does that a dependency function does not

One reading per request, enforced. The engine's own book states the rule — read current() once per request and use that value for the whole request — because a reload landing mid-request would otherwise show one request two configurations. Here it is a contextvars scope opened by the adapter: a second read is the same object, and a read outside a request raises instead of quietly answering with whatever is installed at that instant.

One watcher, however many times the app is built. A second watch() on one configuration is AlreadyExists. uvicorn --reload rebuilds the app on every edit and a test suite builds one per client, so the watcher is leased and counted: the first holder starts it and the last one stops it.

A watcher in every worker. A watcher is a thread, and a thread does not survive fork() — but the engine's registration does, so a gunicorn --preload worker would be refused a new one while nothing was watching. Every lease re-arms itself in the child.

Liveness and readiness as different questions. /healthz never fails on configuration: a process that cannot reload should stop receiving traffic, not be restarted into reading the same broken file. /readyz is where nothing installed, reloads failing and too stale answer 503.

Diagnostics only when you say so. /_config/explain and /_config/check are not mounted at all without a guard — not mounted-and-403, which would tell a scanner they exist.

The seven

Framework Extra Seam Tier
FastAPI [fastapi] lifespan, Depends, APIRouter, ASGI middleware Beta
Litestar [litestar] InitPlugin.on_app_init — lifespan, Provide, routes, middleware Beta
Flask [flask] extension in app.extensions, Blueprint, before_request Beta
Quart [quart] the async twin, on while_serving Beta
Django [django] AppConfig.ready(), middleware, urls, a management command Beta
Django REST Framework [drf] APIView + a permission class Beta
django-ninja [ninja] a Router, and the operation auth= Beta
Robyn [robyn] startup/shutdown events, @scoped handlers Experimental
django-bolt [django-bolt] BoltAPI(lifespan=…, middleware=…), Router Experimental

Each has a page or a section in the book and a runnable example in examples/; all nine answer the same twelve conformance cases, and where one cannot — Robyn's request scope — the suite says so by name rather than skipping quietly.

What this package is not

It is not a second configuration API. Every value still comes from dynamic-config-py, every diagnostic is the engine's, and the adapters add no cache, no copy and no second source of truth — db.current() is still the read path, and current() here is that read taken once per request.

What you may build on and find unchanged tomorrow is written down: the Compatibility Contract.

License

MIT.

Metadata

Release files for dynamic-config-py-web 0.2.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for dynamic-config-py-web 0.2.1
File Size Uploaded
dynamic_config_py_web-0.2.1.tar.gz 152.7 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for dynamic-config-py-web 0.2.1
File Interpreter ABI Platform
dynamic_config_py_web-0.2.1-py3-none-any.whl Python 3 none any Details

Total release size: 226.3 kB

Release files / dynamic_config_py_web-0.2.1.tar.gz

Download URL dynamic_config_py_web-0.2.1.tar.gz
Size 152.7 kB
Tags Source
SHA-256 checksum
How to use checksums
8e82dad04db494cb0a40aecfe8b95ebe9078c2996ec6f9225a7d070e4df1f044
BLAKE2b-256 checksum
How to use checksums
860a0dd5553447e1e967fd7690227c805698e1d7fb42a1022ddc908eb341c589
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 20, 2026.

Transparency log

Release files / dynamic_config_py_web-0.2.1-py3-none-any.whl

Download URL dynamic_config_py_web-0.2.1-py3-none-any.whl
Size 73.6 kB
Tags Python 3
SHA-256 checksum
How to use checksums
5991a31ea52179a4afba484658075f07faeda9cb503c2d9dfbecfa0cde8f05a2
BLAKE2b-256 checksum
How to use checksums
1aca2170f2e076d7fe9f73e25d7ab6a16b66beabf66578e12a62ea12a81e270d
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 20, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.2.1 This release

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page