The Ecosystem

Quadkit publishes five packages. Three are libraries you compose into an app — quadkit, quadkit-contracts, quadkit-web — and two are tooling: quadkit-cli scaffolds and runs projects, quadkit-testing boots them under test.

Every extension depends only on quadkit and quadkit-contracts, never on another extension. That boundary is what keeps the ecosystem composable — see Architecture.

Start from the CLI. Templates pick the first handful of packages; you add the rest later.

uv add "quadkit-cli>=0.0.42,<0.1"
quadkit new project my-app --template web-api
cd my-app
quadkit run

This catalog is the same list as the package sidebar and the landing cards. Canonical URLs live under /packages/{group}/…. Ungrouped /packages/quadkit-* paths redirect here.

Foundation

The container, the lifecycle, and the contracts everything else builds on.

Package	What it does
`quadkit`	Async-first core: the DI container, application lifecycle, providers, modules, typed config, and the Result model.
`quadkit-contracts`	Protocols, shared types, and the exception hierarchy — zero runtime dependencies beyond typing-extensions.

Web & HTTP

ASGI, routing, middleware, and the Result-to-HTTP bridge.

Package	What it does
`quadkit-web`	The async web layer: controllers with signature-based binding, middleware pipelines, a Result-to-HTTP bridge, and OpenAPI.
`quadkit-http`	HTTP client with typed Result errors, retries, timeouts, and a pluggable transport for calling other services.

Data

Relational and document storage behind repositories.

Package	What it does
`quadkit-sql`	Async SQL repositories: typed rows, migrations, connection pooling, and a repository base over SQLAlchemy and asyncpg.
`quadkit-cache`	Cache primitives: a Cache protocol, in-memory and Redis backends, stampede-safe single-flight helpers, and TTL invalidation.
`quadkit-storage`	Artifact storage: a BlobStore protocol, local and S3 backends, content-addressed keys, and signed URL helpers.

Events

Publish, subscribe, replay.

Package	What it does
`quadkit-events`	Event bus, outbox publishing, durable subscriptions, and a timeline/replay API for auditing what happened.

Infra

Background work and operational visibility.

Package	What it does
`quadkit-tasks`	Background tasks: a queue, worker pools, retries with backoff, schedules, and an HTTP console for observing runs.
`quadkit-monitor`	Observability: counters, histograms, structured logs, health/readiness probes, and a metrics endpoint.

Security

Identity, sessions, and access control.

Package	What it does
`quadkit-auth`	Authentication and authorization: API keys, MFA, RBAC, session stores, and login flows wired through the DI container.

Tooling

Scaffold, run, and test a project: the CLI and the testing harness.

Package	What it does
`quadkit-cli`	The quadkit command line: project scaffolding, generators, a smart runner, and admin commands.
`quadkit-testing`	Test harnesses, fakes, and fixtures that boot the real application in-process.

Choosing packages

A typical web application starts like this:

quadkit new project my-app --template web-api   # quadkit, quadkit-contracts, quadkit-web
quadkit add web                                 # wire the web section explicitly
uv add --dev quadkit-testing                    # test harness

quadkit add offers the providers that are actually installed — a public install advertises web, testing, connect, and resilience, and reports anything else as unknown rather than adding a package you cannot fetch.

Staged stacks: Adoption Paths. Dependency rules, extras, and runtime constraints: Compatibility.

Next Steps

Installation — uv add quadkit-cli and scaffold
Your First App — scaffold with the CLI and run
Architecture — the boundary rules that hold the ecosystem together
Adoption Paths — from a hello-world route to a tested service
Compatibility — extras, drivers, and dependency rules