Vercel libera deploy de container a partir de Dockerfile puro

O que muda na detecção de projeto

A Vercel sempre tentou adivinhar o que você quer rodar: encontra um next.config.js e assume Next.js↳Next.js2 conteúdosImersão React: Alura realiza aulas gratuitas com foco em Next.JSGestão Dev & TI · jan 2021Criando sua primeira aplicação com RemixDev (Back & Front) · set 2024Ver tudo em Dev (Back & Front) →, encontra um manage.py e assume Django. Esse pipeline de detecção automática funciona bem para os frameworks que a plataforma reconhece, mas sempre deixou de fora quem monta runtime próprio, usa linguagem fora do radar ou simplesmente quer controlar a imagem do zero.

Segundo o changelog da Vercel, agora um Dockerfile ou Containerfile puro na raiz do projeto passa a ser usado quando nenhum outro framework é detectado. Nesse caso a plataforma seleciona o preset Container, builda esse arquivo e roteia todo o tráfego para a imagem gerada. Não existe mais a obrigação de encaixar o projeto em um buildpack conhecido para publicar na Vercel.

A ordem de prioridade que decide o que builda

Ter um Dockerfile no repositório não garante, sozinho, que ele vai ser usado. A Vercel resolve a disputa entre framework detectado e arquivo de container numa ordem fixa, e é essa ordem que explica comportamentos que à primeira vista parecem bug:

1. Se a Vercel detecta um framework conhecido (o changelog cita Django como exemplo), esse framework vence, mesmo havendo um Dockerfile na raiz.
2. Um arquivo nomeado Dockerfile.vercel ou Containerfile.vercel sempre vence sobre o framework detectado, mesmo que o projeto pareça, por exemplo, um app Next.js.
3. Para forçar o container manualmente sem renomear arquivo, dá para rodar vercel project update --framework container pela CLI ou declarar "framework": "container" no vercel.json.
4. Só quando nenhum framework é detectado e não há .vercel no nome, o Dockerfile ou Containerfile puro entra como fallback automático.

Na prática: se o seu projeto tem um package.json com dependência de algum framework que a Vercel reconhece, o Dockerfile da raiz vai ser ignorado até você forçar a troca por um dos três caminhos acima. É o tropeço mais provável de quem for testar isso num monorepo que já tem cara de app JS mas quer rodar como container puro.

O Dockerfile mínimo usado como exemplo

O exemplo que a própria Vercel publica no changelog já serve como ponto de partida honesto para testar o recurso:

FROM node:26-alpine

RUN npm i -g srvx

COPY . /app
WORKDIR /app

EXPOSE 3000
CMD [ "srvx", "--port", "3000" ]

Repare que não tem nada de mágico aqui: é uma imagem Node enxuta, um servidor (srvx) instalado global, o código copiado para /app e uma porta exposta. A Vercel não precisa entender o conteúdo do app por dentro do container, só precisa que ele escute na porta declarada. Isso é exatamente o que muda o jogo para quem usa runtime fora do trio React/Next/Django: Bun, Deno, binário Rust, worker em Go, tanto faz, desde que vire uma imagem.

Multisserviço com vercel.json

Projeto com mais de um serviço (API separada do worker, por exemplo) continua usando o bloco services do vercel.json, com um entrypoint por serviço:

{
 "framework": "container",
 "services": {
 "api": { "entrypoint": "services/api/Dockerfile" },
 "worker": { "entrypoint": "services/worker/Dockerfile" }
 }
}

Isso importa para quem já organiza o repositório como monorepo com múltiplos Dockerfiles: a plataforma não te obriga a consolidar tudo numa imagem só, mas também não builda cada pasta sozinha sem você declarar o mapeamento explicitamente.

Runtime em beta e billing por Active CPU

O Container runtime roda em cima da infraestrutura de Vercel Functions e está em beta. Isso tem duas implicações diretas:

