Função, Worker ou contêiner: o que estamos alugando

Montar a ficha de execução dos três sistemas mais críticos, com teto, comportamento no teto e data de verificação.

• Distinguir os três modelos de execução pelo que cada um cobra e pelo que cada um limita.
• Declarar o teto de duração e de memória de cada sistema crítico, com data de verificação.
• Descartar objeções de arquitetura baseadas em números que caducaram.

Em linguagem simples

Quando o cliente pede algo que não estava pronto, alguma máquina precisa executar código naquele instante. Existem três formas de alugar essa execução. A função gerenciada acorda quando chamada e some depois. O Worker na borda vive em centenas de pontos do mundo e roda em uma caixa muito pequena e muito rápida. O contêiner é o mais parecido com uma máquina de verdade, e é o que se usa quando o programa precisa de coisas que as outras duas não oferecem.

A pergunta de quem decide é o que exatamente estamos alugando, quanto tempo esse aluguel dura por chamada, quanta memória vem junto e o que acontece quando o teto é atingido. Sistema que estoura teto sem ninguém ter escrito o que acontece falha na frente do cliente e ninguém consegue explicar por quê.

1. 01Cobrança separada em duas linhas. Desde 16 de junho de 2026, a Vercel cobra CPU ativa apenas enquanto o código executa e memória provisionada durante toda a vida da instância, inclusive na espera por banco ou por modelo de IA.
2. 02O teto de duração deixou de ser a objeção que era. O teto de duração padrão de uma função passou a ser 300 segundos em todos os planos, inclusive o gratuito, conforme documentação de 1º de julho de 2026. Os 10 segundos valem apenas para projetos anteriores a 23 de abril de 2025, quando o modelo de execução atual (Fluid compute) passou a ser padrão.
3. 03Na borda, o que se compra é tempo de processador. No plano pago do Cloudflare, o teto de CPU do Worker é de 30 segundos por padrão e configurável até 300.000 milissegundos. A requisição HTTP não tem limite de duração enquanto o cliente estiver conectado, e a memória é fixa em 128 MB por instância.
4. 04Contêiner voltou para a mesa. Desde 30 de junho de 2026 a Vercel constrói e executa imagem de contêiner descrita num arquivo de receita, tem catálogo de imagens no padrão aberto do mercado e serviços privados entre si. O argumento de que a plataforma só serve para a camada visual perdeu validade nessa data.
5. 05Inicialização a frio: a demora da primeira chamada. Quando uma função é chamada depois de um período parada, a máquina precisa acordar antes de responder. Essa demora foi, entre 2022 e 2024, o principal argumento para escolher execução na borda. O caso documentado abaixo mostra o que sobrou dela.

Confusão mais comum: Confundir tempo de resposta com tempo de CPU. Uma função que leva quatro minutos porque espera um sistema externo consome pouca CPU e muita memória provisionada. Otimizar o tempo de resposta dela não reduz quase nada da fatura; reduzir a memória reservada e aumentar a concorrência por instância, sim.

Explique em voz alta: Responda a alguém do financeiro, sem consultar a fatura, por que uma função lenta pode ser barata e uma função rápida pode ser cara, usando as duas linhas de cobrança.

A objeção que caducou em 23 de abril de 2025 e continuou sendo repetida

Existe uma frase que atravessa comitês de arquitetura desde 2022: não dá para rodar trabalho pesado nessa plataforma, porque a função morre em dez segundos. Ela sustentou orçamentos de servidor paralelo, contratos de infraestrutura redundante e decisões de não migrar. E deixou de ser verdadeira.

A documentação da Vercel, atualizada em 1º de julho de 2026, registra que o timeout padrão de funções é de 300 segundos em todos os planos, inclusive o gratuito, com máximo de 800 segundos em disponibilidade geral no Pro e no Enterprise, e 1.800 segundos em beta para runtimes suportados. Os antigos 10 segundos valem apenas para projetos criados antes de 23 de abril de 2025 que não usam Fluid compute, que é padrão para projetos novos desde essa data.

O mesmo aconteceu do outro lado. No Cloudflare, o teto de CPU de um Worker no plano pago é de 30 segundos por padrão e configurável até 300.000 milissegundos, e a requisição HTTP não tem limite de duração enquanto o cliente estiver conectado. Os 15 minutos que aparecem em material antigo valem para tarefas agendadas, alarmes de objetos duráveis e consumidores de fila, e não para a requisição do cliente.

