Packages

NestRS installs as one dependency. Each concern — HTTP, GraphQL, queues, authorization, observability — is a Cargo feature you enable when the binary needs it, and a feature you leave off is code you never compile. A headless worker compiles no HTTP stack; an MCP-only assistant compiles no GraphQL schema.

cargo add nest-rs --features http,seaorm,graphql

Undecided? --features full turns everything on — narrow it later without moving a single use. Either way nest_rs::prelude::* covers the decorators and types an app reaches for daily.

The table below is a menu of features, not a list of crates to line up.

Note

This page lists framework crates — the batteries NestRS ships. Product logic (users, posts, policies) lives in your workspace’s features crate or equivalent; see The Publish workspace for how apps compose those slices.

Umbrella

Crate	Cargo feature	What it is	Docs
nest-rs	(always)	Re-exports core + optional surface crates; nest_rs::prelude for the common case. One version to bump, and the only framework line your manifest needs — a decorator’s expansion resolves through it	Getting started
nest-rs-core	(via umbrella)	DI container, #[module], lifecycle hooks, boot-time access graph	Fundamentals

Default features: http, config — every other surface crate is opt-in via features = [...].

Transports

Each transport is a module you import in AppModule. HTTP-shaped surfaces (GraphQL, OpenAPI, MCP, WebSocket gateways) mount on the same HttpTransport — one port, one TLS config.

Crate	Cargo feature	What it is	Docs
nest-rs-http	http	HTTP transport — controllers, routes, extractors, built on poem	HTTP
nest-rs-graphql	graphql	Resolver discovery, schema composition, async-graphql integration	GraphQL
nest-rs-ws	ws	WebSocket gateways — self-mount on the HTTP transport	WebSockets
nest-rs-openapi	openapi	OpenAPI 3 document + bundled Swagger UI from the route table	OpenAPI
nest-rs-mcp	mcp	Model Context Protocol server over HTTP	MCP

Data

Crate	Cargo feature	What it is	Docs
nest-rs-database	database	ORM-agnostic executor seam — ambient request/job context any driver implements	Database · Writing a driver
nest-rs-seaorm	seaorm	First-class SeaORM integration — SeaOrmDatabaseModule, Repo, transactions, dataloaders	Database
nest-rs-resource	resource	#[expose] — one entity declaration for GraphQL + OpenAPI + CRUD helpers	CRUD · Relations
nest-rs-storage	storage	S3-compatible object storage — injectable Storage, presigned URLs, via object_store	Storage

Security

Authentication answers who; authorization answers what they may do. Product-specific strategies and policies live in your features crate — these crates are the engine.

Crate	Cargo feature	What it is	Docs
nest-rs-authn	authn	JWT service, pluggable Strategy, AuthnGuard	Authentication
nest-rs-authz	authz	Ability-based authorization — access gate, row-level filter, response masking	Authorization
nest-rs-oauth-server	oauth-server	The OAuth 2.0 authorization server role — RFC 6749 §5.2 token-endpoint errors, §2.3.1 client authentication	Split deployment
nest-rs-oauth-client	oauth-client	The OAuth 2.0 client role — Authorization Code flow with PKCE against someone else’s authorization server	OAuth 2.0
nest-rs-oauth-resource	oauth-resource	RFC 9728 protected-resource metadata — the well-known document, and the 401 challenge pointer	Split deployment
nest-rs-social	social	Open SocialProvider contract — first-party GitHub/Google, third-party providers via the same seam	Social login

Request pipeline

Cross-cutting layers shared across HTTP, GraphQL, and WebSockets. Bind them globally on App::builder() or per controller / resolver / gateway.

Crate	Cargo feature	What it is	Docs
nest-rs-guards	guards	The Guard trait — gates access before the handler runs	Guards
nest-rs-pipes	pipes	Stateless input validation and transformation at the edge	Pipes
nest-rs-interceptors	interceptors	Wrap handler execution — logging, transactions, ability scope	Interceptors
nest-rs-filters	filters	Map inner errors to transport responses	Exception filters
nest-rs-exception-filters	exception-filters	Typed exception filters — catch one concrete error type	Exception filters

Background work

Crate	Cargo feature	What it is	Docs
nest-rs-queue	queue	Backend-agnostic job contract + #[process] registry	Queue
nest-rs-redis	redis	Redis-backed producer and worker (via oxana)	Queue wiring
nest-rs-schedule	schedule	Cron-style scheduled jobs — #[scheduled] + ScheduleModule	Schedule
nest-rs-events	events	Typed in-process event bus — #[listeners] / #[on_event]	Events
nest-rs-worker	worker	Ambient job context seam for off-request transports	Queue · Writing a driver

