NestJS Lifecycle Hooks Explained: OnModuleInit and OnApplicationBootstrap

You've already used OnModuleInit twice in this course, once in Module 3's PrismaService, and implicitly through NestJS's own bootstrapping process. This lesson zooms out to cover NestJS's complete application lifecycle, every hook available, the precise order they run in, and why choosing the right one matters for correctness.

NestJS Lifecycle Hooks: Learning Objectives

• List every major lifecycle hook NestJS provides, in their execution order.
• Explain the specific timing difference between OnModuleInit and OnApplicationBootstrap.
• Implement a lifecycle hook to run startup logic like a database connection or cache warm-up.
• Understand the application shutdown hooks and when they're triggered.
• Enable and use shutdown hooks for graceful cleanup on application termination.

NestJS Lifecycle Hooks: Key Terms and Definitions

• Lifecycle hook: A method NestJS automatically calls at a specific point during an application's startup or shutdown, implemented by adding the corresponding interface to a provider or module.
• OnModuleInit: A hook called once a module's dependencies have been resolved, but before the application starts listening for requests.
• OnApplicationBootstrap: A hook called after all modules have been initialized, but still before the application starts listening for requests.
• OnModuleDestroy / OnApplicationShutdown: Hooks called during application shutdown, allowing for graceful cleanup like closing database connections.
• enableShutdownHooks(): A method called on the NestJS application instance to activate listening for shutdown signals (like SIGTERM) so shutdown hooks actually run.

How NestJS Lifecycle Hooks Works: Detailed Explanation

NestJS runs through a well-defined sequence of lifecycle events every time an application starts, and understanding the exact order matters whenever your startup logic has dependencies on other parts of the application being ready first. The sequence begins with each module's providers being instantiated and having their dependencies injected. Once a specific module's own dependency graph is fully resolved, any provider within it implementing OnModuleInit has its onModuleInit() method called, which is why PrismaService in Module 3 used this hook specifically to establish its database connection: by this point, PrismaService itself is fully constructed and ready to initiate that connection.

After every module across the entire application has had its OnModuleInit hooks called, NestJS moves to the next phase, calling OnApplicationBootstrap on any provider implementing it. The distinction is subtle but important: OnModuleInit runs per-module, potentially while other modules are still initializing, whereas OnApplicationBootstrap is guaranteed to run only after the entire application's module graph has finished its OnModuleInit phase. This makes OnApplicationBootstrap the right choice for logic that needs to assume every other part of the application is already fully initialized, such as a service that needs to query another module's already-connected database on startup.

Only after both of these phases complete does NestJS actually start listening for incoming HTTP requests (or begin consuming from a message queue, in a microservice context), meaning both hooks are guaranteed to complete before your application can receive any real traffic.

On the way down, NestJS provides a mirrored set of shutdown hooks: OnModuleDestroy, called as the application begins shutting down, and OnApplicationShutdown, called afterward, similarly allowing you to distinguish between per-module cleanup and cleanup that should assume every module is already shutting down. Critically, these shutdown hooks do not run automatically; you must explicitly call app.enableShutdownHooks() (typically in main.ts, right after creating the application instance) to tell NestJS to actually listen for termination signals like SIGTERM (commonly sent by container orchestrators like Kubernetes during a graceful pod shutdown) and trigger these hooks accordingly, allowing your application to, for example, close database connections cleanly rather than being abruptly killed mid-transaction.

Interview-Friendly Explanation

A strong interview or viva answer for nestjs lifecycle hooks must go beyond a one-line definition. Interviewers evaluating experienced backend developers reward answers that combine a precise definition, a clear working explanation, a real-world example, and a conclusion that highlights why it matters in production Node.js applications. Use the four-point framework below when answering under time pressure.

• Definition point: Lifecycle hook: A method NestJS automatically calls at a specific point during an application's startup or shutdown, implemented by adding the corresponding interface to a provider or module.
• Working point: Explain the specific timing difference between OnModuleInit and OnApplicationBootstrap.
• Example point: Database connection setup (as seen with PrismaService in Module 3) almost universally uses OnModuleInit, since establishing a connection is naturally scoped to that specific module's own readiness.
• Conclusion point: NestJS's lifecycle is a precise, well-ordered sequence, and choosing the right hook depends on exactly what your logic can safely assume is already ready.

How to Answer This in a Technical Interview

1. Give a two-to-three sentence definition using correct NestJS and Node.js terminology.
2. Add one specific example drawn from a real backend scenario such as an e-commerce, fintech, or SaaS API.
3. Mention a relevant trade-off or alternative approach, since interviewers often probe this contrast.
4. Close with one benefit, limitation, or production use case.
5. Avoid vague answers that only restate the term — interviewers filter these out immediately.

