Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- O FastAPI não oferece ramificações LTS; portanto, as versões mais antigas não têm manutenção garantida nem janela de retroportabilidade de segurança.
- A maior parte da exposição real está nas versões fixadas do Starlette e do Pydantic, e não no próprio FastAPI.
- A atualização para várias versões secundárias de uma só vez pode alterar discretamente o comportamento da serialização, da validação e das dependências.
- O Suporte ao Ciclo de Vida Ilimitado mantém a versão que você já utiliza atualizada com os patches enquanto você planeja a atualização de forma adequada.
Então, há um aplicativo FastAPI em produção, rodando em uma versão na faixa de 0.9x, ou talvez 0.104, com modelos do Pydantic v1 integrados em todas as rotas, e um scanner acabou de acionar um alerta no painel, indicando que um pacote foi marcado como em fim de vida útil. Nada está com defeito. A latência está normal. O tráfego está normal. Mesmo assim, alguém da equipe de segurança agora quer definir uma data no calendário.
Há um ponto que vale a pena esclarecer antes de mais nada, pois a maioria dos artigos sobre esse assunto, sem dar muita atenção, apresenta essa informação incorreta. O FastAPI não divulga datas de fim de vida útil. Não há ramificações LTS (Long-Term Support), nem linha de manutenção dedicada exclusivamente à segurança, nem anúncio quando uma determinada versão deixa de receber atenção. O projeto está na versão 0.x.x; versões secundárias podem conter alterações incompatíveis, e a orientação oficial é fixar uma versão comprovadamente estável e atualizar de forma deliberada. Portanto, quando este artigo menciona o “fim de vida útil (EOL) do FastAPI”, refere-se a uma versão mais antiga do FastAPI que não recebe mais atualizações do projeto, e não a uma designação formal emitida pela equipe do FastAPI.
Essa distinção só piora a situação, em vez de melhorá-la. Com uma estrutura que divulga um ciclo de vida, pelo menos você sabe quando o prazo acaba. Aqui, não há prazo definido. Assim que o projeto segue em frente, não há um prazo de manutenção divulgado que indique por quanto tempo sua versão mais antiga continuará recebendo correções, e ninguém envia um e-mail sobre isso também.
A seguir, explicaremos o que isso significa na prática para uma API de produção, por que a cadeia de dependências torna a situação mais complicada do que parece e quais são as opções viáveis, incluindo o Suporte de Ciclo de Vida Ilimitado da TuxCare, caso a atualização imediata não seja algo que o roteiro de desenvolvimento possa acomodar.
Como funcionam, na prática, as versões do FastAPI
Vale a pena dedicar um minuto para entender como as versões se sucedem aqui, pois é fácil perder a noção de onde uma determinada versão se encaixa em um histórico que muda tão rapidamente.
O FastAPI segue o sistema de versionamento semântico, e permanecer abaixo da versão 1.0.0 faz parte desse sistema, e não constitui um desvio dele. De acordo com o SemVer, um projeto 0.x.x tem permissão para causar incompatibilidades em uma versão secundária, e o FastAPI aproveita essa flexibilidade. Sebastián Ramírez (tiangolo) tem sido bem direto a respeito disso. Fixem sua versão, leiam as notas de lançamento e atualizem de forma consciente. O framework está em produção em milhares de empresas e ainda assim se reserva o direito de alterar o comportamento entre versões secundárias.
As versões são lançadas com frequência. Não há um ciclo fixo de seis meses, como no Node.js. Uma nova versão secundária pode ser lançada em qualquer mês, às vezes trazendo mudanças reais na forma como o JSON é serializado, no comportamento das dependências com `yield` ou na forma como os corpos das solicitações são validados.
Aqui está a sequência que é importante para a segurança.
As versões do FastAPI anteriores à 0.100.0 suportavam apenas o Pydantic v1. Essa versão não está mais em desenvolvimento ativo, o que faz com que qualquer aplicativo que ainda esteja vinculado a ela dependa de uma biblioteca de validação que recebe apenas manutenção, em vez de desenvolvimento.
FastAPI 0.100.x a 0.125.x oferecia suporte tanto ao Pydantic v1 quanto ao v2. A versão 0.119.0 adicionou suporte para from pydantic.v1 import BaseModel, permitindo que os modelos v1 e v2 coexistam no mesmo aplicativo e oferecendo às equipes um caminho de migração gradual.
A versão 0.125.0 do FastAPI deixou de oferecer suporte ao Python 3.8, cujo fim de vida útil ocorreu em 7 de outubro de 2024. A versão 0.124.4 é a última que pode ser instalada no Python 3.8; portanto, um resolver do pip nesse ambiente de execução simplesmente deixa de funcionar.
FastAPI 0.126.0 abandonamos o Pydantic v1 e elevamos o padrão mínimo para pydantic >= 2.7.0, mantendo o suporte temporário para o pydantic.v1 namespace. A versão 0.127.0 começou a exibir avisos de obsolescência nesse namespace, e a versão 0.128.0 o removeu. A partir daí, apenas o Pydantic v2 funciona.
A versão 0.129.0 do FastAPI deixou de oferecer suporte ao Python 3.9, tornando a versão 3.10 a versão mínima exigida para qualquer uso atual.
As versões do FastAPI são lançadas rapidamente, e qualquer número de versão mencionado em um artigo como este fica desatualizado em poucos dias. Verifique o PyPI antes de planejar uma atualização, pois o que importa é a diferença entre o seu pin e a versão atual.
Nada de dramático acontece quando você fica para trás. Seu código continua sendo executado. A versão simplesmente para de avançar, e você não pode contar com que quaisquer problemas identificados a partir desse momento sejam corrigidos naquele branch mais antigo.
O que o fim do suporte (EOL) do FastAPI realmente significa para o seu ambiente de produção
As atualizações param. Os terminais continuam respondendo. Os painéis permanecem no verde. Então, qual é o problema, afinal?
As vulnerabilidades não deixam de ser descobertas só porque uma versão deixou de receber manutenção. Os pesquisadores continuam analisando softwares amplamente implantados porque é aí que está o retorno, e o FastAPI está implantado em todos os lugares atualmente, alimentando APIs nos setores de fintech, saúde, infraestrutura de IA e em uma grande quantidade de ferramentas internas de empresas.
Duas vulnerabilidades (CVEs) do próprio histórico do FastAPI ilustram a natureza do problema.
CVE-2024-24762 (CVSS 7,5, Alta) é uma vulnerabilidade de negação de serviço (DoS) relacionada a expressões regulares no python-multipart, a biblioteca que o FastAPI utiliza para analisar dados de formulários. Um cabeçalho Content-Type malicioso leva o analisador a um backtracking quadrático e bloqueia o loop de eventos, sem que seja necessária autenticação para enviá-lo. Uma única solicitação bloqueia um worker, e um número suficiente de solicitações simultâneas pode tornar o serviço indisponível. A correção foi implementada no python-multipart 0.0.7, e o FastAPI 0.109.1 elevou sua exigência de dependência para incluir essa versão. Vale a pena saber disso, pois muda a classificação de risco: uma versão mais antiga do FastAPI não fica automaticamente vulnerável se o python-multipart já tiver sido corrigido, e atualizar esse único pacote costuma ser a solução mais rápida.
CVE-2021-32677 (CVSS 8.1, Alta) é uma vulnerabilidade de falsificação de solicitação entre sites (CSRF) no FastAPI em versões anteriores à 0.65.2. O FastAPI analisava o corpo de uma solicitação como JSON mesmo quando o cabeçalho Content-Type indicava text/plain. Uma solicitação text/plain é considerada uma solicitação simples CORS; portanto, o navegador a envia sem verificação prévia (preflight) e com cookies anexados. Uma página maliciosa poderia, portanto, enviar uma carga JSON disfarçada como texto simples e fazer com que ela fosse aceita como uma solicitação de um usuário autenticado. A vulnerabilidade afetava aplicativos que utilizavam autenticação baseada em cookies em operações de caminho acessíveis pelo navegador que aceitavam corpos de solicitação em JSON. A versão 0.65.2 corrigiu a falha, analisando JSON apenas quando o tipo de conteúdo for `application/json` ou um tipo de mídia compatível.
Nenhuma dessas situações é incomum. Ambas podem ser acionadas remotamente em condições de implantação totalmente comuns e, juntas, mostram por que as versões das dependências são tão importantes neste contexto. Às vezes, a correção envolve atualizar o próprio FastAPI. Outras vezes, uma dependência que pode ser atualizada independentemente resolve o problema por si só.
Isso oferece uma triagem aproximada para uma base de código mais antiga. Para versões anteriores à 0.109.1, verifique a que o `python-multipart` realmente remete no seu arquivo de bloqueio antes de mexer em qualquer outra coisa, já que isso por si só pode resolver o problema. Em versões anteriores à 0.65.2, aplicativos que usam autenticação baseada em cookies em endpoints JSON voltados para o navegador estão expostos há anos e precisam de uma atualização de verdade ou de uma verificação compensatória por meio de middleware. E se amanhã for divulgada uma vulnerabilidade com o mesmo perfil na versão à qual você está vinculado, não há nenhum ramo upstream onde um backport venha a ser disponibilizado.
O risco oculto na sua árvore de dependências
Quando as equipes pensam no risco de fim de vida útil (EOL) do FastAPI, elas pensam no FastAPI. A exposição mais interessante geralmente está uma camada abaixo.
O conjunto de dependências principais do FastAPI gira em torno do Starlette e do Pydantic, além de algumas bibliotecas auxiliares de tipagem, e esse conjunto tem mudado ao longo do tempo, à medida que o projeto evolui. Instalar fastapi[standard] e você também utiliza complementos opcionais, como o python-multipart para análise de formulários e o Uvicorn para hospedar o aplicativo. Cada um deles tem seu próprio ritmo de lançamento, seus próprios mantenedores e seu próprio histórico de segurança.
O Starlette é o exemplo mais claro. O CVE-2025-62727, publicado como GHSA-7f5h-v6xp-fcq8, é uma falha de análise do cabeçalho `Range` no `FileResponse` com complexidade de tempo quadrático, que permite que uma solicitação não autenticada sobrecarregue a CPU. A vulnerabilidade afeta o Starlette das versões 0.39.0 a 0.49.0, foi corrigida na versão 0.49.1 e afeta qualquer aplicativo que sirva arquivos por meio do FileResponse ou do StaticFiles. Muitos aplicativos FastAPI fazem exatamente isso sem se darem conta.
Depois, há aquele que deveria realmente preocupar qualquer pessoa que ainda esteja presa a uma pilha de sistemas mais antiga. Em maio de 2026, a X41 D-Sec divulgou o CVE-2026-48710, apelidado de BadHost, descoberto durante uma auditoria patrocinada pela OSTIF no vLLM. O Starlette não estava validando o cabeçalho HTTP Host antes de usá-lo para reconstruir request.url. O roteamento é feito com base no caminho bruto, request.url foi reconstruído a partir do cabeçalho do Host, e um único caractere inválido poderia fazer com que request.url.path informar algo diferente do caminho que foi realmente solicitado. Qualquer middleware que tome decisões de autorização com base em request.url.path poderia passar despercebida. O GitHub atribuiu a ela uma pontuação de 6,5 segundo o CVSS 3.1; ela não requer credenciais nem interação do usuário e afeta o Starlette das versões 0.8.3 a 1.0.0, com a correção incluída na versão 1.0.1. A autorização do FastAPI no nível do endpoint que não toma decisões com base em request.url.path não é afetado. O middleware personalizado que toma decisões de autorização com base em request.url ou request.url.path ou seja, um padrão observado em servidores MCP, proxies LLM e outras infraestruturas baseadas em FastAPI.
É aqui que a armadilha das dependências deixa de ser teórica. A solução é o Starlette 1.0.1, mas o Starlette só chegou à versão 1.0.0 em março de 2026. Versões mais antigas do FastAPI declaram um limite máximo bem abaixo disso. O FastAPI 0.120.1, por exemplo, limita o Starlette a uma versão inferior a 0.50.0. Se o Starlette corrigido ficar fora do intervalo declarado pela versão do FastAPI, atualizar apenas o Starlette deixará você em uma combinação que o FastAPI nunca testou e não oferece suporte. Adotar a correção significa atualizar o FastAPI primeiro, que é exatamente a atualização que você estava tentando programar, em vez de ser forçado a fazê-la.
Pydantic merece uma descrição mais detalhada do que geralmente recebe. A V1 não está mais em desenvolvimento ativo, mas a política de versões publicada pelo Pydantic ainda se compromete a fornecer correções de bugs críticos e de segurança para a V1 até o lançamento da V3, e a V3 ainda não foi lançada. A pressão sobre a V1 não é o abandono, mas a redução da compatibilidade. O FastAPI removeu o suporte nativo à V1 na versão 0.126.0 e o pydantic.v1 O shim na versão 0.128.0 faz com que, ao permanecer na v1, você fique limitado à FastAPI 0.126, independentemente do que a equipe do Pydantic venha a fazer. O caminho para a atualização fica cada vez mais restrito com o tempo, mesmo que a garantia de segurança, tecnicamente, continue válida.
O Starlette é a outra metade dessa história. O FastAPI constrói seu roteamento, middleware, tratamento de WebSockets e lógica de resposta diretamente sobre ele; portanto, uma falha no Starlette se torna um problema do FastAPI sempre que um aplicativo executa uma versão afetada e acessa o caminho de código vulnerável. O BadHost é exatamente esse padrão.
Se somarmos tudo isso, o quadro que se apresenta não é tanto o de “um único pacote sem suporte”, mas sim o de “várias bibliotecas antigas e fortemente interligadas, com políticas de suporte diferentes, requisitos de atualização distintos e intervalos de versões que se restringem mutuamente”. Isso é algo mais difícil de analisar e muito mais complicado de corrigir aos poucos.
Suas opções quando chegar o fim da vida útil (EOL)
Portanto, a versão está desatualizada, ou está caminhando para isso. Três caminhos realistas, com custos reais associados.
Atualize para a versão mais recente do FastAPI
Essa é a resposta oficial e, muitas vezes, a correta. A versão mais recente do FastAPI é realmente melhor. O Pydantic v2 traz melhorias substanciais no desempenho da validação, o sistema de injeção de dependências é mais robusto e as versões mais recentes do Python proporcionam ganhos de velocidade em diversas cargas de trabalho.
É a transição a partir de uma versão mais antiga que torna tudo mais interessante.
A mudança do Pydantic da v1 para a v2 é a mais significativa. A v2 é praticamente uma reescrita, com uma API diferente para validadores, definições de campos e configuração de modelos. A @validator O decorador está obsoleto e deve ser substituído por @field_validator, com assinaturas e semântica de validação alteradas, o que pode exigir alterações reais no código, em vez de apenas uma operação de localizar e substituir. O orm_mode = True a opção de configuração passa a ser model_config = ConfigDict(from_attributes=True). Modelos complexos com validadores personalizados transformam isso em um projeto de migração com seu próprio cronograma.
O FastAPI também sofreu alterações nos bastidores. A versão 0.118.0 reverteu o código de saída das dependências com `yield` para que fossem executadas após o envio da resposta, o que corrigiu um bug real em que um `StreamingResponse` não conseguia usar uma sessão de banco de dados que já havia sido fechada e, ao mesmo tempo, causou falhas no código que passara a depender da saída anterior. A versão 0.121.0 adicionou Depends(scope="function") para voltar ao comportamento anterior. A versão 0.130.0 transferiu a serialização de respostas JSON para o codificador Rust do Pydantic; a versão 0.131.0 marcou como obsoleta as classes ORJSONResponse e UJSONResponse, pois o argumento de desempenho já não se aplica; e a versão 0.132.0 ativou a verificação rigorosa do Content-Type para solicitações JSON, rejeitando corpos sem um tipo de conteúdo JSON válido, a menos que você defina strict_content_type=False. Esse último problema vai aparecer imediatamente se algum cliente do seu sistema não estiver prestando atenção aos cabeçalhos.
Nada disso é impossível. Simplesmente não é pip install --upgrade fastapi e um café. Se você estiver um ou dois minors atrasado, faça o upgrade e siga em frente. Se estiver vinte atrás e ainda estiver na versão Pydantic v1, trate isso como um projeto com uma estimativa real associada.
Migrar para uma estrutura diferente
Algumas equipes aproveitam o momento para reavaliar completamente a escolha do framework e analisar o Flask, o Django REST Framework, o Litestar ou alguma outra opção.
O argumento arquitetônico se aplica a casos específicos, especialmente quando o design “async-first” do FastAPI continua entrando em conflito com uma base de código predominantemente síncrona, ou quando a geração automática de OpenAPI não está valendo a pena para serviços internos que ninguém fora da equipe utiliza.
O problema é o custo. Os manipuladores de rota, a estrutura de injeção de dependências, o middleware, a autenticação e os modelos de resposta são todos moldados pela FastAPI. O ciclo de vida das solicitações e respostas é diferente. Os padrões de teste são diferentes. A configuração de implantação muda. Para um aplicativo de produção maduro, isso pode facilmente se tornar um projeto de vários sprints; e, para uma base de código grande com obrigações reais de tempo de atividade, isso é medido em trimestres, não em fins de semana. Essa é uma escolha legítima, mas não é uma correção de segurança.
Conte com o suporte contínuo ao longo do ciclo de vida da TuxCare
A terceira opção altera o tempo, e não o destino, o que geralmente é o que as equipes precisam.
A TuxCare vem atuando há 15 anos na área de correções de código aberto, já corrigiu mais de 14.000 vulnerabilidades e distribuiu mais de 420.000 correções nos pacotes suportados. Esse histórico é importante não tanto como uma credencial, mas como uma indicação de como o trabalho é estruturado, pois a retroportação de uma correção para uma versão que o projeto original abandonou é uma disciplina específica.
A cobertura vai além do próprio FastAPI. As dependências diretas e transitivas estão incluídas sem custo adicional, o que é o ponto mais importante, considerando tudo o que foi dito acima sobre o Starlette e o Pydantic. Quando algo como o BadHost atinge um componente localizado três camadas abaixo das suas instruções de importação, um patch para a versão que você realmente executa vale consideravelmente mais do que uma nota informando que você deve atualizar o framework.
O processo é automatizado, com etapas de verificação humana. A TuxCare monitora o NVD, os alertas de fornecedores e os alertas de segurança do GitHub, faz o backport de correções usando ferramentas algorítmicas e assistidas por IA e, em seguida, os engenheiros de segurança validam cada patch antes do lançamento. Tudo passa por testes de integridade, funcionalidade e regressão, é assinado e enviado para repositórios hospedados pela TuxCare. A entrega ocorre por meio do pip; portanto, quer você instale o FastAPI diretamente ou por meio de um espelho de pacotes interno, basta indicar uma fonte diferente e continuar trabalhando.
As correções são disponibilizadas dentro dos prazos estabelecidos pelo SLA, com suporte 24 horas por dia, 7 dias por semana, e as versões são lançadas acompanhadas da documentação da cadeia de suprimentos exigida pelo auditor, incluindo a saída do SBOM e o contexto do VEX, que mostra quais vulnerabilidades nesse SBOM já foram corrigidas. Atualmente, a TuxCare publica cobertura ELS para o FastAPI 0.63.0 e 0.104.1, além de cobertura separada para o Starlette em fim de vida (EOL), que é onde a exposição de dependências tende a se concentrar.
Quanto ao custo, a verdade é que isso depende dos seus números. Depois de somar as horas de engenharia a taxas reais, os ciclos de teste, o tempo de qualquer prestador de serviços, o risco de tempo de inatividade e os recursos que não serão lançados enquanto sua equipe sênior depura a resolução de dependências, o suporte estendido frequentemente sai bem mais barato do que uma migração acelerada. Faça essa comparação com base em seus próprios números, em vez de acreditar na palavra de qualquer pessoa.
Vale a pena deixar essa contrapartida bem clara, já que qualquer pessoa cética o suficiente para ter lido até aqui já deve ter pensado nisso. O ELS mantém uma versão antiga recebendo patches de segurança. Ele não a moderniza. Você permanece na mesma interface de API, na mesma geração do Pydantic e no mesmo comportamento para o qual seu código foi escrito — e esse é exatamente o ponto —, e ainda assim vai querer fazer a atualização eventualmente. O que muda é que a atualização ocorre quando sua equipe estiver pronta, em vez de seguir o cronograma definido por quem quer que seja que registre o próximo CVE.
O verdadeiro custo de apressar uma atualização
Quando um painel de segurança começa a piscar e um superior pede um prazo, o instinto é concentrar o trabalho no tempo que estiver disponível. É geralmente aí que começam os problemas.
O que realmente envolve uma atualização de versão do FastAPI
Alterar um código de versão no arquivo requirements.txt não é a tarefa em si. A tarefa começa depois disso.
O código precisa se adaptar. Mesmo mudanças que parecem insignificantes podem alterar o comportamento do modelo do Pydantic, modificar a serialização da resposta ou transformar um padrão de injeção de dependência que antes era tolerado em um erro. Um código que funcionou sem problemas por dois anos, sem nenhuma alteração, de repente precisa de atenção, e ninguém reservou verba para isso porque ninguém estava prestando atenção nele.
A compatibilidade precisa ser verificada em toda a árvore, não apenas nos pacotes que você escolheu deliberadamente. As dependências transitivas se restringem mutuamente de maneiras que só se tornam evidentes no momento da resolução, e um pacote incompatível, mesmo que esteja em um nível quatro níveis abaixo, pode bloquear toda a atualização até que alguém resolva o problema.
O middleware e a autenticação precisam passar por uma auditoria adequada. Os utilitários de segurança do FastAPI, os fluxos OAuth2 e o tratamento de JWT evoluíram, e um middleware que funcionava corretamente em uma versão mais antiga pode se comportar de maneira sutilmente diferente em uma versão mais recente. Essas falhas podem passar despercebidas em testes unitários restritos e só vir à tona em testes de integração ou no tráfego de produção, como uma sessão de usuário que expira no momento errado em uma sexta-feira.
Os testes representam a verdadeira sobrecarga. As suítes de testes unitários, de integração, de ponta a ponta e de desempenho precisam ser executadas na nova versão para detectar regressões antes que o tráfego comece. Equipes com cobertura insuficiente descobrem exatamente o quão insuficiente ela é durante a atualização, que é o pior momento possível para se perceber isso.
O que acontece quando você faz tudo com pressa
Quando se tenta condensar tudo isso em um cronograma determinado por um prazo de conformidade, o processo tende a dar errado das formas já conhecidas.
A carga de suporte aumenta primeiro. Os bugs que não foram detectados nos testes aparecem como tickets relatando comportamentos estranhos da API, e boa parte deles remonta à atualização, mesmo que ninguém faça essa conexão inicialmente.
A estabilidade vem em seguida. Mudanças sutis nas dependências geram bugs em casos extremos que só aparecem sob carga de produção, e uma falha intermitente causada por uma mudança de comportamento três camadas abaixo é algo terrível de se depurar às 3 da manhã.
A dívida técnica se acumula silenciosamente. Na correria para garantir a conformidade, a refatoração é deixada de lado e as soluções provisórias se acumulam, e a ideia de que “vamos consertar isso direito mais tarde” se torna o estado permanente da base de código.
O orçamento é o último a ser considerado e o que mais pesa. É muito mais provável que haja estouros de orçamento quando surgem problemas inesperados com atualizações, entre horas extras de emergência dos prestadores de serviços, atrasos nos lançamentos e o custo de oportunidade de seus melhores engenheiros passarem três semanas resolvendo dependências, em vez de trabalharem no que os clientes solicitaram.
Como começar
Se você estiver utilizando versões mais antigas do FastAPI e quiser verificar qual é a cobertura de segurança disponível, em vez de simplesmente acreditar no que o fornecedor afirma, a TuxCare publica um rastreador de CVEs onde é possível consultar vulnerabilidades e as correções já disponibilizadas para as versões suportadas e suas dependências. Essa é uma maneira razoável de avaliar como seria a cobertura de segurança para sua pilha de tecnologia.
Para saber mais sobre as versões compatíveis, os detalhes de entrega e os preços, a página “Suporte de Ciclo de Vida Ilimitado para FastAPI” explica como a implementação funciona na prática.
Não deixe que o fim do suporte ao FastAPI coloque suas APIs em risco
O FastAPI evoluiu bastante. O suporte ao Pydantic v2, a serialização JSON mais rápida, o melhor desempenho em streaming e um conjunto muito maior de ferramentas complementares fazem com que valha a pena adotar a versão atual assim que for o momento certo para sua equipe e seu ambiente de produção.
Mas se você estiver mantendo um aplicativo que, na prática, não pode ser migrado de uma versão mais antiga sem causar graves interrupções, essa situação não precisa significar pânico nem uma exceção permanente em termos de segurança.
Existem opções, e elas são reais. Você pode planejar uma atualização deliberada para quando fizer sentido para a empresa. Você pode avaliar uma estrutura diferente se houver um motivo arquitetônico genuíno. Ou você pode contratar suporte estendido para manter a segurança enquanto essas decisões são tomadas de acordo com o seu cronograma, em vez de seguir o cronograma de divulgação de terceiros.
As equipes que lidam bem com isso raramente são aquelas com os maiores orçamentos ou as bases de código mais recentes. São aquelas que identificaram o risco com precisão, compreenderam o custo de suas opções e fizeram uma escolha consciente.
Se o fim do suporte (EOL) do FastAPI está em sua agenda no momento, vale a pena verificar quais opções de suporte estão disponíveis antes de se comprometer com uma atualização para a qual sua agenda ainda não está preparada. O artigo “Suporte de ciclo de vida ilimitado para software de código aberto” aborda até onde essa proteção se estende ao restante da sua pilha de tecnologia, pelo tempo que você precisar.
