Choose crates and Cargo features

Facade or narrow crates

Use runifold for applications that combine models, Agents, workflows, tools, and optional integrations. It re-exports the stable runtime surface; concrete Provider adapters are selected separately from runifold-providers. Use narrow crates when building infrastructure, adapters, or libraries that must not pull in orchestration.

Feature map

The facade has no Provider Features in 0.9. Enable native protocols such as openai, anthropic, bedrock, gemini, or ollama on runifold-providers; named compatible modules reuse its openai Feature. Optional platform Features on runifold include mcp, otel, sqlite, sqlite-bundled, workflow-postgres, qdrant, pgvector, and archive-s3.

Features select compiled capability, not runtime authority. Enabling mcp or archive-s3 does not grant a Run permission to call or delete anything.

Common configurations

• model-backed API: facade + one Provider Feature;
• durable local service: Provider + sqlite;
• distributed workflow platform: Provider + workflow-postgres + otel;
• RAG service: Provider + pgvector or qdrant;
• MCP workflow server: mcp + workflow-postgres;
• governance archive: workflow-postgres + archive-s3 + otel.

Start smaller than the target production topology, but do not prototype with a Store whose semantics contradict the intended deployment.

Dependency boundaries

Keep CLI-only crates out of runtime dependencies. Keep database adapters at the application edge. Avoid enabling every Provider in a reusable library. Pass trait objects or narrow interfaces inward rather than provider clients, database pools, and credential types.

Review cargo tree -e features when unexpected HTTP, database, cloud, or TLS dependencies appear.

Upgrade checklist

Pin the exact pre-1.0 version, read the changelog, review Feature changes, run MSRV and target builds, recompile examples, execute Store migration and recovery tests, re-run Provider conformance, and compare evaluation baselines. An API-compatible dependency update may still change model or Provider behavior.

Choose and audit Features

Add only the capabilities the binary owns. These examples pin the published 0.9.0 contract:

# Local durable service with OpenAI and bundled SQLite.
cargo add runifold@=0.9.0 --features sqlite-bundled
cargo add runifold-providers@=0.9.0 --features openai
 
# Distributed worker with PostgreSQL and OpenTelemetry.
cargo add runifold@=0.9.0 --features workflow-postgres,otel
cargo add runifold-providers@=0.9.0 --features openai
 
# Inspect exactly what those choices enabled.
cargo tree -e features -i runifold
cargo tree -e features -i runifold-providers
cargo tree -d
cargo check --all-targets

If an unexpected TLS stack, database driver, or cloud SDK appears, trace it with cargo tree -e features and remove the enabling Feature at the application boundary. In a reusable library, prefer default-features = false and expose your own small Feature that forwards only the required Runifold capability.