Fastify EOL: Versões, datas, riscos e opções (2026)

Principais conclusões

• O Fastify v3 chegou ao fim de sua vida útil em 30 de junho de 2023, e a v4 seguiu o mesmo caminho em 30 de junho de 2025.
• Apenas a linha v5 ainda recebe correções da equipe do Fastify, e a v6 já entrou na fase alfa.
• O Fastify v5 requer o Node.js 20 ou uma versão mais recente, e o Node 20 chegará ao fim da vida útil (EOL) em abril de 2026 — portanto, uma atualização do framework implica necessariamente uma atualização do ambiente de execução.
• Suporte de ciclo de vida ilimitado da TuxCare abrange as versões 3.29.5 e 4.29.1 do Fastify com correções contínuas de vulnerabilidades CVE enquanto você planeja a migração.

Faça um levantamento em um grande conjunto de servidores Node.js e você provavelmente encontrará serviços que ainda rodam o Fastify v3, cujo suporte de longo prazo (LTS) chegou ao fim em junho de 2023. Isso significa mais de três anos sem correções de segurança do framework para um código que está em produção neste momento.

O Fastify v4 também não tem mais suporte, já que seu período de suporte de longo prazo (LTS) terminou em 30 de junho de 2025. Isso deixa a v5, lançada em setembro de 2024, como a única versão para a qual a equipe principal ainda oferece correções. Mudar para ela também significa migrar para uma versão do Node.js que ainda tenha suporte, pois o Node 20 já está no fim da vida útil (EOL) e o Node 22 já entrou na fase de manutenção.

A seguir, você descobrirá o que realmente significa o fim da vida útil (EOL) do Fastify, quais riscos são reais e quais são teóricos para cada linha, como fica uma frota v3 quando aquele ticket de migração fica sendo adiado para outro trimestre e quais são suas três opções viáveis.

O que é o Fastify?

O Fastify é um framework web para Node.js desenvolvido para oferecer baixo overhead por solicitação, com uma arquitetura de plug-ins que mantém tudo encapsulado, de modo que os decoradores de uma rota não possam interferir na outra. Ele valida e serializa por meio do JSON Schema e registra em log por meio de pino. Quando a versão 5 foi lançada, a OpenJS Foundation registrou os downloads mensais em 7,8 milhões, com 296 plug-ins oficialmente reconhecidos no ecossistema. Em julho de 2026, segundo o npm-stat, esse número havia ultrapassado 43 milhões de downloads mensais.

 

Em comparação com as estruturas que você provavelmente já utilizou, o Express é o mais antigo e muito maior, registrando cerca de doze vezes mais downloads mensais no npm do que o Fastify, mesmo sem praticamente nenhuma validação embutida, e é de onde a maioria das equipes vem. O Hapi exige uma configuração mais complexa e vem com mais recursos integrados. O Koa é um núcleo de middleware enxuto, em que quase tudo o mais é uma decisão separada que você precisa tomar. O NestJS não é realmente um concorrente, já que é uma estrutura de aplicativos que roda sobre o Express ou um adaptador do Fastify.

Se o seu serviço for um aplicativo NestJS que executa o adaptador Fastify, o Fastify estará presente na sua árvore de dependências, independentemente de o inventário de ativos da sua equipe se referir a ele como um aplicativo Fastify. O mesmo se aplica à versão do Node.js subjacente a ele, que silenciosamente chegou ao fim de sua vida útil e ficou presa ali por uma estrutura que alguém escolheu há duas equipes e uma reestruturação atrás.

Dica profissional: execute npm ls fastify –all em todos os repositórios de serviços, não apenas naqueles que você acha que o utilizam. Adaptadores, geradores e SDKs internos incluem o Fastify como uma dependência transitiva, e essas cópias raramente têm um responsável claro. É assim que geralmente surge uma instalação perdida da v3.

O Fastify chegou ao fim de sua vida útil?

