A Vercel troca o toggle Sensitive por tipos Config e Secret nas variáveis de ambiente

A Vercel anunciou no dia 24 de agosto de 2026, em seu changelog, uma mudança na forma de classificar variáveis de ambiente. O antigo toggle Sensitive (liga/desliga) deu lugar a dois tipos explícitos: Config e Secret. A diferença parece cosmética, mas muda como o time raciocina sobre segredos e reduz uma classe comum de erro em deploy: expor por engano um valor que deveria ficar oculto, ou o contrário, esconder uma URL pública que alguém precisaria inspecionar depois.

O que Config e Secret significam na prática

Os dois tipos resolvem problemas opostos:

• Config: o valor continua legível depois de salvo, para membros com acesso. É pensado para valores não sensíveis que você pode precisar conferir mais tarde, como variáveis com prefixo público de framework (NEXT_PUBLIC_, VITE_, etc.).
• Secret: o valor fica disponível para os deployments e pode ser substituído, mas nenhum membro consegue visualizar ou recuperar o conteúdo depois de salvar. É o destino natural de senhas, chaves de API e tokens.

O ponto central é que a distinção deixou de ser "sensível ou não" (um estado binário meio ambíguo) para virar uma escolha semântica sobre o que aquele valor é. Na prática, isso alinha a ferramenta ao que os times já faziam mentalmente: uma API_URL pública nunca deveria ter o mesmo tratamento de uma API_KEY.

Quem já tinha variáveis marcadas como Sensitive não precisa fazer nada. Segundo o changelog, elas passam a ser tratadas automaticamente como Secret e continuam funcionando sem migração. É uma transição sem quebra, o que é o comportamento certo para algo que vive na base de deploy de produção.

Mudanças nas políticas de time

Aqui está a parte que exige atenção de quem administra uma organização na Vercel, porque envolve política de segurança que pode estar ativa hoje.

A política Enforce Sensitive Environment Variables foi descontinuada. Quando ligada, ela obrigava que toda variável criada por um membro do time fosse marcada como Sensitive, incluindo configuração não sensível. Isso gerava atrito: uma URL pública acabava tratada como segredo só para satisfazer a regra. Com os tipos Config e Secret, cada membro escolhe o tipo adequado por variável, então a política perdeu o sentido.

Em seu lugar entra a Separate Production Secret Values, disponível nas configurações de Security. Quando habilitada, ela exige que o valor de Produção de um Secret seja diferente dos valores usados para a mesma chave em Preview, Development e ambientes customizados. A lógica é direta: evita que a mesma chave de API real vaze de um preview deploy exposto e comprometa produção, um vetor de ataque conhecido em ambientes de preview públicos.

O ponto de atenção: se o seu time tinha a política antiga ativa, vale confirmar se a nova Separate Production Secret Values deve ser ligada. A Vercel avisa que a política antiga não é mais aplicada pela CLI, então não conte com ela como rede de proteção. Quem depende dessa garantia precisa reconfigurar de forma explícita.

Como definir os tipos pela CLI

Para scripts, pipelines de CI e automação, a escolha do tipo agora passa pela flag --visibility em vercel env add ou vercel env update:

# Config
vercel env add API_URL production \
  --value "https://api.example.com" \
  --visibility config --yes

# Secret
vercel env add API_KEY production \
  --value "sk_live_..." \
  --visibility secret --yes

As flags antigas continuam válidas por compatibilidade. Quando --visibility é omitido, --no-sensitive mapeia para Config e --sensitive para Secret. Depois de adicionar ou atualizar uma variável, a saída da CLI mostra o tipo sob o campo Visibility.

Para quem mantém scripts de provisionamento, o recado é: não é preciso reescrever nada agora, mas ao atualizar esses scripts, migrar para --visibility deixa a intenção mais explícita e legível do que o par --sensitive / --no-sensitive.

O que muda para o dev que faz deploy no Brasil

O ganho concreto é reduzir uma categoria de erro silencioso. No modelo antigo do toggle, era fácil deixar uma chave de API sem marcar como sensível (e ela ficava legível no dashboard para qualquer membro do time), ou marcar como sensível uma variável de configuração que depois ninguém conseguia inspecionar quando precisava debugar um deploy. Ao forçar a escolha entre Config e Secret na hora de criar, a interface empurra a decisão de segurança para o momento certo.

Para times pequenos ou agências que gerenciam múltiplos projetos de clientes, o benefício some no barulho de projeto único mas aparece na escala: dezenas de variáveis por projeto, várias pessoas com acesso, e a diferença entre uma chave sk_live_ visível e oculta é a diferença entre um incidente e um dia normal. A política Separate Production Secret Values também é especialmente útil para quem usa preview deploys em fluxo de review, cenário comum em times que trabalham com Next.js↳Next.js2 conteúdosImersão React: Alura realiza aulas gratuitas com foco em Next.JSGestão Dev & TI · jan 2021Criando sua primeira aplicação com RemixDev (Back & Front) · set 2024Ver tudo em Dev (Back & Front) → e branches de feature.

Onde isso não faz diferença

Seja honesto sobre o escopo: para um dev solo com um projeto pessoal e três variáveis, essa mudança é praticamente invisível, e não há motivo para mexer em nada, já que a migração é automática. O valor real está em times com controle de acesso e em ambientes onde preview deploys podem ser acessados por terceiros.

Vale lembrar também que "Secret" na Vercel significa que membros não conseguem ler o valor depois de salvo, não que ele seja criptografado de ponta a ponta de forma que a própria Vercel não tenha acesso. Para segredos de altíssima criticidade, gerenciadores dedicados (como um secrets manager externo integrado via runtime) continuam sendo a abordagem recomendada, e essa mudança não substitui isso. A documentação completa de Environment Variables da Vercel traz os detalhes de cada ambiente e prefixo.

Fonte: Vercel Changelog