Adoption Paths

QuadKit is designed for incremental adoption. You do not install a catalog; you scaffold with the CLI and add packages as the application grows. The current public line is focused on purpose — eighteen packages, one project shape, all published at 0.0.50.

Day one — the CLI

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

That is the supported start. The CLI currently provides one api starter; add installed packages with quadkit add and generate components with quadkit gen. The project shape stays the same. Feature types live in domains/. App providers live in app-root di/.

Hand-wiring create_app() is possible; the CLI is what generators and quadkit run expect. See Installation and Project Structure.

Starter — a web API

Enough to serve HTTP with OpenAPI. No database, no cache, no auth — fine for prototypes and early services.

• quadkit + quadkit-contracts — DI container, Application, YAML config, Result
• quadkit-web — ASGI, controllers, middleware, OpenAPI (included by the api starter)

quadkit new project my-app --template api
quadkit run

Tip

This is a complete API server. Add persistence when you have something to persist — not because the framework requires it.

Standard — test it, then ship it

The next step is not another library; it is making the app testable and shippable.

• quadkit-testing — test harnesses, fakes, fixtures that boot the real application (uv add --dev)
• quadkit-cli — quadkit gen for new controllers and services, quadkit db/quadkit config for operations

uv add --dev quadkit-testing
quadkit gen controller users --module billing
quadkit run --server granian

See Testing and Deployment.

Open-core expansion — available now

The 0.0.50 release added five packages to the thirteen-package line: quadkit-ai-llm, quadkit-ai-agents, quadkit-ai-mcp, quadkit-workflow, and quadkit-notification. All eighteen are published on PyPI at 0.0.50.

Beyond the published catalog, enterprise tenancy, external broker queues, search, GraphQL, and RAG/memory extensions remain in the private repository and are not installable from PyPI.

The eighteen-package catalog is the open-core contract surface. As further packages stabilize and release, they layer on without changing your application code.

Note

quadkit add only advertises providers whose distribution is installed, so a public project never gets a dependency line it cannot fetch.

Decision flow

Starting a new project?
├── Prototype or microservice → CLI + api starter
├── Keep it alive long term   → add quadkit-testing, wire health and logs
├── Need AI & tool use        → add quadkit-ai-llm, quadkit-ai-agents, quadkit-ai-mcp
├── Need persistence          → add quadkit-sql, quadkit-cache, quadkit-storage
├── Need auth                 → add quadkit-auth
├── Need workflows & jobs   → add quadkit-tasks, quadkit-events, quadkit-monitor, quadkit-workflow, quadkit-notification
└── Need tenancy/search/RAG   → not published yet; keep contracts, add later

Each step is a superset of the one before it. Moving forward is uv add, not a rewrite.

---

See Compatibility for extras, dependency rules, and runtime constraints.