As versões Fastify v1, v2, v3 e v4 já ultrapassaram suas datas de fim de suporte LTS. A v5 é a única linha que ainda recebe correções ativas da equipe principal, e sua entrada no cronograma oficial ainda consta como “a definir”. No entanto, isso não ficará em aberto para sempre. O Fastify 6.0.0-alpha.1 foi lançado em agosto de 2026 e, de acordo com a mesma política, a v5 passará a receber apenas atualizações de segurança por seis meses após o lançamento da v6.

O cronograma não é arbitrário, mesmo que pareça ser assim visto de fora. A política de LTS da Fastify garante a cada versão principal um mínimo de seis meses de suporte ativo, além de mais seis meses de atualizações exclusivamente de segurança após o lançamento da próxima versão principal. É essa lógica que define o fim do LTS da v4 para 30 de junho de 2025.

Após o término desse prazo, a política estabelece que os mantenedores continuarão analisando e lançando correções de segurança, mas somente quando a comunidade as fornecer e desde que não encontrem outras restrições, como a versão mínima compatível do Node.js. Trata-se de um suporte condicional, impulsionado pela comunidade, e não de uma linha de versões mantida. Um bug grave na v4 hoje pode receber um patch da comunidade, pode gerar uma nota educada solicitando a atualização ou pode simplesmente permanecer aberto como um issue no GitHub.

Apostar em uma API de produção, sem saber qual desses três resultados ocorrerá, é o que acaba prejudicando as equipes. É exatamente por isso que o suporte estendido à segurança existe, para começar.

Ciclo de vida das versões do Fastify e principais datas de fim de vida útil (EOL)

Essas datas vêm diretamente do cronograma de LTS publicado pelo Fastify. A coluna do Node.js reproduz as linhas de lançamento listadas ali para cada versão principal; é por isso que ela inclui versões “Current” de curta duração, como a 9 e a 11, juntamente com as linhas LTS.

Versão do Fastify	Data de lançamento	Fim do LTS	Situação atual	Linhas do Node.js listadas
1.0.0	6 de março de 2018	1º de setembro de 2019	EOL	6, 8, 9, 10, 11
2.0.0	25 de fevereiro de 2019	31 de janeiro de 2021	EOL	6, 8, 10, 12, 14
3.0.0	7 de julho de 2020	30 de junho de 2023	EOL	10, 12, 14, 16, 18
4.0.0	8 de junho de 2022	30 de junho de 2025	EOL	14, 16, 18, 20, 22
5.0.0	17 de setembro de 2024	Não anunciado	Ativo	20, 22

Uma observação sobre a linha da v5. Ela registra o que foi testado quando a v5 foi lançada, e a CI do Fastify no branch “main” agora executa seus testes unitários com o Node 24 e 26. O Node 20 também aparece nessa linha, mas chegou ao fim da vida útil (EOL) em 30 de abril de 2026; portanto, considere-o como um limite mínimo de compatibilidade, e não como uma versão em que você faria a implantação.

Agora observe a linha da v3 ao lado da data de hoje. Três anos após o fim do suporte LTS, em um intervalo do Node.js (de 10 a 18) que já está totalmente fora de suporte (EOL), e com a v4 também fora de uso, não resta mais nenhuma etapa intermediária para se recorrer. É por isso que “basta atualizar” é uma tarefa muito mais complexa para uma frota na v3 do que parece ser para uma na v4.

Riscos de segurança decorrentes da execução do Fastify (EOL) em ambiente de produção

O risco não é que um CVE específico esteja no seu node_modules agora mesmo. É a assimetria que entra em ação no dia em que sua versão chega ao fim da vida útil (EOL) e se agrava a cada ano que se passa. As pesquisas de segurança no Fastify continuam avançando a todo vapor, e as correções produzidas são desenvolvidas para a linha v5, que tem suporte. Para uma frota na v4, isso já representa mais de um ano de lacuna acumulada. Para uma frota na v3, são três.

As vulnerabilidades (CVEs) do framework deixam de afetar a sua versão

