Como configurar o Dependabot no GitHub para atualizar bibliotecas automaticamente?

Quando uma biblioteca fica desatualizada, alguém precisa descobrir a nova versão, alterar o projeto e conferir se nada parou de funcionar. O Dependabot automatiza a descoberta e propõe a mudança em uma pull request. Você recebe uma alteração separada para revisar e testar antes de integrar ao código principal.

Neste guia, vamos configurar atualizações semanais para um projeto React que usa npm e para as GitHub Actions do repositório. O Dependabot não faz o merge no seu lugar. Ele prepara as mudanças para que sua equipe avalie o resultado.

Há dois tipos de tarefa relacionados: version updates mantêm as dependências em dia conforme o calendário do arquivo, enquanto security updates tratam versões com alertas de vulnerabilidade. A configuração abaixo ensina primeiro as atualizações de versão. Alertas de segurança têm controles próprios no GitHub.

Abra a raiz do seu repositório e procure package.json. Ele lista as dependências npm do aplicativo. Veja também qual arquivo de lock acompanha o projeto, como package-lock.json, pnpm-lock.yaml ou yarn.lock. Esse arquivo registra as versões exatas instaladas, para que sua máquina e o ambiente de publicação usem a mesma árvore de pacotes.

Se package.json estiver na raiz, o caminho será /. Se estiver em uma pasta como frontend, o campo directory precisa apontar para /frontend. A regra é simples: informe a pasta em que o Dependabot deve procurar os manifests, não o caminho de um arquivo específico. Em um monorepo, faça uma entrada para cada pasta que tenha seu próprio package.json. Por exemplo, o site pode ficar em /frontend e a API em /services/api:

updates:
  - package-ecosystem: "npm"
    directory: "/frontend"
    schedule:
      interval: "weekly"

  - package-ecosystem: "npm"
    directory: "/services/api"
    schedule:
      interval: "weekly"

Esse é um exemplo de estrutura: mantenha as entradas dentro do campo updates do arquivo principal e use somente caminhos que existam no seu repositório. Se os dois package.json estiverem na raiz, não crie duas entradas para eles.

Na raiz do repositório, crie a pasta .github se ela ainda não existir. Dentro dela, crie dependabot.yml e cole a configuração. Ela agenda uma verificação semanal de pacotes npm e GitHub Actions, com no máximo cinco pull requests de atualização de versão abertas ao mesmo tempo.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

• npm: procura package.json e o arquivo de lock na pasta indicada.
• github-actions: verifica as versões das ações declaradas nos workflows do GitHub Actions.
• directory: troque "/" pelo caminho da pasta que contém os manifests. Em um monorepo, adicione uma entrada para cada local que precisa ser monitorado.
• open-pull-requests-limit: limita a cinco as pull requests de atualização de versão abertas ao mesmo tempo.

O arquivo começa com version: 2 e contém uma entrada em updates para cada ecossistema. A primeira entrada encontra dependências npm. A segunda cuida das actions referenciadas nos arquivos de workflow, que normalmente ficam em .github/workflows. Se o repositório não usa GitHub Actions, você pode remover essa segunda entrada.

Envie o arquivo para a branch padrão do repositório. Depois que o GitHub reconhecer a configuração, o Dependabot consulta os manifests e pode abrir pull requests para as versões novas. A espera pela primeira atualização depende de quando a próxima verificação for executada e da existência de versões pendentes.

Quando uma pull request aparecer, comece pelo resumo do Dependabot. Veja quais pacotes foram alterados, de qual versão para qual versão e se há notas de lançamento que mencionam mudanças incompatíveis. Uma atualização major, como a passagem da versão 2 para a 3, pode exigir alterações no seu código. Atualizações patch costumam ser menores, mas também precisam passar pelos testes.

Configure seu workflow do GitHub Actions para rodar nos eventos de pull request. Para um projeto com package-lock.json, um fluxo comum instala exatamente o que está no lockfile e roda os scripts disponíveis no package.json:

npm ci
npm test
npm run build

Use os comandos que existem no seu projeto. Se não houver um script test, por exemplo, configure o workflow para executar as verificações que sua equipe realmente usa. Não aprove uma atualização só porque a versão instalou: abra a aplicação e confira o comportamento que depende daquela biblioteca.

O Dependabot prepara a atualização. Os testes e a sua revisão decidem se ela entra no projeto.

Se nenhuma pull request aparecer, não conclua imediatamente que o Dependabot está quebrado. Primeiro confira se o arquivo está no caminho exato, se usa o nome dependabot.yml e se o campo directory aponta para a pasta do manifest. Depois abra o Dependency graph do repositório e consulte a área Dependabot, que mostra os ecossistemas monitorados e a última verificação.

Se uma pull request falhar, leia a saída do workflow. Um teste pode estar identificando uma quebra real, ou a atualização pode exigir credenciais para baixar uma dependência privada. Nesse caso, configure o acesso ao registro privado conforme as instruções do GitHub, sem colocar tokens diretamente no YAML.

Uma novidade para esse último cenário: em 12 de outubro de 2026, o GitHub liberou autenticação Anonymous para registros privados configurados no nível da organização. Ela atende espelhos de pacotes que já permitem leitura sem credenciais. Não serve para um registro que exige login. No GitHub.com, a configuração fica em Settings da organização, depois Secrets and variables e Private registries. Se havia um token fictício no registro, é preciso removê-lo e cadastrar o registro novamente com Anonymous.

Para reduzir uma fila muito grande de pull requests, o Dependabot também permite agrupar atualizações relacionadas. Uma opção é juntar versões minor e patch do npm:

groups:
  npm-minor-patch:
    update-types:
      - "minor"
      - "patch"

Adicione groups dentro da entrada de npm em updates. Esse agrupamento reduz a quantidade de solicitações, mas torna a revisão mais ampla. Para aprender o fluxo e descobrir uma mudança problemática com mais facilidade, comece com pull requests separadas e adicione grupos quando já estiver confortável com as atualizações.

Comece com uma frequência que você consiga revisar. Automatizar a abertura das pull requests não substitui a manutenção do projeto.