Practical Scenario

Imagine you are scaling a production backend for a SaaS product, similar to systems used at companies like Razorpay, Freshworks, or Zomato. Every lesson in this module maps directly to a decision you will make while making that backend more advanced, performant, and maintainable at scale.

NestJS Lifecycle Hooks: Architecture and Flow Diagram

Visualize the full lifecycle sequence, startup to shutdown:

[Module providers instantiated, dependencies injected] --> [OnModuleInit called per module] --> [OnApplicationBootstrap called once, application-wide] --> [Application starts listening for requests]

... running ...

[Termination signal received (e.g. SIGTERM)] --> [OnModuleDestroy called per module] --> [OnApplicationShutdown called once, application-wide] --> [Process exits]

NestJS Lifecycle Hooks: Hook Reference Table

Hook	Timing	Typical Use Case
OnModuleInit	After a module's own dependencies resolve, per-module	Establishing a database connection (e.g. PrismaService)
OnApplicationBootstrap	After every module's OnModuleInit has completed, application-wide	Logic assuming the entire app is already initialized
OnModuleDestroy	During shutdown, per-module	Per-module cleanup, like unsubscribing from an event
OnApplicationShutdown	During shutdown, application-wide (after OnModuleDestroy)	Final cleanup assuming every module is already shutting down

NestJS Lifecycle Hooks: NestJS Code Example

import { Injectable, OnModuleInit, OnApplicationBootstrap, OnModuleDestroy, OnApplicationShutdown } from '@nestjs/common';

@Injectable()
export class CacheWarmerService implements OnModuleInit, OnApplicationBootstrap, OnModuleDestroy, OnApplicationShutdown {
  async onModuleInit() {
    console.log('CacheWarmerService: this module\'s own dependencies are ready');
  }

  async onApplicationBootstrap() {
    console.log('CacheWarmerService: the ENTIRE application has finished initializing — safe to warm the cache now');
    // Safe to assume every other module's database connections, etc. are ready
  }

  async onModuleDestroy() {
    console.log('CacheWarmerService: shutting down, this module is cleaning up');
  }

  async onApplicationShutdown(signal?: string) {
    console.log(`CacheWarmerService: application-wide shutdown, received signal: ${signal}`);
  }
}

// main.ts — enabling shutdown hooks so OnModuleDestroy/OnApplicationShutdown actually run
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.enableShutdownHooks(); // without this, shutdown hooks are never triggered
  await app.listen(3000);
}
bootstrap();

CacheWarmerService implements all four major lifecycle interfaces to demonstrate their distinct timing. Its onModuleInit() runs once this specific service's own dependencies are ready, but potentially while other modules are still initializing. Its onApplicationBootstrap() is guaranteed to run only after every module in the entire application has completed its own OnModuleInit phase, making it the safe place to perform cache warming logic that might need to query data from other, now-guaranteed-to-be-ready parts of the application. The two shutdown hooks mirror this same per-module versus application-wide distinction. Crucially, main.ts calls app.enableShutdownHooks() before app.listen(); without this call, NestJS would never listen for termination signals, and onModuleDestroy() and onApplicationShutdown() would simply never execute, even though they're correctly implemented.

Real-World NestJS Lifecycle Hooks Industry Examples

• Database connection setup (as seen with PrismaService in Module 3) almost universally uses OnModuleInit, since establishing a connection is naturally scoped to that specific module's own readiness.
• Cache warming services, which need to pre-load frequently accessed data on startup, commonly use OnApplicationBootstrap specifically because they often need to query data from other, already-initialized parts of the application.
• Applications deployed on Kubernetes rely on enableShutdownHooks() and OnModuleDestroy/OnApplicationShutdown to gracefully close database connections and finish in-flight requests when a pod receives a SIGTERM signal during a rolling deployment or scale-down.
• Message queue consumers (RabbitMQ, Kafka) frequently use OnModuleDestroy to explicitly unsubscribe or acknowledge in-flight messages before the application process actually terminates, preventing message loss or duplicate processing.

NestJS Lifecycle Hooks Interview Questions and Answers

Q1. What is the key timing difference between OnModuleInit and OnApplicationBootstrap?

Short answer: OnModuleInit runs once a specific module's own dependencies have resolved, potentially while other modules in the application are still initializing. OnApplicationBootstrap runs only after every module across the entire application has completed its OnModuleInit phase, making it the safe choice for logic that needs to assume the whole application is fully ready.

