Fastify v6 Preview — Backend Architecture Changes via V8 Serialization and createPlugin

Fastify recently released its v6 pre-release, completely overhauling the core mechanisms of this high-performance backend framework. This update aims for a major structural simplification, including removing the serialization library that has driven performance for a long time and introducing native V8 engine serialization. It also presents new plugin design standards to address global type pollution issues that have occurred in large-scale TypeScript monorepo environments.

1. Moving Away from fast-json-stringify toward V8 Native Serialization

The biggest change in the Fastify v6 architecture is the removal of the fast-json-stringify library—a key pillar of its high performance—from its dependencies, shifting instead to the Node.js V8 engine's native JSON serialization. This decision aims to improve framework maintainability by stripping away the complex schema compilation layer and leveraging the drastically improved object optimization performance of the latest V8 engine.

However, this change presents architectural challenges for backend developers beyond simple performance metrics. Previously, Fastify automatically removed extra fields not present in the defined response schema during the serialization stage, acting as a form of security filter. Since this automatic filtering is removed with the transition to native serialization, there is a risk that unintended sensitive data or extra database fields could be exposed in the response payload.

To prevent these security gaps, safeguards should be implemented starting from the data entry point. It is recommended to design your application by strictly enabling the removeAdditional option in your Ajv configuration, which handles schema validation, to automatically strip extra fields. Because the implicit filtering previously guaranteed by the framework has moved to the realm of explicit schema control, response and input schema definitions must now be managed much more carefully.

2. Type Safety Without Global Pollution: The Arrival of createPlugin

The global type pollution issue, which was a major headache in TypeScript monorepo environments, has finally been resolved with the arrival of Fastify v6 and fastify-plugin v6.0.0. Previously, extending decorator or plugin types relied on global declaration merging, which frequently caused issues where types in other sub-services that did not inject the plugin were also distorted.

The newly introduced createPlugin helper perfectly blocks this global type pollution. Instead of forcing an extension of the global namespace, it isolates custom decorators and context types within the scope where the plugin is actually registered, safely propagating them to lower-level router trees.

By combining this with a TypeBox-based type provider, you can achieve safe request type inference at the compiler level without needing separate global type declaration files.

typescript

import { createPlugin } from 'fastify-plugin';
import { TypeBoxTypeProvider } from '@fastify/type-provider-typebox';
import { Type } from '@sinclair/typebox';

export const userPlugin = createPlugin(async (fastify) => {
  const server = fastify.withTypeProvider<TypeBoxTypeProvider>();
  const UserSchema = Type.Object({ name: Type.String() });

  server.post('/users', { schema: { body: UserSchema } }, async (request) => {
    const { name } = request.body; // 컴파일 단계에서 자동으로 타입 추론
    return { hello: name };
  });
});

By applying this pattern, multiple microservices within a large project will not affect each other's type declarations at all. Developers can immediately catch logical mistakes at compile-time where they might try to access a module or decorator that was not actually injected during application build.

3. Separation of LogController and Breaking Errors for Old FSTDEP Warnings

In Fastify v6, top-level properties that adjusted global logging options for server instances have been completely removed. Global options like disableRequestLogging or requestIdLogLabel can no longer be used. Instead, the structure has been completely reorganized to require instantiating a separately designed LogController class and injecting it into the logController property of the server options.

This change prevents server configuration flags from increasing indiscriminately and cleanly isolates logging concerns. Below is the configuration for logging settings before and after the change.

typescript

// 이전 방식 (Fastify v5)
const server = Fastify({
  disableRequestLogging: true,
  requestIdLogLabel: 'tx-id'
});

// 변경된 방식 (Fastify v6)
import { LogController } from 'fastify';

const server = Fastify({
  logController: new LogController({
    disableRequestLogging: true,
    requestIdLogLabel: 'tx-id'
  })
});

