Workflow SDK 5 da Vercel criptografa dados por padrão e corta latência em até 25 vezes

Da automação aos agentes: por que a Vercel reescreveu o runtime

Quando a Vercel lançou o Workflow SDK, a proposta era simples: escrever JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) → assíncrono comum e deixar o SDK manter a execução viva através de falhas, deploys e esperas longas. Um sleep("3d") no meio de uma função sobrevive a um redeploy sem código extra. Desde então, segundo a Vercel, o SDK passou de 4 bilhões de steps executados e 700 milhões de runs.

Daí saíram dois padrões de uso que moldaram a versão 5. O primeiro é automação tradicional: mover dados, processar pedidos, coordenar jobs em background, gerenciar assinaturas, rodar ETL. O segundo é agentes e harnesses de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →, que são caros e de execução longa e por isso também exigem durabilidade. Workflow SDK 5 foi desenhado em cima desses dois casos, com foco declarado em segurança, confiabilidade e performance.

Criptografia ponta a ponta sem mexer no código

O event log do Workflow guarda argumentos e retornos de cada step para permitir recuperação após crash ou deploy. Esse log pode conter dados sensíveis de cliente, contexto de modelo, credenciais e resultados de tool-calls. A partir da v5, todo esse payload é criptografado com AES-256-GCM antes de sair do seu código, com uma chave única por run.

Na Vercel, isso não exige configuração nenhuma: a chave de cada run deriva de uma chave associada ao deployment, então um run só consegue decifrar seus próprios dados. O código do workflow não muda:

export async function onboardCustomer(customer: Customer) {
 "use workflow";
 const account = await createAccount(customer);
 await sendWelcomeEmail(account.email);
 return account.id;
}

async function createAccount(customer: Customer) {
 "use step";
 // chega decifrado aqui dentro do seu deployment
 return db.accounts.create(customer);
}

A observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → continua funcionando porque nomes, tempos e status de cada step permanecem visíveis em texto puro; só o payload vira ciphertext. Para inspecionar o conteúdo real, é preciso decifrar localmente, no navegador ou no terminal, respeitando as mesmas permissões das variáveis de ambiente do projeto:

npx workflow inspect run <run-id>
npx workflow inspect run <run-id> --decrypt

Quem roda Worlds auto-hospedados também pode habilitar criptografia implementando getEncryptionKeyForRun() com o próprio gerenciamento de chaves, desde que devolva sempre os mesmos 32 bytes para o mesmo run. Escritas entre runs (quando um código resume o hook de outro run ou escreve num stream encaminhado) também são seladas, cifradas para a chave pública do run de destino. E quem quer reter o mínimo possível pode zerar a retenção com experimental_retention: 0, apagando inputs, outputs e streams assim que o run termina, mantendo só os metadados.

Trace viewer redesenhado e atributos de execução

A v5 traz um trace viewer refeito, com busca de span, zoom, minimap e inspeção local durante o desenvolvimento. É a tela que mostra onde um run travou ou demorou, agora navegável sem precisar cruzar logs manualmente.

Também chegam os run attributes: metadados pesquisáveis que podem ser anexados a um run, como um ID de pedido, para depois localizar execuções por esse valor. A Vercel é explícita sobre a limitação: atributos ficam em texto puro, então não devem carregar segredos.

Workflows em cada região, não só em iad1

No Workflow SDK 4, todo run vivia na região iad1, mesmo em projetos deployados em várias regiões. Isso significava que um step rodando em outro lugar fazia requisições cross-region só para registrar seu progresso, um custo de latência escondido em qualquer app geograficamente distribuído.

Na v5, a Vercel levou a infraestrutura do Workflow para toda região de Function. Por padrão, um run nasce na região da função que o iniciou; dá para forçar outra região passando a opção region para start():

const run = await start(processOrder, [order], { region: "fra1" });

Isso fixa onde o estado do run vive, mas não onde os steps executam: steps rodam onde o app está deployado, então fixar a região dos dados em Frankfurt só faz sentido se o deploy também cobrir aquela região. Runs antigos, criados na v4, continuam presos a iad1 sem migração automática. O ganho extra é resiliência: com failover de Function configurado, uma instabilidade numa região não derruba runs novos em regiões saudáveis, e o estado permanece fixo na região de origem durante o failover.

Menos saltos de fila para cargas de agentes

Na v4, cada invocação de step passava por um salto de fila para começar e outro para a workflow continuar. Para automação lenta em background isso é irrelevante; para loops de agente com milhares de eventos sequenciais, streams de token de alto throughput e subagentes dinâmicos, esse custo de rede e CPU por step virou gargalo real.

A v5 reescreveu partes grandes do engine para reduzir saltos de fila, tráfego de rede desnecessário e trabalho de CPU, permitindo que uma invocação execute vários steps (inclusive em paralelo) antes de ceder o controle para uma espera, um hook ou um timeout próximo. Um segundo pilar é o replay incremental: em vez de reprocessar todo o histórico de eventos a cada retomada, o runtime evita esse crescimento proporcional ao tamanho do log. Por padrão, streams no World da Vercel agora trafegam por WebSocket, e a compressão de payload reduz em cerca de 80% o tamanho médio de streams de token de IA.

Os números, medidos em 8 de outubro de 2026 comparando v5.2.0 com v4.8.12 em produção na Vercel (região iad1, steps com 1 KB de JSON de entrada e saída), são os seguintes:

Vale a ressalva: a própria Vercel trata esses números como a visão de uma carga de trabalho específica, numa região, contra o World gerenciado da Vercel, e não como previsão garantida para qualquer aplicação. Quem roda Worlds auto-hospedados ou outras regiões deve medir o próprio cenário antes de generalizar esses ganhos.

Worlds como base compartilhada: fx, durable-harness e eve

Por trás do SDK existe o conceito de World, a interface que cuida de armazenar progresso, despachar trabalho e entregar streams. É essa mesma base que agora sustenta outras ofertas da Vercel: o fx, para embutir e estender um agente de código nativo via libfx; o durable-harness, que adiciona durabilidade a harnesses de agente já existentes (com suporte a Pi e OpenCode, e integrações experimentais com Claude Code e Codex no Vercel Sandbox); e o eve, para construir agentes com sessões duráveis nativas.

Melhorias na camada compartilhada de storage, fila e streaming beneficiam qualquer consumidor de World, mas otimizações dentro do runtime de replay do Workflow SDK não se propagam automaticamente para todo harness.

O que muda na prática para quem já roda v4

A Vercel afirma não ter introduzido breaking changes relevantes na v5, então a atualização tende a ser direta: pnpm add workflow@latest. Ainda assim, há pontos de atenção concretos antes de migrar em produção:

• Runs criados na v4 continuam presos à região iad1; não há migração automática de dados existentes para outras regiões.
• Criptografia é zero-config só na Vercel; em Worlds auto-hospedados exige implementar e operar o próprio gerenciamento de chaves via getEncryptionKeyForRun().
• Atributos de run são plaintext por design, então não servem como substituto de segredo ou dado sensível pesquisável.
• Os ganhos de performance mais expressivos (replay incremental, menos saltos de fila) importam sobretudo para quem já opera agentes ou harnesses de execução longa; pipelines simples de automação em lote sentem menos diferença no dia a dia.

O SDK em Python, lançado em beta junto com a v5, replica steps, sleeps e hooks duráveis para quem constrói fora do ecossistema Node.js, um sinal de que a aposta da Vercel em durabilidade como primitiva de infraestrutura vai além do JavaScript.

Fonte: Vercel Changelog