Durante anos, a resposta honesta para "Dá para rodar Docker na Vercel?" era um não bem educado. Você publicava Nuxt ou Next na edge, e o que precisava de container de longa duração ia para Fly.io, Railway ou ECS. Isso mudou em meados de 2026: a Vercel passou a tratar imagens OCI como cidadãs de primeira classe no Fluid compute, com build, registry, roteamento e autoscaling incluídos.
Este texto é para quem já entrega com Vue, Nuxt, TypeScript, Laravel ou Node e quer um mapa prático do que Docker na Vercel significa de fato—o que funciona hoje, o que ainda pertence a outro lugar e como organizar o repositório para previews continuarem rápidos.
O que "Docker na Vercel" significa em 2026
A Vercel não virou um Kubernetes genérico. Não há SSH em VM nem daemon arbitrário. Você empacota um servidor HTTP em imagem OCI; a Vercel faz o build, envia para o Vercel Container Registry (VCR) e executa como Vercel Function autoscaling no Fluid compute. A cobrança segue o modelo de Active CPU, igual às outras functions: você paga quando o código está trabalhando de verdade, não enquanto espera I/O ou fica ocioso depois que o tráfego cai.
A convenção é um Dockerfile.vercel (ou Containerfile.vercel) na raiz. No deploy, a plataforma detecta o arquivo, constrói a imagem, guarda no VCR e configura o roteamento. Cada push pode gerar URL de preview—o mesmo fluxo que o time de frontend já conhece.
A regra que derruba a maioria dos primeiros deploys
O container precisa subir um processo que escute HTTP na porta que a Vercel define pela variável PORT (padrão 80). Frameworks presos em localhost:3000 sem ler PORT falham no health check em produção mesmo com a imagem rodando bem na sua máquina.
Padrões que funcionam:
- Node / Express / Fastify:
app.listen(process.env.PORT || 3000, '0.0.0.0') - Laravel / PHP-FPM + nginx: nginx faz proxy para a app e escuta em
$PORT - Go, Rust, Java, .NET: ler
PORTna inicialização e fazer bind em0.0.0.0
Build multi-stage continua valendo: imagens finais menores deployam mais rápido e respeitam limites de tamanho. Copie só artefatos para o estágio final—as otimizações que você já usa no Docker local valem aqui.
Fluxo ponta a ponta
Caminho mínimo até a preview:
- Dockerfile.vercel na raiz com CMD de produção que sobe o servidor HTTP.
- Repositório conectado à Vercel ou vercel deploy via CLI.
- Build compila a imagem e envia para vcr.vercel.com no escopo do time e do projeto.
- URL do deployment; logs e métricas no mesmo dashboard do app Nuxt ou Next.
Se você já tem Dockerfile para outra plataforma, muitas vezes basta derivar o Dockerfile.vercel removendo ferramentas de dev e ajustando o entrypoint para PORT. No caminho feliz, não é obrigatório operar registry próprio—o VCR é por projeto e integrado ao deploy.
Para paridade local, o vercel dev orquestra functions com imagem quando a CLI do Docker e um daemon local existem. Isso ajuda a caçar o clássico "funciona no Docker, 502 na Vercel" por bind errado ou env faltando.
Onde isso encaixa em Nuxt ou arquitetura full-stack
A maioria dos projetos Nuxt 3 e 4 ainda se sai melhor no pipeline padrão: SSR via Nitro, estáticos na CDN, rotas de servidor como functions leves. Use Dockerfile.vercel quando o preset do Nitro não bastar—PHP legado ao lado de UI nova, sidecar em Go, API Laravel que você não quer reescrever em handlers serverless.
Um híbrido comum:
- Frontend: Nuxt no pipeline padrão (cold start rápido, cache na edge).
- API ou serviço HTTP: projeto Vercel separado com Dockerfile.vercel, chamado pelo Nuxt via base URL em
runtimeConfig. - Tipos compartilhados: pacote TypeScript no monorepo para composables Vue e API containerizada falarem a mesma língua.
Estado não fica no filesystem do container. As functions são stateless; upload vai para object storage, sessão para Redis ou banco, trabalho assíncrono para fila—a mesma disciplina do serverless clássico, com mais superfície para linguagens e libs de sistema dentro da imagem.
Vercel Container Registry e Sandboxes
O VCR fala Docker Registry HTTP API v2, então docker push, docker pull e docker tag funcionam em vcr.vercel.com quando o CI builda fora dos builders da Vercel. A documentação recomenda Buildx com compressão zstd para pushes manuais.
Vercel Sandbox é outra faixa: ambientes efêmeros onde dá para rodar Docker dentro do sandbox—por exemplo Postgres ou Redis em testes de integração do Nuxt sem sujar o notebook. Sandbox serve para desenvolvimento e validação; tráfego de produção continua nas Functions com imagens no VCR.
Limitações para planejar
Container functions herdam limites de memória, duração e payload das Vercel Functions. Escalam para zero após inatividade (janela menor em preview que em produção), então a primeira requisição depois do idle pode pagar cold start—parecido com serverless, embora uma imagem bem montada reduza o tempo de subida.
Em meados de 2026, duas features de rede ainda não estão disponíveis para imagens container:
- Secure Compute (conectividade privada a backends)
- Static IPs (IPs de saída fixos para allowlist)
Se o serviço dockerizado precisa chamar API bancária com allowlist de IP ou banco só na rede privada, mantenha esse pedaço em infra que suporte isso, ou exponha um BFF serverless fino na Vercel que encaminhe para a rede privada.
Custo e mentalidade operacional
Active CPU favorece APIs I/O-bound que passam a maior parte do tempo esperando banco ou terceiros—você não paga esse tempo ocioso como em VM ligada 24/7. Carga pesada de CPU (transcode de vídeo no container, transformações grandes em memória) pode estourar custo; perfil antes de migrar batch de um servidor fixo.
Observabilidade continua centralizada: logs, erros e histórico de deploy no mesmo lugar dos outros projetos. Trate o container como qualquer function—logs JSON estruturados, correlation IDs do middleware Nuxt e health checks leves.
Checklist antes do merge
- Servidor em 0.0.0.0 lendo PORT.
- Imagem sobe dentro do orçamento de cold start do time; imports lazy e base slim ajudam.
- Sem persistência em disco entre requisições.
- Secrets via variáveis de ambiente da Vercel, não em layers da imagem.
- Requisitos de rede (Static IP, Secure Compute) documentados e roteados para a plataforma certa se não forem suportados.
Docker na Vercel finalmente é a história de deploy que muita gente queria há dez anos—sem cluster próprio—mas continua sendo functions mais containers, não Docker arbitrário. Use para colocar Laravel, Go ou legado ao lado de um front Nuxt moderno, e deixe a edge rápida onde o Nitro já ganha.