Um cliente ligou para mim no início de janeiro, absolutamente animado. "Gautam, eu acabei de ler que Vercel faz Docker agora. A gente pode desligar nossos droplets DigitalOcean, né?" Ele estava rodando três droplets, dois deles a $24/mês cada, um a $48. Ele tinha uma planilha pronta. Queria economizar dinheiro e queria economizar imediatamente.
Eu disse a ele para esperar duas semanas enquanto eu realmente testava. Menos mal que ele me ouviu.
A coisa é: o suporte a containers do Vercel é genuinamente impressionante. E um VPS ainda não está morto. Ambas as frases são verdadeiras ao mesmo tempo, e a nuance entre elas vale a pena entender antes de você começar a fazer docker push de tudo para a infraestrutura do Vercel e se perguntar por que suas conexões WebSocket continuam caindo.
O Que Vercel Realmente Anunciou
O suporte a Docker do Vercel, lançado através de sua Build Output API e depois formalizado para uso geral, permite que você envie um Dockerfile e deixe Vercel cuidar do runtime do container. Sem mais estar confinado às convenções Next.js ou estruturas de arquivo de função serverless. Você escreve seu Dockerfile, Vercel constrói, roda.
Isso é uma mudança genuína. Antes disso, se você tinha um backend FastAPI ou um servidor Node customizado fazendo algo exótico, você estava ou contorcendo-o para a forma de uma função serverless ou mantendo uma VPS rodando junto com seu frontend Vercel. O último era o que a maioria de nós fazia. Era irritante mas funcionava.
Como o Runtime Realmente Funciona
O container runtime do Vercel não é Docker bare-metal. É mais próximo do que você teria em um serviço de container gerenciado. Seu container recebe uma requisição, Vercel roteia-a, o container a trata. Processos persistentes funcionam. Você pode rodar algo como um servidor Python WSGI ou um binário HTTP Go. Tarefas de longa duração dentro de um único ciclo de vida de requisição funcionam bem.
Mas as limitações importam. Containers podem escalar para zero. Cold starts existem. E crucialmente: você não tem armazenamento de disco persistente. Se sua app escreve no filesystem local e espera que esses arquivos estejam lá na próxima requisição, você vai ter um mau momento.
Onde Vercel Containers Realmente Brilham
Tenho rodado uma Django REST API em containers Vercel desde março. É um serviço relativamente simples focado em leitura para um cliente de mídia, principalmente requisições GET, batendo em um banco de dados Neon Postgres. Sem escrita de arquivos. Sem background jobs. Sem WebSockets.
Tem sido excelente. Deploy previews funcionam. A integração GitHub significa que cada PR ganha seu próprio ambiente. A latência de cold start neste container específico fica em torno de 800ms a 1.2 segundos no primeiro hit após ociosidade, o que parece ruim mas é aceitável quando o tráfego do cliente é em rajadas e previsível.
O custo daquele serviço? Em torno de $20/mês com o plano Pro do Vercel considerado. O equivalente no DigitalOcean App Platform seria similar. Um droplet bruto seria mais barato, mas precisaríamos gerenciá-lo nós mesmos.
O Cenário Onde Isso é uma Vitória Clara
Pense no projeto típico de uma agência. Um site de marketing com um CMS headless, uma API leve para um formulário de contato ou alguma lógica customizada, e a necessidade de deploys rápidos. Anteriormente você teria Vercel para o frontend e um droplet de $6 para a pequena API. Agora você pode colocar tudo no Vercel, usar um dashboard, ter deploy previews para a API também. Menos coisas para manter. Menos coisas para esquecer de atualizar.
Para freelancers que cuidam de cinco a quinze sites de clientes, essa simplicidade operacional vale dinheiro de verdade, mesmo que o custo de computação seja um pouco mais alto.
Onde um VPS Ainda Vence. Claramente.
Certo. Aqui é onde preciso ser direto, porque o entusiasmo em torno dos containers do Vercel levou alguns desenvolvedores a cometer erros caros.
Operações persistentes do sistema de arquivos. Se sua app gera PDFs e os armazena localmente antes de enviar para S3, tudo bem, essa operação específica funciona. Mas se você estiver rodando algo como uma instância autohospedada de Meilisearch que escreve seu índice em disco, você precisa de armazenamento persistente. Vercel não oferece um volume montado. Você precisaria adicionar algo como um serviço Meilisearch gerenciado ou rodá-lo em um VPS. Ponto final.
WebSockets e conexões de longa duração. Os ambientes serverless e containers do Vercel têm timeouts de requisição. Encontrei esse problema com um projeto da Seahawk no final de 2024, antes mesmo do suporte a Docker chegar. Estávamos construindo uma ferramenta colaborativa em tempo real para um pequeno cliente SaaS. Tentei tudo para fazê-lo funcionar em infraestrutura serverless. Eventualmente movi o servidor WebSocket para um VPS Hetzner de $12/mês. Problema resolvido. O VPS tem rodado ininterruptamente desde então.
Background workers e cron em escala. Sim, Vercel tem cron jobs. Eles são adequados para tarefas agendadas simples. Mas se você está rodando algo como workers do Celery que processam uma fila de tarefas continuamente, você quer um processo que simplesmente... rode. Um VPS faz isso trivialmente. Em containers Vercel, você está indo contra a corrente.
Custo em volume. Este é o que surpreende as pessoas. Com tráfego baixo a médio, containers Vercel são competitivos. Mas em volumes de requisição genuinamente altos, o preço por requisição começa a se agregar. Um servidor dedicado Hetzner de $48/mês aguenta tráfego que custaria centenas de dólares no Vercel em pico. Meu cliente que queria desativar seus droplets? Um deles estava rodando um dashboard interno de alto tráfego. Fiz as contas. Manter o droplet era £18/mês mais barato mesmo levando em conta o tempo ocasional de manutenção.
As Cargas de Trabalho Específicas que Eu Nunca Moveria para Vercel
Deixa eu ser concreto. Estas são as coisas que ativamente direciono para um VPS independentemente do que Vercel lança:
- Bancos de dados autohospedados. Até mesmo uma pequena réplica Postgres para performance de leitura. Vercel não é um host de banco de dados. Use-o com Neon, Supabase ou PlanetScale, mas não tente rodar Postgres em si lá.
- Processamento de mídia. Jobs FFmpeg, filas de redimensionamento de imagens, qualquer coisa CPU-intensiva com tempos de execução imprevisíveis. Um VPS Hetzner de $20 com 2 vCPUs funciona melhor e mais barato.
- Ferramentas internas que rodam 24/7. Agentes de monitoramento, agregadores de logs, servidores proxy customizados. Essas devem estar rodando. Sempre. Escalar para zero é o inimigo aqui.
- Qualquer coisa que toque em uma GPU. Óbvio, mas vale a pena dizer.
E inversamente, aqui está o que eu colocaria com confiança em containers Vercel hoje:
- APIs REST leves (FastAPI, Express, Gin) sem estado persistente
- Apps Next.js ou Remix containerizados com configuração de servidor customizada
- APIs internas que são acessadas apenas durante horário comercial (escalar para zero é realmente ótimo aqui)
- Qualquer serviço onde você genuinamente quer deploy previews por PR
O Custo Oculto que Ninguém Fala: Complexidade Operacional
Construí mais de 12.000 sites ao longo dos anos na Seahawk. A coisa número um que morde agências e freelancers não é custo de computação. É overhead operacional.
Um VPS soa barato a $6/mês. E é barato mesmo. Mas aí você fica fazendo patches, monitorando, configurando Nginx, configurando fail2ban, ocasionalmente SSHando às 11 da noite porque algo está se comportando de forma estranha. Isso não é grátis. Isso é tempo, e tempo é caro.
Vercel remove tudo isso. Railway, Render e Fly.io também fazem. A competição real aqui não é "Vercel versus um VPS no vácuo." É "taxa de plataforma gerenciada versus taxa de tempo em ops." Para operadores solo e pequenas agências, a taxa de plataforma gerenciada geralmente é o melhor negócio.
Lá em 2019 um cliente me passou um briefing que incluía gerenciar o servidor Ubuntu deles. Orçei de acordo. Seis meses depois eu ainda estava sendo acionado sobre alertas de espaço em disco de um servidor que tecnicamente eu "gerenciava" mas tinha completamente desprioritizado. Desde então tenho sido muito mais deliberado sobre qual infraestrutura eu assumo propriedade versus qual infraestrutura eu pago uma plataforma para gerenciar.
O Framework que Realmente Uso para Decidir
Não é um fluxograma mágico. Só um conjunto de perguntas que faço em cada novo projeto:
- Esse serviço escreve em disco e espera que essas escritas persistam? Se sim, precisa de um VPS ou armazenamento gerenciado.
- Esse serviço mantém conexões de longa duração (WebSockets, SSE, gRPC streams)? Se sim, VPS ou uma plataforma que explicitamente suporte isso como Fly.io.
- Esse serviço é intensivo de CPU por períodos estendidos? Containers do Vercel têm um limite de CPU. VPS vence.
- O time precisa de deploy previews e GitOps sem pensar? Vercel vence.
- O tráfego será consistente e em alto volume? Faça as contas. VPS geralmente é mais barato acima de um certo limite.
- É um trabalho solo ou uma pequena agência que não quer pensar em servidores? Vercel vale o prêmio.
Se as perguntas 1, 2 ou 3 forem sim, estou buscando Hetzner ou DigitalOcean. Tudo o mais é uma conversa.
Como Infraestrutura Realmente Se Parece em 2026
Plataformas estão ficando melhores em armazenamento persistente. Fly.io tem Fly Volumes. Render tem discos persistentes. Vercel provavelmente adicionará algo similar eventualmente, dado com que frequência é solicitado. A lacuna entre "plataforma gerenciada" e "VPS com controle total" está diminuindo.
Mas diminuir não é o mesmo que fechar. E a economia da computação bruta não mudou fundamentalmente. Uma instância Hetzner CAX11 ARM a €3,79/mês ainda oferece uma relação custo-benefício absurdamente boa para a carga de trabalho certa. Ninguém está batendo isso em uma plataforma gerenciada pela computação equivalente.
O estado honesto do mundo em 2026 é este: o VPS não está morto. O VPS está cada vez mais opcional. Essas são coisas diferentes.
A maioria dos novos projetos que inicio na Seahawk agora usam Vercel ou Railway por padrão, a menos que algo nessa lista de perguntas acima dispare uma resposta diferente. Reduzimos o número de instâncias VPS ativas que gerenciamos em aproximadamente 40% nos últimos dezoito meses. Mas as que permanecem estão lá por boas razões, e não estão indo a lugar nenhum.
FAQ
Containers do Vercel podem substituir Docker Compose para paridade local-produção?
Mais ou menos, mas na verdade não. Docker Compose é sobre orquestrar múltiplos serviços juntos localmente. Vercel executa um único container por deployment. Se sua stack tem um servidor web, um worker e Redis todos definidos em um arquivo Compose, Vercel pode lidar com a parte do servidor web. Você ainda precisaria apontar para Redis gerenciado (Upstash é a escolha comum) e lidar com o worker separadamente. A paridade local é melhor do que era, mas Compose-para-Vercel não é uma tradução direta.
O que acontece com os containers do Vercel quando eles escalam para zero?
O processo do container para. Quando uma nova requisição chega, o Vercel o reinicia. Esse tempo de reinício é sua latência de cold start. Para binários compilados (Go, Rust) isso costuma ser menos de 500ms. Para runtimes maiores como apps baseados em JVM, pode ser de 2 a 4 segundos. Vale a pena testar em staging antes de fazer commit, porque alguns clientes vão absolutamente notar um primeiro carregamento de 3 segundos.
O suporte a containers do Vercel está disponível no plano Hobby gratuito?
A partir do início de 2026, não. Deployments de containers requerem pelo menos o plano Pro. O tier Hobby ainda suporta funções serverless e sites estáticos. Vale a pena verificar a página de preços do Vercel diretamente, já que isso mudou antes e provavelmente mudará novamente.
Quando devo usar Fly.io em vez de Vercel ou um VPS bruto?
Fly é meu padrão quando preciso de processos persistentes, distribuição global próxima aos usuários e não quero gerenciar configuração de servidor. Fica em um meio termo interessante. Você faz deploy de containers, mas tem mais controle sobre regiões, tamanhos de máquina e volumes persistentes do que o Vercel oferece. Uso para APIs de longa duração e qualquer coisa com requisitos WebSocket que precisa estar em múltiplas regiões. O tradeoff é que a DX é um pouco mais envolvida do que a integração com GitHub do Vercel.
---
O VPS não é algo que você deva usar por padrão por hábito. Mas também não é algo que você deva abandonar por entusiasmo. Conheça sua carga de trabalho. Faça as contas. E talvez aguarde duas semanas antes de desligar qualquer coisa.
Leitura relacionada: Pesquisa de palavras-chave com IA em 2026: o que é, por que tradicional, SEO técnico e busca com IA.