NestRS

~25× less memory · ~23× faster cold starts · ×4 the throughput of NestJS, core for core
Scalable Rust backend apps — measured on a byte-identical contract, reproducible from the repo.
_{Measured in a 4-core / 8 GB Docker VM (Apple Silicon) — virtualized, not peak native: bare-metal figures only go up.}

What it is

You write business logic; the framework carries the rest — authn, authz, row-level tenant filtering, per-field masking, transactions, discovery, and lifecycle. Those concerns are transparent to your code and verified at boot, not left to review discipline.

A full authenticated, tenant-scoped, transactional, field-masked CRUD resource is an empty impl block:

#[controller(path = "/orgs")]
#[use_guards(AuthnGuard, AuthzGuard)]
pub struct OrgsController {
    #[inject]
    svc: Arc<OrgsService>,
}

#[crud(service = svc, entity = OrgEntity, output = Org,
       create = CreateOrg, update = UpdateOrg)]
impl OrgsController {}

The differentiator is structural multi-tenant isolation you cannot forget: row-level filtering, response masking, and transactions become non-optional the moment the security modules are imported. A feature opts out by not importing them. In NestJS, Spring, Rails, axum, or Loco, tenant filtering is discipline — a scope you remember, a middleware you apply, a review comment. In NestRS it is structural: the data layer applies it from the caller's ability, and an operation with no declared access posture is refused — at compile time on GraphQL, at boot on HTTP. MCP gets the same guarantee across the whole protocol, not tools/call alone: scope, ability and transaction reach prompts/get, resources/read, completion and the tasks/* trio, so a Repo-backed prompt is row-filtered exactly like a controller.

The numbers behind the tagline — against the same hello-world service in NestJS 11, idiomatic on both sides, byte-identical HTTP contract, conformance-gated: NestRS runs in ~25× less memory (single-digit MB against ~200 MB), cold-starts ~23× faster (milliseconds against near half a second), and — core for core, each server pinned to a single CPU — serves ×4.2 the throughput of NestJS on Express (its default) — ×2.5 its best case, Fastify — with p99 latency cut to a third. Scaling out changes nothing: Node adds ~200 MB of process per core; one NestRS binary takes every core in a single single-digit-MB process. Where the Express service needs three boxes, one NestRS binary carries the load. Those figures come from a 4-core / 8 GB Docker VM — virtualized, so they are a floor, not a ceiling. The harness lives in bench/ — cd bench && just bench reproduces every figure on your own hardware.

Try it on your machine:

cargo install --locked nest-rs-cli
nestrs new hello --standalone && cd hello
nestrs run dev   # → Hello World on :3000

Adding NestRS to a crate you already have is one dependency. Every capability — http, graphql, seaorm, ws, mcp, queue, schedule, … — is a feature of the umbrella, and a feature you leave off is code you never compile. No decorator ever asks you to declare a second crate:

cargo add nest-rs --features http,seaorm

→ Why not axum? · Coming from NestJS · Why NestRS

Stability

NestRS is stable at 2.0 and ready for production. The public API is frozen for the 2.x line: breaking changes wait for 3.0. Every nest-rs-* crate publishes at the same version in lockstep, so one NestRS version names exactly one compatible resolution — down to the third-party crates that surface in your own signatures (poem, sea-orm, async-graphql, rmcp, schemars), whose majors are tied to the NestRS major and frozen for the whole 2.x line.