Detailed explanation: NestJS runs through a well-defined sequence of lifecycle events every time an application starts, and understanding the exact order matters whenever your startup logic has dependencies on other parts of the application being ready first. The sequence begins with each module's providers being instantiated and having their dependencies injected. Once a specific module's own dependency graph is fully resolved, any provider within it implementing OnModuleInit has its onModuleInit() method called, which is why PrismaService in Module 3 used this hook specifically to establish its database connection: by this point, PrismaService itself is fully constructed and ready to initiate that connection. After every module across the entire application has had its OnModuleInit hooks called, NestJS moves to the next phase, calling OnApplicationBootstrap on any provider implementing it. The distinction is subtle but important: OnModuleInit runs per-module, potentially while other modules are still initializing, whereas OnApplicationBootstrap is guaranteed to run only after the entire application's module graph has finished its OnModuleInit phase. This makes OnApplicationBootstrap the right choice for logic that needs to assume every other part of the application is already fully initialized, such as a service that needs to query another module's already-connected database on startup. Only after both of these phases complete does NestJS actually start listening for incoming HTTP requests (or begin consuming from a message queue, in a microservice context), meaning both hooks are guaranteed to complete before your application can receive any real traffic. On the way down, NestJS provides a mirrored set of shutdown hooks: OnModuleDestroy, called as the application begins shutting down, and OnApplicationShutdown, called afterward, similarly allowing you to distinguish between per-module cleanup and cleanup that should assume every module is already shutting down. Critically, these shutdown hooks do not run automatically; you must explicitly call app.enableShutdownHooks() (typically in main.ts, right after creating the application instance) to tell NestJS to actually listen for termination signals like SIGTERM (commonly sent by container orchestrators like Kubernetes during a graceful pod shutdown) and trigger these hooks accordingly, allowing your application to, for example, close database connections cleanly rather than being abruptly killed mid-transaction.

Practical example: Database connection setup (as seen with PrismaService in Module 3) almost universally uses OnModuleInit, since establishing a connection is naturally scoped to that specific module's own readiness.

Interview tip: Startup order: module dependencies resolved → OnModuleInit (per-module) → OnApplicationBootstrap (app-wide) → app starts listening.

Revision hook: NestJS's lifecycle is a precise, well-ordered sequence, and choosing the right hook depends on exactly what your logic can safely assume is already ready.

Q2. Why did PrismaService in an earlier lesson use OnModuleInit specifically, rather than OnApplicationBootstrap?

Short answer: Establishing a database connection is a concern local to that specific service and module; it doesn't need to wait for every other unrelated module in the application to finish initializing first, making OnModuleInit, which runs as soon as PrismaService's own dependencies are ready, the appropriate and sufficient choice.

Detailed explanation: CacheWarmerService implements all four major lifecycle interfaces to demonstrate their distinct timing. Its onModuleInit() runs once this specific service's own dependencies are ready, but potentially while other modules are still initializing. Its onApplicationBootstrap() is guaranteed to run only after every module in the entire application has completed its own OnModuleInit phase, making it the safe place to perform cache warming logic that might need to query data from other, now-guaranteed-to-be-ready parts of the application. The two shutdown hooks mirror this same per-module versus application-wide distinction. Crucially, main.ts calls app.enableShutdownHooks() before app.listen(); without this call, NestJS would never listen for termination signals, and onModuleDestroy() and onApplicationShutdown() would simply never execute, even though they're correctly implemented.

Practical example: Cache warming services, which need to pre-load frequently accessed data on startup, commonly use OnApplicationBootstrap specifically because they often need to query data from other, already-initialized parts of the application.

Interview tip: Shutdown order (only if enableShutdownHooks() is called): OnModuleDestroy (per-module) → OnApplicationShutdown (app-wide).

Revision hook: OnModuleInit vs OnApplicationBootstrap is fundamentally about per-module readiness versus whole-application readiness.

Q3. Why don't OnModuleDestroy and OnApplicationShutdown run by default, and how do you enable them?

Short answer: By default, NestJS doesn't listen for OS-level termination signals like SIGTERM, so these shutdown hooks would never be triggered even if implemented. Calling app.enableShutdownHooks() in main.ts explicitly activates this signal listening, ensuring the shutdown lifecycle actually runs when the application receives a termination signal.

