Turborepo e Remote Cache do Vercel agora aceitam OIDC no CI/CD

O Vercel anunciou no changelog de 30 de julho de 2026 que o Turborepo e o Vercel Remote Cache passaram a suportar OpenID Connect (OIDC). Na prática, isso significa que workflows de CI/CD (incluindo GitHub Actions) agora conseguem trocar um token OIDC emitido pelo próprio provedor de CI por um token de acesso Turborepo de curta duração, em vez de depender de um Personal Access Token (PAT) armazenado como secret.

O que muda

Até aqui, quem queria compartilhar o Remote Cache entre a máquina local e o pipeline precisava gerar um PAT e colocá-lo nos secrets do repositório. O problema é conhecido: PATs são credenciais de vida longa. Se vazam num log, num fork mal configurado ou numa dependência comprometida, continuam válidas até alguém lembrar de revogá-las manualmente. E, como estão atrelados a uma pessoa, viram um ponto único de falha quando esse alguém sai do time.

O modelo OIDC inverte essa lógica. Segundo a Vercel, os tokens obtidos por essa via são:

• De curta duração, então mesmo um vazamento tem janela de exploração curta;
• Escopados apenas ao Vercel Remote Cache, sem conceder acesso amplo à conta;
• Associados ao time do Vercel, e não a um membro específico.

Esse último ponto é o mais subestimado. Amarrar credenciais de CI a um time em vez de a uma pessoa elimina aquele ritual de rotacionar secrets toda vez que alguém troca de emprego. A recomendação da Vercel é direta: "We recommend all customers migrate their CI/CD workflows from PATs to OIDC."

Como funciona o fluxo

A ideia por trás do OIDC em CI/CD não é nova, o GitHub Actions já usa esse padrão para autenticar em AWS, GCP e Azure sem chaves estáticas. O provedor de CI atua como um identity provider: ele assina um token JWT que descreve quem está pedindo (o repositório, a branch, o workflow). Esse token é então apresentado ao Vercel, que valida a assinatura e, se bater com uma política configurada, devolve um token de acesso temporário ao Remote Cache.

No lado do Vercel, a configuração fica em Settings → Build and Deployment → OIDC Policies for CLI Access, onde se adiciona uma política Turborepo. É ali que se define quais claims do token OIDC são aceitas, o que permite, por exemplo, liberar o cache só para builds vindos da branch principal ou de um repositório específico.

Por que isso importa para o dev brasileiro

Para times daqui que rodam monorepos com Turborepo em GitHub Actions, o ganho é concreto e chega sem custo de infraestrutura extra. Menos secrets para gerenciar significa menos itens no inventário de segurança e menos chances de configurar algo errado. Para quem passa por auditorias ou trabalha com dados sensíveis, credenciais efêmeras e escopadas costumam ser exatamente o tipo de controle que o time de segurança pede.

Vale um alerta de expectativa: OIDC resolve o problema de autenticação do cache remoto, não faz mágica de performance. O ganho de velocidade do Remote Cache continua vindo do reaproveitamento de artefatos de build entre execuções, o turbo só precisa autenticar antes de baixar ou subir esses artefatos. O OIDC apenas torna esse handshake mais seguro.

Trade-offs e o que observar

A migração não é totalmente gratuita em termos de setup inicial. Configurar uma política OIDC exige entender quais claims o seu provedor de CI emite e como escopá-las corretamente, uma política frouxa demais pode acabar liberando o cache para contextos indesejados (pense em pull requests de forks). Aqui a recomendação prática é começar restritivo e afrouxar só quando necessário.

Outro ponto: se o seu pipeline não roda num provedor que emite tokens OIDC, ou roda em runners self-hosted sem essa capacidade configurada, o caminho do PAT ainda existe. A Vercel não sinalizou depreciação imediata dos PATs, apenas recomendou a migração, mas o recado sobre a direção do produto é claro.

Quem quiser testar encontra os detalhes na documentação oficial e no próprio changelog da Vercel. Para monorepos que já vivem no ecossistema Vercel, é uma daquelas mudanças de baixo esforço e alto retorno em postura de segurança.

Fonte: Vercel Changelog