Which strategy should I use for Fastify v5?
Teams still on Fastify 4 need a current migration decision that accounts for the Node 20 minimum, stricter full JSON schema requirements, and plugin compatibility risk in 2026 deployments.
Blockers
- framework/fastify-4 — EOL 2025-06-30
- requires_version: framework/fastify-5 → runtime/nodejs-20
- Full JSON schema is required for querystring, params, body, and response schemas; jsonShortHand removed.
- Lock-in via framework/fastify-5
- Lock-in via framework/fastify-5
- Lock-in via framework/fastify-5
- Lock-in via framework/fastify-5
Who this is for
- small-team
- enterprise
- monorepo
Candidates
Upgrade to Fastify v5 on Node 20+ and convert schemas first
Fastify v5 requires Node.js v20 or newer, and the official migration guide says full JSON schema is now required for querystring, params, body, and response schemas, with jsonShortHand removed. As of 2026-04-01, Fastify v4 support had already ended on June 30, 2025, so the supported path is to move to v5 rather than treat v4 as normal production baseline. The migration guide also calls out adjacent breaking changes such as loggerInstance replacing custom logger use in logger, semicolon query delimiters no longer defaulting on, and stricter AJV date-time and time handling.
When to choose
Use this when you can upgrade runtime and schema definitions in the same delivery window, especially for supported long-lived services. The decisive factor is that Fastify v4 is already out of support as of 2026-04-01, so v5 is the default choice unless plugin blockers are still unresolved.
Tradeoffs
You get back onto a supported framework line and reduce future drift, but you must budget for route-schema rewrites, regression testing around validation behavior, and some configuration updates outside schemas.
Cautions
Do not treat this as only a package bump. Official plugin majors often track Fastify majors, for example @fastify/swagger uses >=9.x for Fastify ^5.x, @fastify/swagger-ui uses ^5.x for Fastify ^5.x, and fastify-plugin metadata can explicitly enforce a Fastify 5.x range, so internal and third-party plugins need an audit before rollout.
Hold on Fastify 4 only as a short-term exception while you clear blockers
The official Fastify v5 migration guide states Fastify v4 was supported only until June 30, 2025, and recommends considering an end-of-life support plan from HeroDevs if you cannot upgrade. As of 2026-04-01, that support window had already passed, so staying on v4 is a conscious exception path rather than a normal steady state. This is mainly justified when Node 20 readiness, full JSON schema conversion, or plugin replacement work is still incomplete.
When to choose
Use this only when a near-term v5 upgrade would break production because runtime, middleware bridge, or plugin compatibility work is unfinished. The decisive factor is whether you have verified blockers that cannot be retired fast enough for a safe cutover.
Tradeoffs
It reduces immediate migration risk and lets you sequence runtime, schema, and plugin work, but it keeps you on an out-of-support Fastify major and extends operational risk. Pricing for any commercial end-of-life support should be treated as check official docs.
Cautions
Do not assume common plugins are drop-in across majors. Official compatibility tables show major-version shifts for v5 support, such as @fastify/express >=4.x for Fastify ^5.x and @fastify/cors ^10.x or ^11.x for Fastify ^5.x, so a temporary hold should include a dated plugin inventory and a firm exit plan.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Which strategy should I use for Fastify v5?"