Platform

Crate	Cargo feature	What it is	Docs
nest-rs-config	config	Namespaced env + file config bound to typed #[config] structs	Configuration
nest-rs-health	health	Kubernetes-style liveness / readiness / startup probes	Health
nest-rs-throttler	throttler	Per-route rate limiting via ThrottlerGuard	Throttler
nest-rs-opentelemetry	opentelemetry	Logs, traces, metrics, W3C propagation, OTLP export	OpenTelemetry
nest-rs-server-timing	server-timing	W3C Server-Timing response header (independent of OTel)	Server-Timing

Developer tools

Crate	Cargo feature	What it is	Docs
nest-rs-cli	(binary: nestrs)	Scaffold workspaces, generate features, project health checks	CLI
nest-rs-testing	testing	In-process harness — boot the real DI graph, drive HTTP/GraphQL/MCP without a socket	Testing

Typical binary profiles

These are composition patterns, not separate crates — they show which packages a deployable usually pulls in.

Binary role	Packages you typically import
REST + OpenAPI API	http, openapi, config, seaorm, authn, authz, health
GraphQL API	http, graphql, config, seaorm, authn, authz
WebSocket live service	http, ws, config, seaorm, authn, authz
Queue worker	queue, redis, schedule, seaorm, config
MCP assistant	http, mcp, config, authn, authz
Token issuer	http, config, seaorm, authn

See The Publish workspace for five real apps that follow these profiles.

Not listed here

Internal macro crates (nest-rs-*-macros, nest-rs-codegen) implement the decorators — you never add them as direct dependencies; the surface crate re-exports what you need. For a decorator index see Decorators.

Your product’s features crate holds domain modules (entities, services, controllers per transport). It is workspace-local and not published to crates.io — copy crates/features/src/users/ as the exemplar.

Adding a capability to your app

Turn on its feature. There is one framework line, and adding a transport never adds a second — this is the real apps/api/Cargo.toml (REST + GraphQL + DB + authz), trimmed to the framework line:

apps/api/Cargo.toml (from the demo)

[dependencies]
nest-rs = { workspace = true, features = [
    "http", "config", "seaorm", "graphql", "openapi", "authn", "authz", "health",
] }

In a fresh project the same step is cargo add nest-rs --features <capability> — exactly what each module’s adoption page shows. Then import the matching modules in AppModule — for example HttpModule::for_root(...), SeaOrmModule::for_root(...), GraphqlModule, AuthzModule. The Publish workspace and Getting started walk through a full composition.

Why one entry is enough

A decorator is a procedural macro, and its expansion resolves paths against your crate’s extern prelude. NestRS decorators root theirs at ::nest_rs::<concern>::…, which that single entry reaches — so the feature list is the install. Nothing a decorator expands into is a line you write.

Get the dependency wrong and the compiler says so in your own terms:

error: this nestrs decorator expands into the framework, which this crate
       cannot reach. Add to Cargo.toml:

The message does not stop there — it ends on the complete nest-rs = { … } line to paste, carrying the version the decorator that failed to resolve was built from and the features it needs. That line is elided here on purpose: printed by the compiler it is always current, and written on this page it would go stale at the next release.

Get the feature wrong — the likelier mistake, since the dependency is already there — and the diagnostic is rustc’s own. A missing feature reads as a missing item, with a note telling you which:

error[E0433]: failed to resolve: could not find `seaorm` in `nest_rs`
   |
   = note: found an item that was configured out
   = note: the item is gated behind the `seaorm` feature

Add the feature named in the note to the nest-rs line — never a second crate.

The nest-rs-* crates stay published and keep their names — they are separate compilation units, which is what makes an unused capability free. They are not the entry point, and renaming the nest-rs dependency is unsupported: the same limit tokio has, for the same reason.

What stays in your manifest

Crates your own code names. A job payload deriving serde::Serialize, an indicator returning anyhow::Result, an entity written against sea-orm — those are yours, and hiding them behind a re-export would cost you their feature flags and a truthful cargo tree. No Rust framework hides them; NestRS does not either.

GraphQL used to be the one exception, and no longer is: #[operations] wraps async-graphql’s #[Object], but it now pins that expansion to the framework’s own re-export, so nest-rs --features graphql alone compiles a resolver. async-graphql returns to the rule above — yours when your code names it, which for its types you can avoid entirely with use nest_rs::graphql::async_graphql::{Context, Result};, and for its derives you cannot, exactly as for serde.

Going further

• Getting started — scaffold an app and write the first route.
• The Publish workspace — five apps that follow these binary profiles.
• Fundamentals — the DI container every capability wires into.