E há um terceiro modelo de volta à mesa. Em 30 de junho de 2026, no evento anual da Vercel, a plataforma passou a construir e executar imagem de contêiner descrita num arquivo de receita, ganhou catálogo de imagens no padrão aberto do mercado e serviços privados entre si. A frase de que a Vercel só serve para a camada visual perdeu validade nessa data. Os nomes técnicos de cada peça estão no bloco de execução deste módulo.

O trabalho deste módulo é substituir opinião por ficha. Três sistemas críticos, uma linha cada, com quem executa, sob qual modelo, qual teto de duração, qual teto de memória, o que acontece quando o teto é atingido e a data em que cada número foi lido na documentação do fornecedor.

Três formas de alugar execução

Todos os números foram lidos na documentação primária dos fornecedores e verificados em 24 de julho de 2026. Ficha sem data volta a enganar em seis meses, porque limite de plataforma muda por changelog.

Modelo operacional

A ficha de execução, campo a campo

Uma linha por sistema crítico. Três sistemas bastam para começar, e são sempre os três cuja indisponibilidade aparece primeiro para o cliente que paga.

• Quem executa: Função gerenciada, Worker na borda ou contêiner. Sem essa distinção, os campos seguintes não têm significado, porque cada família tem teto e fatura próprios. Exemplo: Emissão de relatório de frota: função gerenciada. Checagem de sessão: Worker na borda.
• Modelo de cobrança: O que exatamente é medido. Escreva as linhas da fatura que aquele sistema alimenta, não o nome comercial do plano. Exemplo: CPU ativa mais memória provisionada mais invocação, no caso da função gerenciada; requisições mais CPU-milissegundos, no caso do Worker.
• Teto de duração: Quanto tempo uma execução pode durar. Sempre com a data em que o número foi lido na documentação do fornecedor. Exemplo: 300 segundos por padrão, documentação de 1º de julho de 2026, ampliável a 800 segundos sob configuração no plano Pro.
• Teto de memória: Quanto de memória a execução tem disponível. Em Worker é valor fixo de 128 MB; em função gerenciada é configurável e vira linha de fatura. Exemplo: 128 MB por instância no Worker, valor que decide sozinho se determinado processamento cabe ali.
• O que acontece no teto: Comportamento observável quando o limite é atingido. É o campo que quase nunca está escrito e é o único que o cliente enxerga. Exemplo: Hoje devolve erro genérico. O comportamento pretendido é devolver identificador de tarefa e notificar quando concluído, com dono e prazo.
• Data de verificação: Quando cada número foi lido na documentação primária. Sem essa coluna, a ficha vira folclore interno em um ou dois semestres. Exemplo: 24 de julho de 2026, com o endereço da página de limites do fornecedor anotado ao lado.

A ficha descreve o que a plataforma permite. Ela não descreve o que o sistema consome de fato, e essas duas coisas divergem sempre. Consumo real é medição, e ela pertence ao módulo de fatura.

Evidência pública

Caso documentado: a demora da primeira chamada deixou de ser argumento de arquitetura

Engenharia da Vercel

Com o modelo de execução atual da plataforma, a engenharia da Vercel reporta que 99,37% das requisições não sofrem inicialização a frio, ou seja, não esperam a máquina acordar depois de um período parada, com instâncias processando dezenas de requisições concorrentes. Em 21 de julho de 2026, a distribuição de bytecode pré-compilado nos pacotes Python derrubou a inicialização da função de tamanho mediano de 2,8 segundos para 1,3 segundos.

• 99,37% das requisições não sofrem inicialização a frio no modelo corrente, segundo a própria engenharia da plataforma.
• O pré-aquecimento evita cerca de um terço das inicializações a frio remanescentes.
• A melhoria de 21 de julho de 2026 é específica de Python e representa queda de cerca de 54% no tempo de inicialização da função mediana.

A escolha de executar na borda foi vendida entre 2022 e 2024 com o argumento de eliminar inicialização a frio. Esse argumento perdeu força, e em 10 de junho de 2026 o próprio fornecedor passou a recomendar a migração da borda para Node.js. Decisão de arquitetura tomada com o argumento antigo precisa ser reaberta, não defendida.

