The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
NestJS does not document a module-level guard binding. Its documented choices are controller-level, method-level, and application-wide guards. Registering APP_GUARD in a module does not limit that guard to the module: NestJS says it is global regardless of where the provider is declared. A request for automatic module-level binding appears in issue #15795, while an October 2026 article presents Holu as offering an import-time configuration for that scope.
What guard scopes does NestJS document?
NestJS documents three binding levels:
- Controller: apply a guard to a controller with
@UseGuards(), affecting its routes. - Method: apply a guard to a route handler with
@UseGuards(), limiting it to that handler. - Application-wide: register a guard through the
APP_GUARDprovider token so it applies globally.
The official guide explicitly clarifies that “regardless of the module where this construction is employed, the guard is, in fact, global.” In other words, declaring an APP_GUARD provider inside a feature module does not create a guard that applies only to controllers in that module. NestJS Guards documentation
Why doesn’t module organization provide module-scoped guards?
NestJS modules organize the application graph, including controllers and providers, and define provider visibility and imports. That architectural role is distinct from a guard’s execution scope. The modules guide describes how modules structure an application; it does not document a module-level guard-binding option. NestJS Modules documentation
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsSo “the guard is provided by this module” and “the guard runs only for this module’s controllers” are different claims. The documented behavior of APP_GUARD is the former declaration location with the latter expectation explicitly ruled out: it remains global.
#1 Best Overall
What does issue #15795 request?
NestJS issue #15795 asks for guards to apply automatically to every controller declared in a module. Its proposed wording is: “It would be great if NestJS allowed guards to be applied at the module level, so that all controllers declared in that module automatically use the guard.” The issue page is shown as closed and its development section lists no branch or pull request. That page establishes the existence and displayed state of this particular request; it does not explain why it was closed or establish the history of all requests on this subject. NestJS issue #15795
How can you handle guards with documented NestJS patterns?
Use controller or method decorators when you own the routes
Apply @UseGuards() to each controller that needs the guard, or to individual methods when access should differ by route. This is the direct documented approach when you can edit the target controllers.
Use a global guard with public-route metadata when appropriate
NestJS’s authentication guide shows a global APP_GUARD pattern alongside custom metadata to mark routes as public. This can centralize authentication while allowing explicitly public routes. It is not the same as module-scoped binding, and the reviewed documentation does not establish that it addresses every third-party or non-HTTP integration scenario. NestJS Authentication documentation
Account for ownership and integration boundaries
The practical choice depends on whether you can decorate the relevant controllers, whether a global policy is acceptable, and which transports or third-party modules are involved. The documented patterns do not provide a way to apply an enhancer across all controllers in one module without modifying them while leaving the rest of the application untouched.
Rank #3
What does the article claim Holu does differently?
An October 1, 2026 article presents Holu as allowing guards to be specified when importing a module, with configuration shaped like:
{ module: ApiModule, path: 'api', guards: [AuthGuard] }The same article says guard providers must be available in the importing module and mentions a createGuardHelper() facility for parameterized guards. These are claims made by that article, also republished on DEV Community; they have not been independently tested or verified against current Holu documentation here. They should be read as a description of the article’s proposed alternative, not as independently established compatibility or production results. Mango Developer article DEV Community republication
How should the “17 issues, 9 years, zero PRs” figures be read?
The figures come from the October 1, 2026 Mango Developer article, not from an official NestJS report or an independently audited issue analysis.
| Figure | What the article reports | Evidence qualification |
|---|---|---|
| 17 issues | Requests concerning module-scoped guards | Reported by Mango Developer; not independently audited across all issues. |
| 9 years | The reported span of those requests | The article’s historical summary; not independently verified as a measurement. |
| Zero implementation PRs | No implementation pull requests | Reported by the article; issue #15795 alone cannot verify that aggregate. |
The DEV Community page republishes the article, so it is not independent corroboration of those totals. The issue record is useful for confirming one concrete request, not for validating the full count or the explanation behind its status.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
