NestJS v12.3.0, v12.2.0 and v11.2.8: Native Node HTTP Adapter

• Release date: v12.3.0 is dated 2026-10-27 in its release notes.
• Feature: a native Node HTTP platform adapter, #18063, in platform-node.
• Security tag: multer is updated to v2.5.0 (#18268, platform-express).
• Express: 5xx http-errors errors are left unmapped so they are logged (#18232).
• Fastify: 4xx http-errors errors map to HttpException (#18239); 5xx Fastify errors are left unmapped (#18240).
• Microservices: the TCP server is retried again after close and listen (#18238), and RMQ counts every failed connection attempt (#18204).
• Uploads: unsupported multipart content types on Express map to 415 (#18264).

Native Node HTTP Platform Adapter in platform-node #

The lead change is a native Node HTTP platform adapter (#18063) in platform-node, credited to kamilmysliwiec and listed under Features in the v12.3.0 release notes. No other v12.3.0 entry names platform-node, so the adapter stands apart from the Express, Fastify and transport fixes that make up the rest of the release.

feat(node): add a native node http platform adapter

NestJS v12.3.0 release notes

The release notes do not say how an application selects this adapter, so the steps for adopting it are not covered here. Teams that stay on their current platform still have the error, upload and transport changes below to review, since those entries sit in the Express, Fastify, microservice and core code.

HTTP Error Mapping and Logging on Express and Fastify #

On Express, #18232 leaves 5xx http-errors errors unmapped so they are logged, #18214 maps http-errors exceptions to HttpException in the Express adapter, and #18199 sends the standard body for an exception that wraps an error. This suggests that exception filters matching HttpException will receive fewer of the 5xx http-errors errors on Express, while those errors still reach the logs. Both changes are listed in the v12.3.0 release notes.

On Fastify, #18239 maps 4xx http-errors errors to HttpException, and #18240 leaves 5xx Fastify errors unmapped so they are logged. #18253 sends object error bodies with a JSON content type. Exception filters that handled 4xx http-errors on Fastify as plain errors need to be checked against the new mapping.

The v12.2.0 notes add two related rules. BaseExceptionFilter answers http-errors errors created with expose: false, which default from 500, with the standard reason phrase instead of their message. Object error bodies on Express routes with a non-JSON Content-Type are sent as application/json. Together with the v12.3.0 mapping, these rules decide what a client sees for a server error, so the two releases should be read together.

Multer 2.5.0 Security Update and 415 for Unsupported Multipart Types #

#18268 updates multer to v2.5.0 under a [security] tag in the platform-express package, submitted by renovate[bot]. multer v2.5.0 under a security tag is the dependency change to verify first in any Express project that accepts uploads, by confirming the resolved version is 2.5.0 or later. The v12.3.0 notes carry the tag without describing the issue it addresses.

#18264 maps unsupported multipart content types to 415 on Express. #18289 reports the detected file type in file type errors, and #18257 updates file-type to v22.2.0 in the common package. This suggests that upload handlers which match on the previous error text will need review against the 415 status and the new file type message.

The v12.2.0 notes also change FileTypeValidator: a string fileType matches up to the end of a name, so font/woff no longer accepts font/woff2, and a RegExp is needed to match that case.

Middleware Exclusions and CORS Order on Fastify #

#18276 runs middleware once for routes that differ only in version, #18209 lets middleware exclusions cover routes excluded from the prefix, and #18201 reads a quoted media type version in the exclusions. These fixes sit alongside the optional HttpServer.getRouteMatchingOptions() hook that the v12.2.0 notes introduced to tell core how the router matches paths.

The v12.2.0 notes state the consequence for adapters without that hook.

with an adapter that does not implement getRouteMatchingOptions() , excluded routes are matched exactly

NestJS v12.2.0 release notes

On a lenient router, other spellings of an excluded path then run the middleware. The same notes ask that @nestjs/core be updated together with @nestjs/platform-express or @nestjs/platform-fastify, so an application with exclusions should move core and the adapter in one step.

On Fastify, #18217 runs CORS before Nest middleware, and the v11.2.8 notes list the same change as a backport. The v12.2.0 notes also run the request hook used by enableCsrfProtection() and useSecurityHeaders() before Nest and app.use() middleware, including with NestFactory.create().

Microservice Retry and Reply Handling Across Transports #

The v12.1.3 notes list cancelling pending TCP retries on close (#17988). v12.3.0 continues that retry handling: the TCP server is retried again after close and listen (#18238), the retry timer is cleared when a new listen starts (#18223), and the retry attempts reset on each listen (#18206). TCP retry attempts reset on each listen. This suggests that each listen begins a fresh retry cycle, and #18250 applies the same re-arming to Redis retries on a new listen.

#18204 counts every failed RMQ connection attempt, and #18255 reports a NATS connection that gave up reconnecting. This suggests that alerts built on RMQ failure counts or NATS reconnect reports may show more entries after the upgrade.

Reply handling changed too. #18229 lets only the exact message handler answer a request, #18211 fails the request when its last reply cannot be sent, and #18256 lets a retriable exception keep travelling. #18249 stops sending a trailing null to Kafka requesters, and #18197 sends NATS record headers as message headers.

Defaults Changed in v12.2.0 for Projects Moving Past It #

Projects that move from v12.1.x to v12.3.0 cross the v12.2.0 release, whose notes list the following changed defaults and behaviour. validationError.target now defaults to false, so review these items before the upgrade.

• ValidationPipe uses validationError.target: false unless the options set it, so an exceptionFactory that reads error.target gets undefined. Set validationError.target to true to keep the old errors.
• ValidationPipe answers an array or a primitive sent for a validated class with a 400.
• On Express and Fastify, fieldNestingDepth and fieldArrayIndexLimit default to 32 and 1000; set them to Infinity to lift the limits.
• On Fastify, a route with fileSize undefined or null falls back to the plugin's limit; set it to Infinity to keep uploads unlimited.
• A StreamableFile error still gets a 400, but the body no longer carries the error message.
• Files uploaded with a request that a pipe rejected are removed from storage.
• A global enhancer that the injector failed to instantiate now fails the application at startup.
• MQTT reconnectOnConnackError is enabled by default, so a refused connection attempt is retried; set it to false for the previous behaviour.
• Kafka parser.maxMessageSize defaults to 16 MiB after decompression; larger messages are logged and skipped.
• Kafka messages may carry up to 10,000 header values, and headers given as a string or array are not sent.
• TCP drainTimeout defaults to 30 s, and 0 disables it; it disconnects a peer that leaves its responses unread.
• A microservice pattern key longer than 256 characters matches no handler.
• ConsoleLogger in JSON mode cuts a record short past about a million characters.

The v12.2.0 notes also add a deprecation. On TCP, Redis, NATS, MQTT and RabbitMQ, an @EventPattern() handler that replies to ClientProxy#send() now logs a deprecation warning, while the reply is unchanged. The notes state that in the next major version, event handlers will not reply to send(), as on Kafka already, so handlers that reply should be reviewed before that release.

Teams on Express, Fastify and Microservice Transports #

Express and Fastify teams should review the HTTP error mapping and the multer update first, because they change what reaches exception filters and the logs and because the dependency update carries a security tag. Microservice teams should review the retry and reply changes, and teams on the v11 line can take the backports of #18220, #18217, #18229 and #18221 from the v11.2.8 notes.

1. Confirm that the resolved multer version is 2.5.0 or later.
2. Update @nestjs/core together with @nestjs/platform-express or @nestjs/platform-fastify.
3. Check exception filters against the 5xx mapping on Express and the 4xx mapping on Fastify.
4. Test upload handlers that match on error text against the 415 status and the new file type message.
5. Review the defaults and deprecation listed for v12.2.0.

Also in This Release #

the full list is in the v12.3.0 release notes. The notes list more fixes than this brief covers, and the v12.3.0 release notes hold the complete set. The remaining entries that a reader may want to check are:

• #18251 loads adapters with an older core for core, express, fastify, ws and socket.io.
• #18226 lets Fastify listen on a file descriptor.
• #18285 loads the ws and microservices packages where bundlers can see them.
• #18252 reads the URL protocol from the server.
• #18254 names the array and index of undefined module entries.
• #18235 discovers classes by each of their discovery decorators.
• #18246 stops throwing for arrow prototype constructors.
• #18272 keeps one route param per argument in an overriding method.
• #18262 tolerates SSE request sockets without tuning methods.
• #18200 resolves request-scoped forward references for concurrent requests.
• #18216 and #18210 honor the abortOnError option of the app being called and the one passed to select().
• #18215 subscribes to handler observables from other rxjs copies.
• #18219 updates @fastify/middie to v9.3.6.