A família de validações de tipo de conteúdo é um exemplo claro do que isso custa na prática. Em abril de 2025, o CVE-2025-32442 documentou uma falha em que aplicativos que definem validação por tipo de conteúdo poderiam ter essa validação totalmente ignorada, bastando para isso enviar um cabeçalho Content-Type ligeiramente alterado. O comunicado lista as versões Fastify 5.0.0 a 5.3.1 e 4.29.0 como afetadas, com correções nas versões 5.3.2 e 4.29.1. A v4 recebeu uma versão corrigida porque ainda estava dentro do período de suporte, e a v3 nunca foi listada como afetada. Um ano depois, a mesma família gerou a CVE-2026-33806, uma falha de alta gravidade que contornava justamente essa correção, utilizando nada mais exótico do que um espaço à esquerda no cabeçalho, corrigida apenas na versão 5.8.5.

A Atualização de segurança do primeiro trimestre de 2026 da OpenJS Foundation registra 18 CVEs do ecossistema publicados por meio de suas operações da CNA naquele trimestre, sendo três deles no ecossistema Fastify. Dois estavam no próprio Fastify. O CVE-2026-3419 foi um problema de validação de Content-Type malformado que afetou as versões 5.7.2 a 5.8.0 e foi corrigido na versão 5.8.1, o que o torna uma regressão exclusiva da v5, e não uma falta de backport. CVE-2026-3635 é o que merece atenção: um falha de falsificação de cabeçalho que permite a falsificação de cabeçalhos, cujo aviso abrange todas as versões do Fastify até a 5.8.2, com a correção disponível apenas na versão 5.8.3. Todas as instalações das versões v3 e v4 estão dentro desse intervalo afetado, e nenhuma delas recebeu uma versão corrigida.

O terceiro, CVE-2026-2880, foi uma falha de alto nível de gravidade que permitia contornar a autorização no módulo opcional @fastify/middie , no qual o middleware com escopo de caminho podia ser ignorado porque o plug-in normalizava os caminhos de solicitação de maneira diferente do roteador. A correção está disponível no middie 9.2.0, e a linha 9.x é desenvolvida com base no Fastify v5. A linha 8.x, na qual os aplicativos v4 são executados, parou na versão 8.3.3 em setembro de 2024 e nunca recebeu essa correção.

Nada disso está perdendo força. A OpenJS informa, em sua atualização do segundo trimestre de 2026 que sua CNA publicou 3 CVEs no segundo semestre de 2025 e 49 no primeiro semestre de 2026, com cerca de mais dez aguardando divulgação. Grande parte desse aumento se deve a uma triagem mais rigorosa e à varredura assistida por IA, e não a uma onda repentina de novos bugs, mas o efeito sobre uma linha de produtos em fim de vida (EOL) é o mesmo de qualquer maneira. Mais divulgações – nenhuma delas chegando à sua versão.

O ambiente de execução subjacente possui seu próprio relógio

O Fastify v3 foi testado com as versões do Node.js de 10 a 18, todas elas agora em fim de vida útil (EOL). As equipes continuam usando versões antigas do Fastify porque a atualização é cara, e a mesma pressão orçamentária que as mantém nessas versões geralmente as mantém também em uma versão antiga do Node.js. Para um serviço v3, isso frequentemente significa duas versões cujos ciclos de vida terminaram há anos, e o ambiente de execução é o que expõe a maior superfície de ataque — desde TLS e análise de HTTP até redes e tudo o mais que está abaixo do código da sua aplicação.

Essa é a verdadeira razão pela qual as equipes ficam paralisadas, e raramente a culpa é da estrutura. Ninguém define o escopo de “atualizar a estrutura web” como uma migração em tempo de execução, mais uma mudança na imagem base, mais uma recompilação do módulo nativo. Quando alguém faz isso, a estimativa triplica, e o ticket é adiado para o próximo trimestre.

Quando as restrições de dependência limitam suas opções

