--- title: "Vercel ahora soporta Docker: por qué importa" excerpt: "Vercel deja desplegar cualquier Dockerfile sobre su infraestructura con autoscaling y pricing por uso. Más que una feature, es una señal de hacia dónde va el deploy." date: "2026-06-30T18:00:00.000Z" category: "DevOps" tech_article: true author: name: "angel cruz" picture: "https://angelcruzdevcdn.nyc3.cdn.digitaloceanspaces.com/images/me/angel-cruz.png" seo_title: "Vercel soporta Dockerfile: qué significa y por qué importa" seo_description: "Vercel ahora despliega cualquier Dockerfile sobre Fluid Compute con autoscaling y Active CPU pricing. Qué significa para tu stack y para otros proveedores." --- **Vercel ahora deja desplegar cualquier Dockerfile directamente sobre su infraestructura.** Agregas un archivo `Dockerfile.vercel` a tu proyecto y Vercel se encarga de construir la imagen, guardarla, desplegarla y autoescalarla sobre Fluid Compute, con una URL de producción lista. Suena a "una feature más", pero es una señal importante de hacia dónde va el deploy. Vamos por partes. ## Qué anunció Vercel exactamente Lo concreto, según el [anuncio oficial](https://vercel.com/blog/dockerfile-on-vercel): - Pones un `Dockerfile.vercel` y Vercel **construye, guarda, despliega y autoescala** la imagen. - Corre sobre **Fluid Compute**, la misma infraestructura que ya usan sus funciones. - Funciona con **cualquier framework**: Rails, Spring Boot, Express, **Laravel**, ASP.NET, FastAPI o un servidor detrás de nginx "se despliegan igual". El único requisito es que el servidor escuche en la variable `$PORT` (por defecto el 80) y hable HTTP. - Trae lo que ya esperas de Vercel: **preview deploys** por cada push, autoescalado bidireccional, **Active CPU pricing** (pagas por el tiempo que tu código realmente corre), arranque rápido y observabilidad integrada. > los contenedores son **stateless**. Para datos persistentes necesitas un servicio aparte (base de datos, storage) del Marketplace, y el almacenamiento durable integrado está anunciado como "viene pronto". ## Por qué importa: Vercel deja de ser "solo frontend" Durante años, la etiqueta mental de Vercel fue "donde despliegas tu Next.js". Esto la rompe. **Si puedes empaquetar tu app en un contenedor, puedes correrla en Vercel**, sea Laravel, FastAPI o lo que sea. El backend y el frontend pasan a vivir en la misma plataforma, con la misma experiencia de desarrollo (preview URLs, autoscaling, logs y métricas) para cualquier lenguaje. Eso cambia la conversación de "frontend en Vercel, backend en otro lado" a "todo aquí, si quiero". ## Docker como contrato universal (y menos lock-in) Lo más interesante es la decisión de aceptar **cualquier Dockerfile** en vez de obligarte a sus convenciones de runtime. Docker es un estándar abierto y portable: la misma imagen corre en tu máquina, en Vercel o en otro proveedor. Al adoptar ese contrato, Vercel reduce el miedo al lock-in justo abrazando el formato más portable que existe. Si mañana quieres irte, te llevas tu Dockerfile. ## Qué significa para Laravel, PHP y otros lenguajes Esto se vuelve muy concreto si trabajas fuera de JavaScript. **Antes no podías correr Laravel en Vercel de forma nativa; ahora es cuestión de un Dockerfile**. Lo mismo aplica para FastAPI, Spring Boot o ASP.NET. La plataforma deja de ser territorio casi exclusivo de JavaScript y se abre a stacks que antes resolvías con un VPS, Railway o Cloud Run. ## Qué puede significar para otros proveedores Aquí entro en terreno de análisis, no de hechos. Lo que Vercel está haciendo (acepta un Dockerfile + autoescalado serverless + pricing por uso + preview environments) es, en la práctica, el modelo que ya empujaban **Fly.io, Railway, Render y Google Cloud Run**. La diferencia es que Vercel le suma su DX pulida y su base de usuarios de frontend. Mi lectura de lo que puede venir: - **Se vuelve table stakes** ese combo "push de un contenedor → autoscaling + URLs de preview + pago por uso". Lo que era diferenciador de los PaaS modernos pasa a ser lo mínimo esperable. - **Presión sobre Netlify y plataformas frontend-first** para ofrecer lo mismo o quedar como "solo estáticos". - **Validación del modelo de Cloud Run / Fly / Railway**, pero con la vara de DX más alta. - La frontera **PaaS vs serverless vs contenedores se sigue difuminando**: contenedores arbitrarios con escalado serverless y facturación por CPU activa. No es que Vercel haya inventado nada nuevo; es que un actor con mucha distribución normaliza el patrón. Y cuando eso pasa, el resto suele moverse. ## Conclusión El titular es "Vercel soporta Docker". La historia real es que **el deploy converge**: contenedores portables como entrada, escalado serverless y pago por uso como base, y la misma experiencia para frontend y backend. Para ti significa una opción más (y muy cómoda) para llevar tu stack a producción; para el mercado, una señal de hacia dónde va todo. ## Preguntas frecuentes ### ¿Qué significa que Vercel soporte Docker? Que puedes desplegar cualquier app contenedorizada en Vercel agregando un archivo `Dockerfile.vercel`. Vercel construye, almacena, despliega y autoescala la imagen sobre Fluid Compute, sin limitarte a frameworks de JavaScript. ### ¿Puedo desplegar Laravel o FastAPI en Vercel ahora? Sí. El anuncio menciona explícitamente Laravel, FastAPI, Rails, Spring Boot, ASP.NET y Express. El único requisito es que tu servidor escuche en `$PORT` y hable HTTP. ### ¿Los contenedores en Vercel guardan datos? No: son stateless. Para datos persistentes necesitas un servicio externo (base de datos o storage) del Marketplace. El almacenamiento durable integrado está anunciado como próximo. ### ¿Esto reemplaza a Fly.io, Railway o Cloud Run? No los reemplaza, pero compite directamente con su modelo (Dockerfile + autoscaling + pago por uso). La diferencia de Vercel es su experiencia de desarrollo y tener frontend y backend en una sola plataforma. --- ## Sitemap Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md) Canónico HTML: [https://www.angelcruz.dev/post/vercel-soporta-docker](https://www.angelcruz.dev/post/vercel-soporta-docker)