Detailed explanation: NestJS runs through a precise, well-defined lifecycle on both startup and shutdown. During startup, each module's providers are instantiated, after which OnModuleInit runs per-module as soon as that module's own dependencies are ready, followed by OnApplicationBootstrap, which is guaranteed to run only after every module across the entire application has completed its OnModuleInit phase, making it the safe choice for logic depending on the whole application being ready. Only after both phases complete does the application start accepting requests. On shutdown, a mirrored pair of hooks, OnModuleDestroy and OnApplicationShutdown, allow for graceful, ordered cleanup, though these only run if app.enableShutdownHooks() has been explicitly called in main.ts to activate NestJS's listening for termination signals like SIGTERM. Understanding this exact sequence is essential for correctly placing startup and cleanup logic, avoiding subtle, hard-to-diagnose ordering bugs.

Practical example: Applications deployed on Kubernetes rely on enableShutdownHooks() and OnModuleDestroy/OnApplicationShutdown to gracefully close database connections and finish in-flight requests when a pod receives a SIGTERM signal during a rolling deployment or scale-down.

Interview tip: OnModuleInit is fine for self-contained setup (e.g. a DB connection); OnApplicationBootstrap is needed when depending on other modules being ready.

Revision hook: Shutdown hooks are opt-in via enableShutdownHooks(), a detail easy to overlook and forget in real projects.

Q4. In what real-world scenario would you specifically need OnApplicationBootstrap instead of OnModuleInit?

Short answer: A cache warming service that needs to query data managed by a different module's database connection would need OnApplicationBootstrap, since it must be certain that every other module, including the one owning that database connection, has already finished its own OnModuleInit phase before it's safe to run the warming query.

Detailed explanation: NestJS runs through a well-defined sequence of lifecycle events every time an application starts, and understanding the exact order matters whenever your startup logic has dependencies on other parts of the application being ready first. The sequence begins with each module's providers being instantiated and having their dependencies injected. Once a specific module's own dependency graph is fully resolved, any provider within it implementing OnModuleInit has its onModuleInit() method called, which is why PrismaService in Module 3 used this hook specifically to establish its database connection: by this point, PrismaService itself is fully constructed and ready to initiate that connection. After every module across the entire application has had its OnModuleInit hooks called, NestJS moves to the next phase, calling OnApplicationBootstrap on any provider implementing it. The distinction is subtle but important: OnModuleInit runs per-module, potentially while other modules are still initializing, whereas OnApplicationBootstrap is guaranteed to run only after the entire application's module graph has finished its OnModuleInit phase. This makes OnApplicationBootstrap the right choice for logic that needs to assume every other part of the application is already fully initialized, such as a service that needs to query another module's already-connected database on startup. Only after both of these phases complete does NestJS actually start listening for incoming HTTP requests (or begin consuming from a message queue, in a microservice context), meaning both hooks are guaranteed to complete before your application can receive any real traffic. On the way down, NestJS provides a mirrored set of shutdown hooks: OnModuleDestroy, called as the application begins shutting down, and OnApplicationShutdown, called afterward, similarly allowing you to distinguish between per-module cleanup and cleanup that should assume every module is already shutting down. Critically, these shutdown hooks do not run automatically; you must explicitly call app.enableShutdownHooks() (typically in main.ts, right after creating the application instance) to tell NestJS to actually listen for termination signals like SIGTERM (commonly sent by container orchestrators like Kubernetes during a graceful pod shutdown) and trigger these hooks accordingly, allowing your application to, for example, close database connections cleanly rather than being abruptly killed mid-transaction.

Practical example: Message queue consumers (RabbitMQ, Kafka) frequently use OnModuleDestroy to explicitly unsubscribe or acknowledge in-flight messages before the application process actually terminates, preventing message loss or duplicate processing.

Interview tip: enableShutdownHooks() must be explicitly called in main.ts for shutdown hooks to ever run.

Revision hook: Understanding this lifecycle deeply prevents subtle startup-order bugs that are otherwise difficult to diagnose.

NestJS Lifecycle Hooks MCQs and Practice Questions

1. Which lifecycle hook runs after every module's OnModuleInit has completed, application-wide?

1. OnModuleInit
2. OnApplicationBootstrap
3. OnModuleDestroy
4. constructor()

Answer: B. OnApplicationBootstrap

Explanation: OnApplicationBootstrap is guaranteed to run only after the OnModuleInit phase has completed across every module in the entire application, unlike OnModuleInit which runs on a per-module basis.

Concept link: Startup order: module dependencies resolved → OnModuleInit (per-module) → OnApplicationBootstrap (app-wide) → app starts listening.

Why this matters: NestJS's lifecycle is a precise, well-ordered sequence, and choosing the right hook depends on exactly what your logic can safely assume is already ready.

2. What must be called in main.ts for OnModuleDestroy and OnApplicationShutdown to actually run?