Os números são reportados pelo próprio fornecedor, o que os torna informativos e não independentes. Tratar como ordem de grandeza e cobrar a medição da própria operação.

Guardrail

Números que envelheceram e continuam sendo repetidos em comitê

Estas cinco afirmações circulam em apresentação interna, em material de treinamento e em proposta de fornecedor. Todas eram verdadeiras em algum momento e nenhuma resiste à documentação primária de julho de 2026. Quando uma delas aparecer, peça a data da fonte antes de discutir o mérito.

• A função morre em 10 segundos. Falso para projeto novo: o padrão é 300 segundos em todos os planos, e os 10 segundos valem apenas para projetos anteriores a 23 de abril de 2025, data em que o modelo de execução atual passou a ser padrão.
• Worker roda até 30 segundos no plano gratuito e 15 minutos no pago. Confunde três coisas: no gratuito o teto de CPU é de 10 milissegundos; no pago são 30 segundos por padrão, configuráveis até 300.000 milissegundos; e os 15 minutos valem para tarefas agendadas, alarmes e consumidores de fila.
• Coloque na borda para eliminar inicialização a frio. Em 10 de junho de 2026 a Vercel passou a recomendar o caminho inverso, e ambos os runtimes rodam sobre o mesmo modelo de cobrança de CPU ativa.
• A Vercel só serve para a camada visual. Desde 30 de junho de 2026 a plataforma constrói e executa imagem de contêiner descrita num arquivo de receita, tem catálogo de imagens no padrão aberto do mercado e serviços privados entre si.
• O plano gratuito tem 100 GB de banda e pronto. São sete cotas mensais, não uma, e o plano é vedado a uso comercial pelas diretrizes de uso justo, conforme documentação de 1º de julho de 2026.

Rotina real

A apresentação dos três sistemas críticos

Gerente de infraestrutura apresentando ao comitê de tecnologia, com o CFO presente · Levantamento único de noventa minutos, com revisão semestral e revisão obrigatória a cada mudança de plano ou de fornecedor.

Situação: O comitê quer decidir se mantém no orçamento um servidor paralelo criado há dois anos exclusivamente para tarefas longas, justificado por um limite de dez segundos que já não existe.

Entradas: Lista dos três sistemas cuja indisponibilidade aparece primeiro para o cliente, páginas de limites dos dois fornecedores e o registro de quando cada projeto foi criado.

Processo: Para cada sistema, preencher os seis campos da ficha, sempre com a data de leitura ao lado do número. Onde o comportamento no teto não estiver escrito, abrir item de trabalho com dono e prazo em vez de improvisar a resposta na reunião.

Saída: Meia página com três linhas preenchidas, a data de verificação em cada número e a lista de itens de trabalho gerados pelos campos que estavam vazios.

Verificação humana: Toda objeção histórica citada na reunião é confrontada com a data da fonte. Objeção sem fonte datada não derruba nem sustenta decisão, e isso é dito em voz alta antes de a discussão começar.

Como se mede: Número de sistemas críticos com ficha completa e datada, e idade da verificação mais antiga da ficha. Verificação com mais de seis meses volta para a fila.

Laboratório de decisão

Onde colocar a emissão de relatório que leva quatro minutos

O relatório mensal de frota consolida dados de três fontes e leva cerca de quatro minutos para ficar pronto. Hoje ele roda em um servidor paralelo criado em 2024, com custo fixo mensal, justificado à época pelo limite de dez segundos das funções.

O relatório continua em máquina própria, volta para a plataforma ou muda de desenho?

• A. Manter o servidor paralelo, porque já está funcionando e a migração tem risco.: Preserva o funcionamento e mantém no orçamento uma máquina ligada vinte e quatro horas para atender um pico mensal. Também mantém um elo a mais no caminho, com atualização de sistema operacional, correção de segurança e dono próprio.
• B. Migrar para função gerenciada com teto de 300 segundos, aceitando que a execução fique perto do limite.: Elimina a máquina fixa e coloca o processo a segundos do teto. Qualquer crescimento de volume ou lentidão de uma das três fontes derruba a execução, e o cliente vê erro no dia do fechamento, que é o pior dia possível.
• C. Migrar para função gerenciada e trocar o desenho: a chamada devolve identificador de tarefa em segundos, o processamento roda em segundo plano e o cliente é notificado quando o arquivo fica pronto.: Custa uma alteração de desenho e remove o teto da equação, porque nenhuma requisição do cliente precisa esperar. Elimina a máquina fixa, reduz a superfície de manutenção e melhora a experiência no dia de maior uso.