A própria árvore de dependências do Fastify é realmente enxuta, e vale a pena ser honesto quanto a isso. A partir da versão 5.12.0 do Fastify, a instalação da v5 inclui 15 dependências diretas de tempo de execução: avvio, find-my-way, fast-json-stringify, light-my-request, pino, secure-json-parse, semver, rfdc, toad-cache, process-warning, abstract-logginge quatro @fastify/* . Para uma estrutura web, esse é um conjunto de dependências diretas realmente pequeno.

Chegar ao fim da vida útil (EOL) não congela essa árvore por si só, e vale a pena ser preciso sobre o que realmente acontece. O Fastify declara intervalos de versão semver, e o npm atualiza as dependências para versões mais recentes que ainda os satisfaçam; assim, muitas correções de segurança do desenvolvedor original chegam sem que ninguém precise mexer no Fastify. O problema é mais específico e mais irritante do que uma árvore congelada. Quando a única versão corrigida fica fora do intervalo que sua linha do Fastify aceita, adotá-la significa uma substituição, uma alteração direta na dependência ou uma atualização da estrutura para a qual sua versão nunca foi testada.

Então, seu scanner sinaliza um aviso transitivo, e a solução limpa acaba sendo “atualizar o Fastify”, que é exatamente o que você estava tentando evitar. Para um aplicativo v3, isso geralmente significa uma atualização do Node.js, além de alterações no esquema e na API, e não apenas a aplicação de um patch. É essa lacuna que faz com que uma auditoria limpa se transforme em um trimestre inteiro de discussões com sua equipe de segurança sobre risco aceitável versus falsos positivos.

Suas opções após o fim do ciclo de vida do Fastify

Existem três opções, e a escolha da mais adequada tem menos a ver com preferências de engenharia do que com a versão que você está realmente utilizando e com o tempo disponível da sua equipe neste trimestre.

Se isso se aplica a você	Faça isso
Estamos executando a v3 ou a v4 em um ambiente regulamentado, sem margem para uma migração de runtime e framework neste trimestre	Suporte estendido para a sua versão atual; depois, faça a migração no seu próprio ritmo
Já está em uma versão compatível do Node.js, com poucas APIs obsoletas e plug-ins mantidos	Atualize para a versão 5 agora
O Framework não é uma boa opção, além do problema do fim da vida útil (EOL)	Substitua-o e faça um orçamento adequado

 Suporte ao ciclo de vida ilimitado da TuxCare

O Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare abrange runtimes, bibliotecas e frameworks de código aberto em fim de vida útil (EOL). Ele fornece patches de segurança retrocompatíveis para versões que o projeto original não mantém mais, por meio do gerenciamento padrão de pacotes, o que reduz ao mínimo as alterações em seu pipeline de implantação. Especificamente para o Fastify, as versões cobertas são 3.29.5 e 4.29.1, as últimas versões das linhas v3 e v4. As correções são disponibilizadas pelo npm e acompanhadas publicamente no CVE Tracker da TuxCare, para que sua equipe de segurança possa ver exatamente o que está coberto antes de aprovar.

Para uma equipe que está presa a uma linha do Fastify em fim de vida útil (EOL), seja uma frota da v4 um ano após o fim do suporte de longo prazo (LTS) ou uma frota da v3 três anos após esse prazo, isso garante a continuidade das correções de segurança para a versão já em produção, em vez de uma migração forçada para a v5, que acarreta uma atualização envolvendo várias versões do Node.js. Isso também garante a documentação das correções, que você pode apresentar em uma auditoria SOC 2 ou PCI DSS, além de um cronograma de migração definido por você mesmo, em vez de um imposto por um calendário de divulgação ou pelas conclusões de um auditor.

As equipes que acabam nessa situação não são preguiçosas. Elas enfrentam restrições reais: limites de compatibilidade de plataforma, recursos de engenharia já alocados, complexidade de testes envolvendo dezenas de serviços ou normas regulatórias que transformam uma atualização não planejada da estrutura em um problema de controle de mudanças, em vez de um problema técnico. Para um serviço da era v3, isso costuma se assemelhar mais a uma completa migração de plataforma do que a um simples aumento de versão.

O papel da TuxCare aqui é servir de ponte, mantendo a versão do Fastify coberta atualizada com os patches enquanto a migração ocorre de acordo com o seu próprio cronograma, e não com o do upstream.

Atualizar para o Fastify v5

Essa é a decisão certa quando você tem condições financeiras para isso, e, no caso de uma frota na versão 4, a mudança é menor do que costuma ser na maioria das atualizações de versão principais. O próprio guia de migração da Fastify é realmente curto. Para uma frota na versão 3, reserve um orçamento semelhante ao de uma mudança de plataforma, com duas versões principais de APIs obsoletas para serem tratadas, além de uma mudança de ambiente de execução da linha do Node em fim de vida (EOL) em que o serviço está hoje para uma versão atualmente suportada.

Quatro fatores determinam essa estimativa. O primeiro é o ambiente de execução, já que a v5 requer o Node.js 20 ou uma versão mais recente, e isso é inegociável. Como o Node 20, por si só, chegará ao fim da vida útil (EOL) em abril de 2026, uma nova migração deve ser feita para uma versão LTS atualmente suportada, o que, no final de 2026, significa o Node 24, em vez de parar na versão 20.

O segundo é o JSON Schema completo. O opção jsonShorthand foi removida e, ao usar o validador padrão, querystring, params, bodye resposta devem conter objetos de esquema completos, incluindo o propriedade .

O terceiro ponto diz respeito às APIs removidas. O Fastify v5 eliminou as APIs que foram marcadas como obsoletas ao longo do ciclo de vida da v4; portanto, os avisos de obsolescência que você tem ignorado nos seus logs são um bom ponto de partida para a lista de tarefas. Para quem vem da v3, isso significa dois ciclos de obsolescência a serem analisados, em vez de apenas um.

O quarto ponto é a compatibilidade com plug-ins. Todos os plug-ins @fastify/* e plug-ins da comunidade precisam de uma versão compatível com a v5, e é geralmente nesse ponto que o cronograma realmente sofre atrasos. O atraso é maior para conjuntos de plug-ins mais antigos, nos quais ninguém mexeu desde 2022.

Se o seu conjunto de plug-ins for inteiramente de origem própria e mantido ativamente, e você estiver migrando da v4, o trabalho tende a permanecer contido. Se você estiver migrando da v3, ou se tiver plug-ins da comunidade que deixaram de ser atualizados há anos, avalie primeiro o escopo do trabalho de substituição. Essa é a parte que pode transformar uma atualização contida em um projeto de migração substancialmente maior.

Substituir o Fastify

Trocar de framework para resolver um problema de fim de vida útil (EOL) é quase sempre mais caro do que atualizar, e isso vale ainda mais a partir da v3, onde, de qualquer forma, você já terá que lidar com uma grande reescrita. Express 5, Hapi e Hono são todos frameworks razoáveis, mas migrar para qualquer um deles pode significar um trabalho substancial de reestruturação no registro de rotas, hooks e middleware, validação, plugins e código de aplicação específico do framework. Isso é uma reescrita disfarçada de atualização. Faça isso se o Fastify for realmente a escolha errada para você, e não apenas porque a versão chegou ao fim da vida útil (EOL).

Proteja o Fastify após o fim da vida útil (EOL) com a TuxCare

O Fastify v3 chegou ao fim do suporte de longo prazo (LTS) em junho de 2023, e a v4 seguiu o mesmo caminho em junho de 2025. Nenhuma dessas datas, por si só, representava um evento de risco. O risco é o intervalo que se estende desde a data aplicável à sua frota até o dia em que seu último serviço em fim de vida útil (EOL) for lançado em uma plataforma compatível; e, para muitas equipes, esse intervalo é medido, na melhor das hipóteses, em trimestres e, na pior, em anos.

Há duas maneiras de resolver isso. Migrar agora para a versão 5 e aceitar a atualização de tempo de execução que vem com ela, ou continuar aplicando patches na versão que você já está usando — incluindo as versões 3.29.5 e 4.29.1 — enquanto realiza a migração de acordo com um cronograma que você mesmo controla. Ambas são posições defensáveis. Continuar usando uma versão no fim da vida útil (EOL) e torcer para que dê tudo certo não é.

Se você faz parte desse segundo grupo, o Suporte de Ciclo de Vida Ilimitado da TuxCare oferece suporte a frameworks e ambientes de execução em fim de vida (EOL), incluindo o Fastify 3.29.5 e 4.29.1, atualizados e prontos para auditoria pelo tempo que a empresa precisar deles.

Perguntas frequentes