1. app.listen()
2. app.enableShutdownHooks()
3. app.init()
4. Nothing, they run automatically by default

Answer: B. app.enableShutdownHooks()

Explanation: app.enableShutdownHooks() must be explicitly called to make NestJS listen for termination signals like SIGTERM, without which the shutdown lifecycle hooks would never be triggered.

Concept link: Shutdown order (only if enableShutdownHooks() is called): OnModuleDestroy (per-module) → OnApplicationShutdown (app-wide).

Why this matters: OnModuleInit vs OnApplicationBootstrap is fundamentally about per-module readiness versus whole-application readiness.

3. Which hook is most appropriate for establishing a module-specific database connection, like in PrismaService?

1. OnApplicationBootstrap
2. OnModuleInit
3. OnApplicationShutdown
4. OnModuleDestroy

Answer: B. OnModuleInit

Explanation: OnModuleInit is appropriate for module-specific setup logic, like establishing a database connection, since it runs as soon as that specific service's own dependencies are ready, without needing to wait for unrelated modules.

Concept link: OnModuleInit is fine for self-contained setup (e.g. a DB connection); OnApplicationBootstrap is needed when depending on other modules being ready.

Why this matters: Shutdown hooks are opt-in via enableShutdownHooks(), a detail easy to overlook and forget in real projects.

4. What OS-level signal commonly triggers NestJS's shutdown hooks in a containerized environment like Kubernetes?

1. SIGKILL
2. SIGTERM
3. SIGSTOP
4. SIGHUP

Answer: B. SIGTERM

Explanation: SIGTERM is the standard termination signal sent by orchestrators like Kubernetes to request a graceful shutdown, which, once enableShutdownHooks() is called, NestJS listens for to trigger OnModuleDestroy and OnApplicationShutdown.

Concept link: enableShutdownHooks() must be explicitly called in main.ts for shutdown hooks to ever run.

Why this matters: Understanding this lifecycle deeply prevents subtle startup-order bugs that are otherwise difficult to diagnose.

Common NestJS Lifecycle Hooks Mistakes to Avoid

• Assuming OnModuleDestroy and OnApplicationShutdown run automatically without calling app.enableShutdownHooks() first.
• Using OnModuleInit for logic that actually depends on other, unrelated modules being fully initialized, when OnApplicationBootstrap is the correct choice.
• Performing expensive or blocking operations inside a lifecycle hook without proper async handling, potentially delaying application startup unexpectedly.
• Confusing NestJS's own lifecycle hooks with Node.js process events (like process.on('SIGTERM')), when NestJS's shutdown hook system already provides a structured way to handle this within the framework.

NestJS Lifecycle Hooks: Interview Notes and Exam Tips

• Startup order: module dependencies resolved → OnModuleInit (per-module) → OnApplicationBootstrap (app-wide) → app starts listening.
• Shutdown order (only if enableShutdownHooks() is called): OnModuleDestroy (per-module) → OnApplicationShutdown (app-wide).
• OnModuleInit is fine for self-contained setup (e.g. a DB connection); OnApplicationBootstrap is needed when depending on other modules being ready.
• enableShutdownHooks() must be explicitly called in main.ts for shutdown hooks to ever run.

Key NestJS Lifecycle Hooks Takeaways

• NestJS's lifecycle is a precise, well-ordered sequence, and choosing the right hook depends on exactly what your logic can safely assume is already ready.
• OnModuleInit vs OnApplicationBootstrap is fundamentally about per-module readiness versus whole-application readiness.
• Shutdown hooks are opt-in via enableShutdownHooks(), a detail easy to overlook and forget in real projects.
• Understanding this lifecycle deeply prevents subtle startup-order bugs that are otherwise difficult to diagnose.

NestJS Lifecycle Hooks: Summary

NestJS runs through a precise, well-defined lifecycle on both startup and shutdown. During startup, each module's providers are instantiated, after which OnModuleInit runs per-module as soon as that module's own dependencies are ready, followed by OnApplicationBootstrap, which is guaranteed to run only after every module across the entire application has completed its OnModuleInit phase, making it the safe choice for logic depending on the whole application being ready. Only after both phases complete does the application start accepting requests. On shutdown, a mirrored pair of hooks, OnModuleDestroy and OnApplicationShutdown, allow for graceful, ordered cleanup, though these only run if app.enableShutdownHooks() has been explicitly called in main.ts to activate NestJS's listening for termination signals like SIGTERM. Understanding this exact sequence is essential for correctly placing startup and cleanup logic, avoiding subtle, hard-to-diagnose ordering bugs.