Recomendação: A terceira opção, com o teto de 300 segundos mantido na configuração como rede de proteção e o comportamento de falha escrito na ficha.

A primeira opção paga máquina ligada o mês inteiro para um pico mensal e adiciona um elo de manutenção ao caminho do código até o cliente. A segunda troca custo fixo por fragilidade: processo que roda a segundos do teto falha no dia de maior volume, e é justamente o dia em que o cliente está olhando. A terceira aceita que a pergunta sempre foi se o cliente precisa esperar. Depois que a resposta ao cliente deixa de estar acoplada ao processamento, o teto de duração para de ser critério de arquitetura e volta a ser o que deveria ser, uma rede de proteção. O custo dessa mudança é de dias de trabalho; o custo de descobrir o limite em produção é o fechamento mensal do cliente.

Guia prático · Guia de marketing 2 · Formulário de lead

Receba o lead do formulário numa função, com o segredo do CRM fora do código

Caso de uso: Geração de leads B2B · formulário de demonstração ligado ao CRM

No fim deste guia o formulário da landing envia o lead para uma função que valida o dado, grava no CRM com uma chave que ninguém consegue ler depois de salva e responde em menos de um segundo, na Vercel ou na Cloudflare.

Onde fica: Vercel: projeto > Settings > Environment Variables e a pasta de rotas do framework. Cloudflare: Worker > Settings > Variables and Secrets, ou o comando de segredos do Wrangler.

Rota de lead no Next.js, com a chave lida do ambiente (exemplo mínimo)

Critério de pronto e como medir

• Critério de pronto: lead de teste da prévia aparece só no ambiente de teste do CRM, lead de produção aparece com as três UTMs preenchidas, e a chave do CRM não é legível no painel.
• Tempo de resposta da rota abaixo de um segundo na aba de logs, medido em dez envios.

Caso Nortis · Semana 2

O time apresenta os três sistemas mais críticos da Nortis. Dois rodam como função gerenciada, um roda como Worker na borda, e ninguém sabe dizer de cabeça qual é o teto de duração de cada um.

A objeção repetida há dois anos em comitê, de que não dá para rodar processamento longo na plataforma porque morre em dez segundos, deixou de valer em 23 de abril de 2025, quando o novo modelo de execução virou padrão para projetos novos. Ninguém acompanhou a mudança.

Montar a ficha de execução dos sistemas críticos com modelo de execução, teto de duração, teto de memória e o que acontece quando o teto é atingido.

Exemplo trabalhado

A ficha de execução dos três sistemas críticos da Nortis

Gerente de infraestrutura da Nortis, apresentando ao comitê

Dois sistemas rodam como função gerenciada e um roda como Worker na borda. Ninguém na reunião sabe dizer de cabeça qual é o teto de duração de cada um, e há dois anos o comitê repete a objeção de que não dá para rodar processamento longo na plataforma porque morre em dez segundos.

Resultado: A ficha ocupa meia página e responde três perguntas que o comitê fazia havia dois anos sem obter número. Um item de infraestrutura paralela sai do orçamento do trimestre seguinte.

Continua sob responsabilidade humana: A ficha diz o que a plataforma permite e não diz o que o sistema aguenta. Teto de 300 segundos não significa que o relatório deva demorar 300 segundos, e cabe ao time provar o consumo real, não o teto teórico. Todo número da ficha tem data porque limite de plataforma muda por changelog, e ficha sem data volta a enganar em seis meses.

• Eu sei dizer, para cada sistema crítico, se pagamos por CPU efetivamente consumida, por memória reservada ou por máquina ligada.
• Eu tenho o teto de duração e de memória de cada sistema crítico escrito, com a data em que o número foi verificado.
• Eu tenho escrita, na ficha de execução, a data em que cada teto foi lido na documentação do fornecedor, e sei apontar qual objeção histórica ela derrubou.

Sabendo onde o código roda, falta saber se o time entrega bem, e isso não se responde com percepção de reunião.