• Cobrança por Active CPU: o runtime é cobrado com o modelo Active CPU pricing, o mesmo usado nas Functions. O changelog não detalha o mecanismo exato de cobrança nem compara custos com outras formas de hospedagem, então vale ler a documentação do Container runtime antes de estimar gastos para o seu caso.
• Superfície de beta: limites de tamanho de imagem, regiões suportadas e comportamento de cold start não aparecem detalhados no changelog. Antes de mover algo crítico de produção para esse caminho, vale ler a documentação do Container runtime linkada pela própria Vercel e testar com uma carga representativa, não só com o Dockerfile de exemplo.

Como eu testaria isso num projeto real

Nota da redação: o roteiro abaixo não foi executado em ambiente real pela redação; trata-se de um passo a passo proposto, não de uma medição feita pelo autor. Valide antes de usar em produção.

Se eu fosse validar o recurso hoje, o caminho que eu seguiria é direto, mas com um checkpoint em cada etapa:

1. Atualizar a Vercel CLI para a versão mais recente antes de qualquer coisa, para garantir que os comandos e flags usados abaixo estejam disponíveis.
2. Colocar o Dockerfile na raiz e testar localmente com docker build -t app-teste . seguido de docker run -p 3000:3000 app-teste, confirmando que o servidor sobe antes de subir pra Vercel.
3. Rodar vercel deploy e conferir no dashboard se o preset escolhido foi mesmo Container; se o projeto tiver qualquer marca de framework reconhecido, é aí que a detecção automática pode vencer sem avisar.
4. Se precisar forçar o container mesmo com framework detectável, usar vercel project update --framework container ou renomear o arquivo para Dockerfile.vercel, que tem prioridade garantida.
5. Acompanhar a fatura por Active CPU nos primeiros dias para entender se o padrão de tráfego do serviço se encaixa melhor nesse billing do que numa instância fixa.

O que fica em aberto para quem builda front-end

Para quem vive de Next.js e Vercel Functions no dia a dia, o impacto direto é menor: apps detectados continuam seguindo o pipeline de sempre. O ganho aparece em monorepos que misturam o front com serviços auxiliares (processamento de imagem, geração de PDF, um backend em linguagem que a Vercel não reconhece) e que hoje vivem espalhados em outro provedor só por causa disso.

O changelog não detalha limite de imagem, tempo de cold start do container nem se há suporte a edge network completo como nas Functions tradicionais. Antes de consolidar infraestrutura inteira ali, vale tratar o recurso como o que ele é agora: uma porta nova, ainda em beta, para quem já confia na Vercel para o front e quer parar de manter um segundo provedor só para o que não é framework.

Fonte 1: Vercel Changelog (https://vercel.com/changelog/deploy-a-container-from-a-plain-dockerfile)

"Deploy a container from a plain Dockerfile" - Vercel Changelog.

Você pode fazer deploy de um Dockerfile ou Containerfile puro na raiz do projeto usando o Container runtime da Vercel, quando nenhum outro framework é detectado. A Vercel seleciona o preset Container, builda esse arquivo e roteia todo o tráfego para a imagem resultante.

Exemplo de Dockerfile usado no changelog:

FROM node:26-alpine

RUN npm i -g srvx

COPY . /app
WORKDIR /app

EXPOSE 3000
CMD [ "srvx", "--port", "3000" ]

Quando a detecção de projeto encontra outro framework, como Django, esse framework ainda vence. Para forçar o uso do Dockerfile ou Containerfile, é possível rodar vercel project update --framework container ou declarar "framework": "container" no vercel.json.

Um arquivo Dockerfile.vercel ou Containerfile.vercel continua vencendo sobre um framework detectado, e projetos multisserviço continuam usando o bloco services do vercel.json, com um entrypoint por serviço.

O Container runtime está em beta, roda sobre Vercel Functions e é cobrado com o modelo Active CPU pricing. A própria Vercel recomenda ler a documentação do Container runtime para começar.

Fonte: Vercel Changelog