Vercel agora roda qualquer Dockerfile na plataforma Fluid compute

A Vercel adicionou à sua plataforma suporte a contêineres arbitrários. Agora os desenvolvedores podem fazer o deploy de qualquer serviço com Dockerfile, de um serviço em Go a uma aplicação em Rails ou Spring Boot. Basta adicionar o arquivo Dockerfile.vercel na raiz do projeto: a própria plataforma constrói a imagem e a implanta na infraestrutura Fluid compute.

Como funciona

O mecanismo é mínimo: o servidor e o arquivo Dockerfile.vercel bastam para o projeto estar pronto para o deploy. A Vercel mostra um exemplo em Go: um servidor HTTP que escuta a porta definida na variável $PORT (por padrão, 80) e é construído com um Dockerfile de dois estágios. Primeiro, a imagem golang:1.24-alpine compila o binário; depois, ele é copiado para a imagem mínima alpine:3.20, que é a que roda em produção.

O comando `vercel deploy` na CLI constrói a imagem, armazena no registro do projeto, faz o deploy no Fluid compute e retorna a URL de produção. Cada git push reconstrói a imagem automaticamente e cria um deploy de preview separado, com URL imutável, que pode ser aberta, compartilhada com colegas ou usada para reverter a uma versão anterior.

• A única exigência para o servidor é escutar a porta HTTP definida na variável $PORT
• O exemplo do blog usa a combinação golang:1.24-alpine e alpine:3.20 em um build de dois estágios
• O deploy é disparado com um único comando `vercel deploy` na CLI ou automaticamente a cada git push
• Há suporte a Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI e serviços atrás de nginx

Quais linguagens e frameworks são suportados

A Vercel ressalta que a stack específica não importa: funciona qualquer serviço que fale HTTP e escute uma porta. A lista inclui explicitamente Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI e servidores web atrás de nginx, incluindo Java e PHP, plataformas que até então eram associadas mais à hospedagem tradicional de servidores do que à infraestrutura serverless da Vercel.

O que os desenvolvedores ganham

O contêiner na Vercel passa a ser um cidadão de primeira classe da plataforma: ele roda na mesma infraestrutura que o frontend e os demais serviços do projeto. Cada commit recebe seu próprio deploy de preview com URL separada, e o escalonamento acontece automaticamente nos dois sentidos. Quando o tráfego cresce, a plataforma adiciona instâncias; quando cai, ela as desativa. Assim, a equipe não precisa calcular manualmente o tamanho da frota nem o limite de concorrência.

A cobrança segue o modelo Active CPU: o Fluid compute fatura apenas o tempo em que o código do serviço está de fato em execução, e não todo o tempo de vida da instância. Na prática, um servidor ocioso, parado à espera de uma consulta lenta ao banco de dados, não custa à equipe mais do que um que está trabalhando ativamente.

O que isso significa

O Dockerfile.vercel apaga a fronteira entre plataformas serverless como a Vercel e as nuvens de contêineres tradicionais. Agora qualquer serviço em Java, PHP ou Ruby pode ser implantado sem configurar registro de imagens, daemon ou cluster próprios, com escalonamento automático e deploys de preview por padrão.

Perguntas frequentes

Quais são os requisitos do servidor para o deploy?

A única condição é que o servidor escute HTTP na porta definida na variável de ambiente $PORT (por padrão, 80). Se o serviço responde a requisições HTTP, ele pode ser empacotado em um Dockerfile.vercel e implantado.

O que acontece a cada commit?

Cada git push reconstrói a imagem e cria uma URL de preview separada, que pode ser aberta, compartilhada ou usada para reverter a uma versão anterior do projeto.

Com quais frameworks isso funciona?

Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI e serviços atrás de nginx. O exemplo do blog da Vercel usa a combinação golang:1.24-alpine e alpine:3.20 em um build de dois estágios.