Era uma noite de quinta-feira e o site Next.js de um cliente havia entrado no que só posso descrever como uma espiral de timeout. Funções serverless travando em 9,8 segundos, usuários vendo telas em branco, e eu freneticamente verificando o dashboard da Vercel à meia-noite tentando descobrir se realmente batemos em um limite do plano ou se o código era só péssimo. (Era os dois, honestamente.) Aquele projeto estava no plano Hobby. Provavelmente não deveria estar.
Deployei mais de 12.000 sites na Seahawk Media ao longo dos anos. Vercel é parte da nossa stack constantemente, especialmente para trabalhos com Next.js, nada mais chega perto em termos de experiência de desenvolvedor. Mas o plano Hobby tem arestas afiadas que são fáceis de perder até um projeto morder você. Então aqui está minha leitura real sobre onde essas arestas estão e quando elas começam a importar.
O Que o Plano Hobby Realmente Oferece
Vamos ser precisos. A partir de 2024, o plano Hobby da Vercel oferece:
100 GB de largura de banda por mês
6.000 minutos de build por mês
Tempo limite de execução de função serverless de 10 segundos
100 invocações de função serverless por dia... espera, não. Esse limite não existe. Mas existe um limite de 100 GB-horas de execução de função serverless por mês
Execução de edge function de 500.000 invocações por mês
1 build concurrent por vez
Deployments limitados apenas a contas pessoais (sem teams)
Nenhum uso comercial permitido conforme os termos da Vercel
Esse último confunde as pessoas mais do que qualquer limite técnico. O plano Hobby é explicitamente para projetos pessoais, não comerciais. Se você está construindo para um cliente pagante ou rodando qualquer tipo de negócio nele, você já está em violação dos termos de serviço. Já vi freelancers fazendo isso por anos e é uma responsabilidade à espera de acontecer.
O Tempo Limite de 10 Segundos da Function
Esse é o que pega as pessoas. Dez segundos parecem muita coisa até você estar fazendo uma chamada de API de terceiros que demora 4 segundos, rodando lógica de database que adiciona mais 3, e depois fazendo algo com a resposta. De repente você está em 9,2 segundos sem margem alguma.
No plano Pro esse limite salta para 60 segundos (e até 900 segundos com configuração na Enterprise). Não é uma diferença menor. É a diferença entre uma integração que funciona e um produto fundamentalmente quebrado para certos casos de uso.
Build Minutes: Onde Eles Desaparecem Mais Rápido Do Que Você Imaginaria
6.000 minutos de build por mês parece generoso. E para um único projeto pessoal provavelmente é. O problema é que esse número se esgota mais rápido que o esperado quando você está iterando de verdade.
De volta em 2021 eu estava rodando um side project, um agregador de conteúdo construído em Next.js com cerca de 400 páginas estáticas. Eu tinha ISR configurado mas também estava fazendo rebuilds completos frequentes enquanto experimentava com a camada de dados. Queimei aproximadamente 4.200 minutos de build em três semanas. Não porque os builds eram lentos, mas porque eu estava disparando eles constantemente.
Cada build em um site Next.js de complexidade média pode rodar 4-8 minutos facilmente. Se você está fazendo push para main 15 vezes por dia durante desenvolvimento ativo (o que é normal para mim), são 60-120 minutos de build idos em um único dia. Faça isso por uma semana e você terá consumido metade da sua alocação mensal.
Não há carryover. Minutos não se acumulam de mês para mês. E quando você chega a zero, seus deployments param. Fim de papo.
Como Desacelerar o Consumo
Algumas coisas que faço em projetos do plano Hobby para preservar minutos de build:
Fazer push para uma branch de não-produção para mudanças experimentais. Mesclar para main apenas quando algo está realmente pronto.
Usar vercel --prebuilt com outputs cacheados quando os artefatos de build não mudaram significativamente.
Configure o ignored build step do Vercel para pular builds quando apenas certos arquivos mudam (como atualizações de readme ou commits que não envolvem código).
Agrupe commits. Em vez de fazer push de 6 pequenos ajustes separadamente, organize-os e faça push uma única vez.
Nada disso é revelador. Mas na prática, a maioria dos devs em planos Hobby apenas faz push livremente e se pergunta por que ficam sem minutos até o 20º do mês.
Banda: Geralmente OK, Ocasionalmente Não
100 GB de banda por mês é onde o plano Hobby é realmente bem razoável. Para um projeto pessoal, um portfólio, um blog pequeno, até mesmo um modesto projeto SaaS paralelo com algumas centenas de usuários, você provavelmente não vai atingir esse limite.
Onde dói é em sites pesados em imagens sem uma camada CDN apropriada na frente, ou sites que sofrem um pico repentino. Tive um cliente, um músico, cujo site estava na minha conta Vercel pessoal durante um período de transição (errado da minha parte, eu sei, uso comercial e tudo mais). Uma das músicas deles foi escolhida por uma playlist de tamanho considerável e o site recebeu cerca de 40 mil visitas em 48 horas. O uso de banda disparou. Felizmente ficamos abaixo do limite, mas foi perto o suficiente para que eu os movesse do Hobby imediatamente.
Se você está usando Next.js Image Optimisation, esteja ciente de que imagens otimizadas servidas através do Vercel contam contra sua banda. E o plano Hobby tem um limite de 1.000 imagens de origem na otimização por mês. Esse é um limite que quase ninguém comenta e vai absolutamente te pegar se você estiver rodando um portfólio de fotografia ou qualquer site com conteúdo pesado em imagens.
A Questão do Uso Comercial Merece Mais Atenção
Quero voltar a isso porque acho que é genuinamente subestimado em círculos freelancer.