Legacy code that previously only printed terminal warnings to maintain backward compatibility has also been cleaned up more strictly. Options that only displayed warning messages ranging from FSTDEP022 to FSTDEP025 in v5 have been converted into fatal errors that immediately stop server startup in v6. This is a measure to ensure stability by blocking applications with configuration errors from being deployed to production environments at an early stage.

4. NestJS Compatibility Warnings and Plugin Ecosystem Transition Status

When considering the introduction of Fastify v6, the first thing to check is the compatibility of your higher-level framework ecosystem. If you are operating a NestJS-based architecture, you should avoid an immediate migration to v6. Currently, the official NestJS adapter @nestjs/platform-fastify is locked to Fastify v5 and is not perfectly synchronized at the interface level.

If you force an override to inject Fastify v6 into a NestJS project via package manager settings, the server may fail to start entirely due to serious dependency conflicts or routing binding failures during the application bootstrap phase. While the NestJS development team is preparing by organizing the internal configuration structure, it is safer not to attempt a manual transition in a production environment until the official adapter fully supports v6.

On the other hand, if you have a standalone project built with pure Fastify—stripping away framework abstraction layers—you can be much more flexible with your migration schedule. Key ecosystem plugins such as @fastify/swagger-ui and @fastify/autoload have already established reliable v6 support. Therefore, I recommend planning a gradual transition to v6 starting with microservices or standalone API servers that do not have framework dependencies.

5. Conclusion: A Roadmap for Preparing for the Upcoming Fastify v6 Era

Once the official version of Fastify v6 is released, the existing v5 will immediately move to a status of receiving only security updates for 6 months. Therefore, you should prepare in advance for core architectural changes, such as the introduction of createPlugin to block global type pollution and the reorganization of the logging structure based on LogController. By reducing type declaration merging and building a TypeBox-centric integrated validation system now, you can easily adapt to the upcoming major update.

Reference links

Comment

Haram@haram20 days ago
V8 네이티브 직렬화로 가면서 추가 필드가 그냥 노출될 수 있다는 점은 보안상 꼭 기억해둬야겠네요. 그래도 createPlugin 덕분에 모노레포에서 타입 오염 걱정 없이 깔끔하게 격리되는 건 정말 마음에 듭니다 ㅎㅎ
1. Maru@maru20 days ago
  맞아요 하람님. 예전엔 프레임워크가 알아서 필터링해주던 걸 이제는 Ajv의 removeAdditional이나 TypeBox의 Clean 유틸리티 같은 도구로 명시적으로 처리해야 하니 보안 위생에 더 신경 써야 할 것 같아요. 그리고 createPlugin은 대규모 모노레포에서 타입스크립트 컴파일 성능도 대폭 개선해주고 로컬 격리를 확실하게 해줘서 진짜 유용한 것 같습니다. 혹시 기존 프로젝트 구성하시면서 전역 타입 유출 때문에 골치 아프셨던 적이 있으신가요?
아이라@aira20 days ago
createPlugin 덕분에 모노레포에서 전역 타입 오염 없이 격리되는 건 진짜 반가운 변화네요~ V8 네이티브 전환으로 스키마 보안 필터링 직접 챙겨야 하는 점도 마이그레이션할 때 핵심 포인트인 것 같습니다.
1. Maru@maru20 days ago
  맞아요 ㅎㅎ 특히 모노레포에서 매번 d.ts 파일 선언 병합하느라 골치 아팠는데 이제 해방이네요! 그리고 데이터 필터링을 직렬화 단계에서 암시적으로 해주기보다는 Ajv의 removeAdditional 설정처럼 검증 레이어에 명시적으로 위임하는 게 장기적으로는 더 건강한 아키텍처 아닐까 싶어요. 마이그레이션은 꼼꼼히 챙겨야겠지만요 ㅎㅎ 혹시 다른 프레임워크 쓰시면서 민감한 필드가 응답으로 잘못 나갔던 경험 있으신가요?