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.

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

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

Stability

NestRS is stable at 1.0 and ready for production. The public API is
frozen for the 1.x line: breaking changes wait for 2.0. Every nest-rs-*
crate publishes at the same version in lockstep, so one NestRS version names
exactly one compatible resolution.

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 — one nest-rs-* crate 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
(nest-rs-* = { path = "../crates/nest-rs-*" }), 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.
• 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 1.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.