nestjs-pino is a platform-agnostic logging module for NestJS, built on Pino, that binds request context into every log line — aimed at NestJS teams that want structured JSON logs without rewriting their existing logging calls.

What it is

nestjs-pino is a TypeScript logging module that plugs Pino and pino-http into a NestJS application. It lives in the NestJS ecosystem on Node.js, and its central promise is stated in its own tagline: request context in every log. Registration happens through LoggerModule.forRoot(...) or forRootAsync(...), and because the module is @Global(), both Logger and PinoLogger become injectable everywhere after that single root registration. The project ships under the MIT licence and is documented for version 5, with earlier majors maintained on separate branches.

The concrete problem it solves is the loss of request context in application logs, plus the cost of wiring an HTTP-aware logger by hand. It replaces NestJS's built-in ConsoleLogger as the application logger, and it packages the pino-http middleware wiring that a team would otherwise assemble itself. Its NativeLogger is a drop-in replacement for ConsoleLogger that produces identical JSON output — same field names, same argument handling, same error format — with the same message, context, level, timestamp, pid, and stack fields, but powered by Pino and with automatic request context binding.

Key capabilities

• NativeLogger as a drop-in replacement for NestJS's built-in ConsoleLogger, emitting identical JSON, so existing new Logger(MyService.name) calls keep working unchanged.
• Request context attached to every log through the pino-http middleware registered by the module.
• Logger as the Pino-native logger, where extra arguments are Pino interpolation values: this.logger.log('foo %s', 'bar') produces {"msg":"foo bar"}.
• NativeLogger matching ConsoleLogger argument parsing, where the last string is the context and the remaining strings become separate log entries.
• Structured params on NestJS 12, where plain objects after the message merge into a single params field (ConsoleLoggerOptions.structuredParams, on by default): this.logger.log('foo', { a: 1 }, { b: 2 }) produces {"message":"foo","params":{"a":1,"b":2}}.
• nativeLoggerOptions as a ready-made preset passed through pinoHttp, and error handling that keeps stack traces: this.logger.error('msg', stackTrace, 'Ctx') produces {"message":"msg","stack":"Error: ...","context":"Ctx"}.
• A published compatibility matrix: v5 targets NestJS 11.0.8+ and 12.0.2+, pino 10, pino-http 11, and Node.js >=22.12, while v4 covers NestJS 8 through 11, pino 7.5+ through 10, and Node.js >=14.

Who uses it and how

• NestJS applications already logging JSON through ConsoleLogger with { json: true } that want Pino's performance and request context without touching logging call sites.
• Services running NestJS 11.0.8+ or 12.0.2+ on Node.js >=22.12, with older stacks pinned to the v4 branch.
• Applications bootstrapped with bufferLogs: true and app.useLogger(app.get(NativeLogger)) to route NestJS framework logs through Pino.
• Teams that need per-request correlation in logs but do not want to thread request identifiers through service code manually.
• A contributor base drawn in partly through the hacktoberfest topic, with 1540 stars, 109 forks, and 12 open issues.

Getting started

Install the nestjs-pino package, then register LoggerModule.forRoot({ pinoHttp: nativeLoggerOptions }) once in the root module, optionally creating the app with NestFactory.create(AppModule, { bufferLogs: true }) and app.useLogger(app.get(NativeLogger)).

How it compares

Among the tools the facts name, nestjs-pino sits between NestJS's built-in ConsoleLogger, which is the thing it replaces, and the underlying pino and pino-http packages, which it wires together for the NestJS dependency injection model. It is not a separate logging backend; it is the NestJS integration layer over Pino, and its differentiator is producing ConsoleLogger-identical JSON while adding request context.

When to use it — and when not to

A self-hoster or application owner takes on the Pino and pino-http dependency chain and its version matrix, which v5 pins to Node.js >=22.12 and NestJS 11.0.8+/12.0.2+, so projects on older runtimes must stay on v4. The documented footgun is real: importing the bare LoggerModule into a feature module instantiates it again, registers the pino-http middleware twice, and makes every request log twice, with no compile error, injection failure, or warning (issue #3074). Teams that do not need structured logs, request context, or a Pino pipeline should keep the built-in ConsoleLogger instead.

import { NativeLogger, nativeLoggerOptions } from 'nestjs-pino';

@Module({
  imports: [LoggerModule.forRoot({ pinoHttp: nativeLoggerOptions })],
})
class AppModule {}

const app = await NestFactory.create(AppModule, { bufferLogs: true });
app.useLogger(app.get(NativeLogger));

{"level":"log","pid":17580,"timestamp":1765305000999,"message":"Hello World","context":"AppService"}

{"level":"log","pid":17580,"timestamp":1765305000999,"message":"Hello World","context":"AppService"}

LoggerModule.forRoot({
  pinoHttp: nativeLoggerOptions,
  nativeLogger: {
    // NestJS 12 default is `true`, NestJS 11 has no such option and behaves
    // as `false`. Omit it to follow the ConsoleLogger you actually have.
    structuredParams: true,
    // Spread params into the root of the record instead of nesting them
    // under `params`. NestJS default is `false`.
    flattenParams: true,
  },
});

{"level":"log","message":"foo","context":"AppService","a":1,"b":2}