O fim de vida do Helm 3, explicado

O fim de vida do Helm 3 é a data a partir da qual o projeto Helm deixa de lançar qualquer versão do Helm 3, incluindo correções de segurança. Essa data é 10 de fevereiro de 2027, segundo o anúncio de fim de vida do projeto Helm. Muitos guias ainda citam novembro de 2026, a data do plano original. Equipes que usam o Helm 3 em scripts e pipelines têm cerca de três meses para migrar para o Helm 4.

O Helm é o gerenciador de pacotes do Kubernetes, o sistema que roda contêineres em muitos servidores. Um chart do Helm é um pacote de modelos para um app. Instalar um chart cria um release, e cada atualização acrescenta uma revisão numerada ao histórico desse release.

Este guia cobre o cronograma, o que muda no Helm 4 e um teste prático do Helm 4.3.1 em releases criados pelo Helm 3.22.1.

Como funciona o fim de vida do Helm 3

O Helm 3 está sendo encerrado em duas etapas, segundo o anúncio de fim de vida que George Jenkins escreveu para o projeto em 2 de junho de 2026.

• As correções de bugs acabaram em 9 de setembro de 2026. A versão desse dia foi a última versão de recursos do Helm 3. Ela só trouxe bibliotecas cliente do Kubernetes atualizadas. Assim, o Helm 3 podia conversar com versões mais novas do Kubernetes.
• As correções de segurança acabam em 10 de fevereiro de 2027. Se uma falha for encontrada antes disso, o projeto ainda lança um patch. Depois dessa data, o Helm 3 não recebe mais nenhuma atualização, "incluindo a biblioteca cliente do Kubernetes e os patches de segurança", segundo o anúncio.

As notas da versão v3.22.0 confirmam que a 3.22 é a última versão menor do Helm 3. O patch mais recente, 3.22.1, saiu em 15 de outubro de 2026.

O fim de vida não desliga nada. Um binário do Helm 3 continua rodando depois de 10 de fevereiro de 2027, como aponta a Private DevOps em seu guia de migração. Ele só deixa de receber correções de segurança e suporte a novas versões do Kubernetes.

O que mudou e quando

O cronograma original veio da HIP-0012, uma proposta de melhoria do Helm. Ela prometia correções de segurança para o Helm 3 por um ano depois do Helm 4.0.0, ou seja, até novembro de 2026. Em junho, os mantenedores acrescentaram três meses.

Data	O que aconteceu
12 de novembro de 2025	Helm 4.0.0 lançado na KubeCon, a primeira nova versão principal do Helm em seis anos
2 de junho de 2026	O Helm estende por três meses as correções de segurança do Helm 3
9 de setembro de 2026	Última versão de recursos do Helm 3 (3.22); fim das correções de bugs
15 de outubro de 2026	Lançamento do Helm 3.22.1 e do Helm 4.3.1, as versões mais recentes em 8 de novembro
13 de janeiro de 2027	Helm 4.4.0 previsto, segundo a página de versões
10 de fevereiro de 2027	Fim das correções de segurança do Helm 3; nenhuma nova versão do Helm 3

O conselho do anúncio é direto: "Recomendamos fortemente que todos os usuários migrem para o Helm 4 antes dessa data."

O que o Helm 4 muda para quem usa o Helm 3

Segundo o projeto Helm, o Helm 4 "deve ser compatível com a maioria dos charts, releases e fluxos de trabalho existentes do Helm 3". Charts no formato v2 atual funcionam sem mudanças, e um novo formato de chart v3 ainda é experimental. A visão geral do Helm 4 lista as mudanças que importam:

• Flags renomeadas. --atomic agora é --rollback-on-failure, e --force agora é --force-replace. Os nomes antigos ainda funcionam, mas mostram um aviso.
• Post-renderers viraram plugins. Um post-renderer edita a saída do Helm antes que ela chegue ao cluster. --post-renderer agora recebe o nome de um plugin instalado, não o caminho de um script.
• O login no registro usa um nome de host. helm registry login aceita só um domínio, não uma URL.
• Server-side apply para novas instalações. Com o server-side apply, o próprio Kubernetes mescla cada mudança e registra qual ferramenta é dona de cada campo. Atualizações e rollbacks mantêm o método que o release já usava. Por isso, releases criados pelo Helm 3 continuam no método antigo, do lado do cliente. A flag --server-side muda isso.
• Um novo sistema de plugins. Os plugins existentes continuam funcionando. Eles também podem rodar em um runtime WebAssembly opcional, que o projeto recomenda por segurança.

Testado: Helm 4.3.1 em releases criados pelo Helm 3

Em um teste da Tech AI Wire em 8 de novembro de 2026, um cluster k3s com Kubernetes 1.36.6 rodou no Docker 28.4.0 sobre o macOS 26.6.2. Os dois binários do Helm vieram de get.helm.sh, e suas somas de verificação SHA-256 bateram. O Helm 3.22.1 instalou o chart de exemplo que o helm create escreve. Depois, o Helm 4.3.1 trabalhou no mesmo release. Abaixo, os dois binários se chamam helm3 e helm4.

helm3 install web ./demo --wait
helm4 upgrade web ./demo --atomic --set replicaCount=2
helm4 registry login https://ghcr.io -u test -p test
helm4 template web ./demo --post-renderer ./pr.sh
helm4 get metadata web

Teste	Resultado
O Helm 4 lê o release do Helm 3	Sim: helm list e helm history o mostraram
upgrade --atomic	Funcionou, com "Flag --atomic has been deprecated, use --rollback-on-failure instead"
upgrade --force	Funcionou, com "Flag --force has been deprecated, use --force-replace instead"
registry login https://ghcr.io	Falhou: invalid reference: invalid registry "https://ghcr.io"
--post-renderer ./pr.sh, um script de shell	Falhou: plugin não encontrado; o Helm 3.22.1 rodou o mesmo script
Método de aplicação do release do Helm 3 após atualizações pelo Helm 4	"client-side apply (defaulted)"
Método de aplicação de uma nova instalação pelo Helm 4	"server-side apply"
Helm 3 depois das atualizações pelo Helm 4	Leu as quatro revisões e voltou para a revisão 1

Os próprios registros do Kubernetes confirmaram. O Deployment do release do Helm 3 foi gravado com uma operação "Update", e o novo release do Helm 4 com um "Apply".

Um resultado não está na documentação. --server-side=true passou o release do Helm 3 para server-side apply. Uma atualização posterior com o Helm 3.22.1 fez o Helm 4 relatá-lo de novo como do lado do cliente, com a marca "(defaulted)". Quando o binário antigo e o novo se revezam em um release, uma migração pode ser desfeita sem aviso.

O que isso significa para desenvolvedores

• Corrija primeiro as duas falhas totais. Procure nos scripts de CI por helm registry login com https:// e por --post-renderer apontando para um script. Os dois param um pipeline do Helm 4, enquanto as flags renomeadas só mostram avisos.
• Renomeie --atomic e --force agora. Elas ainda funcionam, mas o Helm 4 as marca como obsoletas e mostra um aviso a cada execução.
• Um binário por release. Durante a migração, um release que o Helm 4 já tocou deve ser atualizado só pelo Helm 4. Caso contrário, o método de aplicação pode voltar atrás.
• Escolha o server-side apply de propósito. Releases criados pelo Helm 3 continuam do lado do cliente até alguém passar --server-side. Teste a troca em um cluster de staging antes da produção.
• Fixe a versão do Helm na CI e teste os rollbacks. A Private DevOps sugere listar cada chamada ao Helm e testar o Helm 4 fora da produção primeiro.
• Não espere até 10 de fevereiro. Depois dessa data, uma falha de segurança do Helm 3 fica sem correção, e versões novas do Kubernetes não têm suporte no cliente do Helm 3.