Coming from 1.x? CHANGELOG.md lists what moved: the install collapsed onto the nest-rs umbrella (a decorator's expansion now roots at the facade), and nest-rs-mcp moved to rmcp 3.x, which changes types that appear in the signatures an MCP host writes.

Documentation

Using NestRS? Head to nestrs.dev — getting started, tutorial, why NestRS, the axum comparison, and one section per capability crate.

Contributing to the framework? This README is your entry point. For design rules and conventions, read CLAUDE.md and CONTRIBUTING.md.

Contributing

Anyone who can clone the repo can iterate on the framework — the dev container brings up Rust, Postgres and Redis in one step.

Get the dev container running

1. Install Docker and the VS Code Dev Containers extension.
2. Open the repo in VS Code and accept Reopen in Container.
3. cd demo && nestrs run dev api — the main Publish API on http://localhost:3002 (run nestrs run db up first).

The container provisions the Rust toolchain and dev tooling (just, bacon, cargo-nextest, …), and brings up Postgres and Redis beside it with NESTRS_DATABASE__URL / NESTRS_QUEUE__URL already pointed at them. nestrs run dev runs under bacon — every save triggers an incremental rebuild and a restart. The runnable apps live in their own workspace under demo/ — cd demo first; that directory is where nestrs run, the .env cascade, and the database/test recipes resolve.

Prefer a local toolchain? See Getting started → Scaffold and start.

Project layout

Two Cargo workspaces, split along the framework/product line.

nestrs/
├─ crates/              the framework — nest-rs (the umbrella apps install)
│  │                     over one nest-rs-* compilation unit per capability
│  ├─ nest-rs-core/      IoC container, modules, DI, bootstrap
│  ├─ nest-rs-http/      REST controllers & routing
│  └─ …                 (members = ["crates/*"])
├─ docs/                the nestrs.dev site (Astro Starlight)
└─ demo/                the product — its own workspace, consumes the framework
   ├─ apps/              one runnable binary each (the Publish workspace)
   │  ├─ auth/   OAuth2 / JWT token issuer
   │  ├─ api/    REST + GraphQL + OpenAPI, persisted & authorized
   │  ├─ assistant/  Model Context Protocol server
   │  ├─ live/   real-time WebSocket gateway
   │  └─ worker/ background jobs & scheduling (headless)
   ├─ crates/
   │  ├─ features/       product features — port + adapters (users, posts, authn, …)
   │  ├─ migrations/     shared-database SeaORM migrations (CLI)
   │  └─ seed/           shared-database demo data (CLI)
   ├─ Justfile, db.just, test.just, .env*, Dockerfile
   └─ (members = ["apps/*", "crates/*"])

The demo/ workspace references the framework by relative path — one workspace dependency, nest-rs = { path = "../crates/nest-rs", features = [ …] }, exactly the shape a real app has — so it builds against the live framework source. You cd demo and drive it as if it were the app's own repository — see demo/README.md for running the apps, the command table, the Publish map, and Docker.

• crates/nest-rs-*/ — the framework: generic, product-agnostic building blocks, reached through the nest-rs umbrella rather than named one by one.
• demo/apps/<name>/ — main.rs + module.rs listing the edge modules the binary serves.
• demo/crates/features/ — the product's vertical slices; apps import the edges they serve.

Adding an app means a directory under demo/apps/; a new feature means a folder under demo/crates/features/src/; a new framework capability means a nest-rs-* crate under crates/. The hello and blog layouts are generated on demand by nestrs new rather than checked in, so they never drift from the framework — see Getting started and the tutorial.

Running the apps

Everything runnable lives in demo/ — cd demo first, then nestrs run (no args lists every recipe). The full command table, the Publish app map, and the Docker build are documented in demo/README.md.

Community & contributing

NestRS is stable at 2.0 and actively developed — contributors shape where it goes next, and you don't have to write Rust to help.

• 💬 Ask a question, propose an idea, or just say hi in Discussions.
• 🐛 Report a bug or request a feature through issues.
• 🌱 Pick up a good first issue — CONTRIBUTING.md is the short path from idea to merged PR.
• 🗺️ See where it's heading in the roadmap.
• 🔒 Found a vulnerability? Follow SECURITY.md — please don't open a public issue for it.

If NestRS is useful to you, a ⭐ helps other Rust teams find it.

License

MIT — see LICENSE.