Dependabot agora tem cooldown para atualizações: o que muda no seu workflow

O que é o Dependabot e o que mudou

O Dependabot e a ferramenta do GitHub que verifica automaticamente as dependências do seu projeto e abre pull requests quando novas versões são lançadas. Em julho de 2026, o GitHub anunciou que o Dependabot agora aplica um período de carência padrão antes de sugerir atualizações de versão de pacotes.

Isso significa que, após o lançamento de uma nova versão de uma dependência, o Dependabot aguarda alguns dias antes de abrir o PR de atualização. A mudança pode parecer pequena, mas tem impacto prático direto em equipes que usam o Dependabot para manter dependências atualizadas de forma automática.

Entender o motivo da mudança ajuda a decidir se você quer manter o comportamento padrão ou personalizar para o seu caso de uso. O anuncio foi feito via GitHub Changelog e rapidamente gerou discussão no Hacker News com mais de 120 comentários da comunidade.

Como funciona o novo cooldown padrão

O cooldown e um período de espera entre o lançamento de uma nova versão de pacote e o momento em que o Dependabot cria o pull request de atualização no seu repositório. Antes dessa mudança, o Dependabot abria o PR assim que detectava uma versão nova disponível no registry do pacote.

Com o cooldown padrão ativo, o Dependabot aguarda um período configurável antes de sugerir a atualização. O objetivo principal e reduzir o risco de pacotes maliciosos ou com bugs críticos chegarem rapidamente aos projetos. Quando um pacote e comprometido logo após o lançamento e corrigido em horas, projetos que atualizaram imediatamente ficam expostos durante a janela do ataque.

O cooldown não afeta atualizações de segurança: PRs criados por vulnerabilidades detectadas pelo Dependabot alerts continuam sendo abertos imediatamente, sem espera. A carência se aplica apenas a atualizações de versão de rotina.

Por que o GitHub tomou essa decisão

A decisão vem de um problema crescente no ecossistema de pacotes open source: os ataques de supply chain. Nos últimos anos, vários casos de pacotes npm, PyPI e RubyGems comprometidos logo após o lançamento de uma nova versão chamaram atenção da comunidade.

Ao adicionar um período de espera, o GitHub da tempo para que a comunidade detecte problemas em novas versões antes que elas se propaguem automaticamente para todos os projetos que usam o Dependabot. Se um pacote comprometido for publicado e retirado em 24 horas, projetos com cooldown de alguns dias nunca chegam a atualizar para a versão maliciosa.

E também uma resposta ao volume de PRs automáticos que sobrecarregam equipes pequenas. Muitos times reclamam que o Dependabot abre dezenas de PRs por semana, e a maioria não traz beneficio imediato. O cooldown naturalmente agrupa atualizações menores, reduzindo o ruído.

Como configurar o cooldown no dependabot.yml

A configuração e feita no arquivo .GitHub/dependabot.yml do seu repositório. Veja como ficaria a configuração com cooldown personalizado:

version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    cooldown:
      default: 3
      patch: 1
      minor: 5
      major: 14

Se você não configurar o cooldown explicitamente, o Dependabot usa o valor padrão definido pelo GitHub. Para desabilitar o cooldown e voltar ao comportamento anterior, basta definir cooldown como zero na configuração do repositório.

A documentação oficial do GitHub detalha todas as opcoes disponíveis e como o cooldown interage com outras configurações como schedule e groups.

Exemplo prático de configuração completa

Abaixo, um exemplo de configuração que combina cooldown, grupos e limite de PRs para um projeto Node.js:

version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
      day: monday
    cooldown:
      default: 3
      patch: 1
      minor: 7
      major: 30
    groups:
      dev-dependencies:
        dependency-type: development
    open-pull-requests-limit: 10

Com essa configuração, patches chegam em 1 dia, minor versions em 1 semana e major versions só são sugeridas após 30 dias do lançamento. Dependências de desenvolvimento são agrupadas em um único PR por semana.

Comparação com alternativas ao Dependabot

O Dependabot não e a única ferramenta de gerenciamento automático de dependências:

• Renovate Bot: já tinha suporte a cooldown ha mais tempo, com o parâmetro minimumReleaseAge. E mais configurável, mas requer mais setup inicial.
• Snyk: focado em segurança, oferece recursos similares de cooldown. Tem plano gratuito para projetos open source.
• Socket Security: analisa o comportamento do pacote em vez de apenas a versão, detectando pacotes suspeitos antes de qualquer atualização.

O Dependabot tem a vantagem de ser nativo ao GitHub sem configuração adicional. Para a maioria dos projetos hospedados no GitHub, ele continua sendo a escolha mais prática.

Pontos positivos e limitações do cooldown

A nova política de cooldown traz benefícios reais: reduz o risco de comprometimento via supply chain, diminui o volume de PRs automáticos e da mais tempo para a comunidade detectar problemas em novas versões antes da propagação automática.

Por outro lado, times que dependem de atualizações rápidas para patches podem achar o cooldown padrão lento. Para esses casos, a recomendação e configurar cooldown menor para patch versions. Projetos com muitas dependências podem perceber um acumulo de PRs após o período de cooldown se varias dependências lançam versões na mesma semana.

Usar o campo groups ajuda a mitigar esse efeito, agrupando atualizações de dependências relacionadas em um único PR por ciclo, independente do cooldown aplicado.

Casos de uso reais

Quem se beneficia mais do cooldown padrão?

• Times pequenos: que não tem capacidade de revisar dezenas de PRs automáticos por semana;
• Projetos críticos: sistemas de produção onde a estabilidade e prioridade e o cooldown da tempo para a comunidade testar a nova versão;
• Projetos com muitas dependências: onde o volume de PRs do Dependabot se torna um problema operacional;
• Times com pouca cobertura de testes: onde cada PR de atualização precisa de revisão manual e menos PRs significa menos interrupções.

Dicas e boas práticas com Dependabot

Vale a pena habilitar ou personalizar o cooldown?

Para a maioria dos projetos, o cooldown padrão e uma mudança positiva que não requer configuração adicional. Ele melhora a segurança de supply chain e reduz o ruído de PRs automáticos sem impacto na velocidade de correções de segurança.

Se você tem um projeto onde atualizações rápidas são prioridade, configure cooldown menor para patch versions. Se você quer o comportamento anterior sem nenhum cooldown, e possível desabilitar explicitamente na configuração do arquivo dependabot.yml.

O próximo passo: abra o .GitHub/dependabot.yml do seu projeto principal, adicione a secao cooldown com os valores adequados para o seu ritmo de desenvolvimento e aproveite para revisar se os grupos de dependências fazem sentido para o volume de PRs que você recebe por semana.