Lección 4 de 410 min
Vercel: desplegar frontends
Despliegues desde Git, entornos de vista previa, funciones, dominios y variables de entorno.
Acabas de terminar el frontend de tu proyecto con Next.js. Para publicarlo «a la antigua» necesitarías un servidor, Nginx, un certificado, un script de despliegue y paciencia cada vez que algo cambie. Con Vercel conectas tu repositorio de Git y, a partir de ahí, cada git push publica una versión nueva con su propia URL.
Vercel es la empresa que creó Next.js, el framework con el que está hecha esta misma app, y su plataforma está pensada para él, aunque admite muchos otros: Vite, Astro, SvelteKit, Nuxt… En esta lección verás qué hace por ti y qué conviene vigilar.
Desplegar desde Git
Qué es un PaaS de frontend
Una plataforma que convierte tu repositorio en una web publicada, sin servidores que mantener.
- Ejemplos:
- Vercel, Netlify, Cloudflare
- Modelo:
- PaaS
Un PaaS de frontend (Vercel, Netlify, Cloudflare y similares) se especializa en un tipo de aplicación: webs y frontends con algo de lógica de servidor. Detecta tu framework, ejecuta el build, sube los archivos estáticos a una CDN y convierte las rutas de servidor en funciones que escalan solas.
Tú aportas el código y la configuración; la plataforma pone los servidores, los certificados HTTPS, la caché y los despliegues. Es el modelo PaaS que viste en la lección de AWS, afinado para el día a día de un equipo de frontend.
Úsalo cuando
Para frontends, webs de contenido y aplicaciones full stack ligeras, sobre todo si usas un framework que la plataforma conoce bien.
Ten en cuenta
La comodidad tiene un precio: con mucho tráfico o funciones muy usadas, la factura puede superar a la de un servidor propio, y algunas funciones son exclusivas de la plataforma. Los procesos largos, las colas o los WebSockets persistentes suelen encajar mejor en un contenedor o en EC2.
# Instala la CLI, enlaza la carpeta con un proyecto y despliega
npm i -g vercel
vercel link
vercel # despliegue de vista previa
vercel --prod # despliegue a producciónDespliegues desde Git
Cada push genera un despliegue; lo que llega a la rama principal va a producción.
- Producción:
- Rama main (configurable)
- Despliegues:
- Inmutables
Conectas el repositorio de GitHub, GitLab o Bitbucket y Vercel atiende a cada push. Por cada commit construye la aplicación en un entorno limpio y crea un despliegue: una versión inmutable con su propia URL. Los commits en la rama de producción, normalmente main, se publican además en tu dominio principal.
Como cada despliegue se conserva, volver atrás no exige reconstruir nada: con Instant Rollback, el dominio pasa a apuntar a un despliegue anterior en segundos. La mayoría de proyectos no necesitan configuración; si la necesitas, va en vercel.json.
Úsalo cuando
Siempre que puedas: el flujo «merge a main = publicado» elimina pasos manuales y deja un historial de qué se desplegó y cuándo.
Ten en cuenta
El build se ejecuta en Vercel, no en tu equipo: si depende de una variable de entorno o de un archivo que Git ignora, fallará allí aunque funcione en local. Y protege la rama main con revisiones obligatorias, porque lo que entra en ella sale a producción; lo verás en el módulo de CI/CD.
{
"buildCommand": "pnpm build",
"installCommand": "pnpm install --frozen-lockfile",
"redirects": [
{ "source": "/blog/:slug", "destination": "/articulos/:slug", "permanent": true }
]
}Despliegues de vista previa
Una URL propia por rama y por pull request para probar los cambios antes de publicarlos.
- URLs:
- Una por despliegue y otra por rama
Cualquier push a una rama que no sea la de producción genera un despliegue de vista previa (preview deployment) con su propia URL. Vercel la comenta en el pull request, así que quien revisa el código puede abrir la web real con los cambios, incluso desde el móvil, sin instalar nada.
Hay dos tipos de URL: una fija por despliegue, que nunca cambia, y otra por rama, que siempre apunta al último commit de esa rama. Las vistas previas usan sus propias variables de entorno, así que pueden hablar con una base de datos de pruebas en lugar de la real.
Úsalo cuando
En cada pull request: diseño, producto y QA revisan la versión real, y las pruebas end to end pueden ejecutarse contra esa URL.
Ten en cuenta
Una vista previa es accesible desde Internet salvo que la protejas: Vercel ofrece protección de despliegues, que en los proyectos recientes suele venir activada para las vistas previas. Y no la conectes a los datos de producción: cualquiera que pruebe un formulario estaría escribiendo en la base de datos real.
Producción https://tienda.com
Rama «nuevo-checkout» https://tienda-git-nuevo-checkout-mi-equipo.vercel.app
Un despliegue concreto https://tienda-k3j9x2a1q-mi-equipo.vercel.app¿Sabías que…?
Vercel se llamaba ZEIT cuando creó Next.js, en 2016. Esta misma app está hecha con Next.js: cada lección que lees se genera de antemano durante el build y se sirve como una página ya preparada.
Funciones, dominios y variables de entorno
Vercel Functions
El código de servidor de tu app, convertido en funciones que escalan solas.
- Runtimes:
- Node.js (recomendado) y edge
- Se paga:
- Por uso
Las rutas de servidor de tu framework (en Next.js, los Route Handlers y las páginas que se renderizan en cada petición) se despliegan como Vercel Functions: código que se ejecuta bajo demanda, escala con el tráfico y se cobra por uso, como el serverless que viste con Lambda.
Pueden usar el runtime de Node.js, con todas sus APIs y los paquetes de npm, o el runtime edge, más ligero y limitado a APIs web estándar como fetch y Request. Hoy Vercel recomienda Node.js para la mayoría de casos, y en las versiones recientes de Next.js el runtime edge está marcado como obsoleto.
Cada función se ejecuta en una región que puedes elegir, y por defecto suele estar en Estados Unidos. Si tu base de datos está en Fráncfort, lleva la función allí: si no, cada consulta cruzará el Atlántico.
Úsalo cuando
Para las APIs del propio frontend, formularios, webhooks y páginas que se renderizan en cada petición.
Ten en cuenta
Tienen una duración máxima configurable y no están pensadas para tareas largas ni para conexiones abiertas: para eso, una cola o un servidor. No guardes estado en memoria entre peticiones: la siguiente puede ejecutarse en otra instancia.
// Este Route Handler se despliega como una Vercel Function
export const maxDuration = 10; // segundos como máximo
export async function GET(request: Request) {
const sku = new URL(request.url).searchParams.get("sku");
if (!sku) return Response.json({ error: "Falta el sku" }, { status: 400 });
const stock = await consultarStock(sku); // tu acceso a la base de datos
return Response.json({ sku, stock });
}Dominios y variables de entorno
Tu dominio con HTTPS automático y una configuración distinta para cada entorno.
- Entornos:
- Production, Preview, Development
- HTTPS:
- Automático
Cada proyecto recibe un subdominio de vercel.app y puedes añadir los tuyos: apuntas el DNS a Vercel (con un registro A o CNAME, o cediéndole los nameservers) y la plataforma emite y renueva sola el certificado HTTPS. También puedes asignar un dominio a una rama, como staging.tienda.com a la rama staging.
Las variables de entorno se definen por entorno: Production, Preview y Development. Así, producción usa la clave real de la pasarela de pagos, las vistas previas la de pruebas, y vercel env pull descarga las de desarrollo a tu .env.local.
Úsalo cuando
Para separar la configuración y los secretos del código: claves de API, URLs de bases de datos, banderas de funcionalidades.
Ten en cuenta
Si cambias una variable, vuelve a desplegar: los despliegues existentes conservan los valores con los que se crearon. En Next.js, las variables que empiezan por NEXT_PUBLIC_ se incrustan en el JavaScript que descarga el navegador: nunca pongas un secreto con ese prefijo.
# Añade un secreto solo para producción (te pedirá el valor)
vercel env add STRIPE_SECRET_KEY production
# La misma variable, con la clave de pruebas, para las vistas previas
vercel env add STRIPE_SECRET_KEY preview
# Descarga las variables de desarrollo a .env.local
vercel env pull .env.localLa CDN de Vercel e ISR
Lo más rápido es no ejecutar nada: servir una copia ya generada desde un servidor cercano. La CDN de Vercel hace eso con tus archivos estáticos y, con ISR, también con páginas que cambian de vez en cuando.
CDN, caché e ISR
Archivos estáticos en todo el mundo y páginas que se regeneran en segundo plano.
- ISR:
- Incremental Static Regeneration
- Cabecera:
- x-vercel-cache
Todo lo que el build genera como estático (HTML prerenderizado, JavaScript, CSS, imágenes) se sirve desde la CDN de Vercel, cerca del usuario. Las respuestas de tus funciones también se pueden cachear si envían una cabecera como Cache-Control: s-maxage=60, y la cabecera x-vercel-cache te dice si una respuesta fue HIT, MISS o STALE.
ISR (Incremental Static Regeneration) es una función de Next.js que Vercel gestiona de forma nativa: la página se genera una vez y se sirve desde caché; pasado el tiempo de revalidación, la siguiente visita todavía recibe la copia antigua mientras la nueva se genera en segundo plano. También puedes regenerarla al momento con revalidatePath, por ejemplo cuando tu CMS avisa de un cambio.
Úsalo cuando
ISR para páginas iguales para todos que cambian de vez en cuando: fichas de producto, artículos, documentación. Para datos que deben ser exactos al segundo, renderiza en cada petición.
Ten en cuenta
Con ISR, algún visitante verá la versión anterior durante un rato: es el precio de la velocidad. No cachees en la CDN respuestas que dependen del usuario conectado. Y en las versiones recientes de Next.js con Cache Components activado, como esta app, la misma idea se expresa con la directiva "use cache" y la función cacheLife.
// Se sirve desde caché y se regenera, como mucho, una vez por hora
export const revalidate = 3600;
export default async function Producto({ params }: { params: Promise<{ slug: string }> }) {
const { slug } = await params;
const producto = await fetch(`https://api.tienda.com/productos/${slug}`).then((r) => r.json());
return <h1>{producto.nombre}</h1>;
}
// En app/api/cms/route.ts, tras comprobar un secreto compartido con el CMS:
// revalidatePath("/productos/[slug]", "page");Interactivo
¿Dónde publico mi frontend?
Cuatro formas habituales de llevar un frontend a producción, de la más gestionada a la que más control te da.
| Característica | Vercel | Cloudflare | S3 + CloudFront |
|---|---|---|---|
| Qué gestionas tú | Código y configuración | Código y configuración | Bucket, distribución, certificados y pipeline |
| Despliegue | Automático desde Git | Desde Git o con la CLI Wrangler | Lo montas tú, o con un servicio como Amplify Hosting |
| Vistas previas por rama | Sí, integradas en los pull requests | Sí | Solo si las construyes tú |
| Código de servidor | Vercel Functions | Workers | Aparte: Lambda, ECS… |
| Encaja con | Next.js y frameworks de frontend | Webs globales y lógica en el edge | Sitios estáticos dentro de una arquitectura en AWS |
Ponlo en práctica
Saber qué es cada cosa es la mitad del trabajo. La otra mitad es reconocer cuándo usarla.
Interactivo
¿Qué usarías?
Lee cada situación y elige la opción que mejor la resuelve. Fallar aquí no cuenta: es para practicar.
La diseñadora quiere revisar el nuevo proceso de pago en su móvil antes de que se fusione el pull request.
Para recordar
- Vercel es un PaaS de frontend: conectas Git y cada push construye y publica un despliegue inmutable.
- La rama de producción va a tu dominio; cualquier otra rama genera una vista previa con su propia URL.
- El código de servidor se convierte en Vercel Functions: colócalas en la región de tus datos y no guardes estado en memoria.
- Las variables de entorno van por entorno (Production, Preview, Development) y requieren un nuevo despliegue;
NEXT_PUBLIC_significa público. - La CDN sirve lo estático y, con ISR, también páginas que se regeneran en segundo plano.
Comprueba lo aprendido
Cuestionario
Responde las 5 preguntas para completar la lección.
1.Haces push a la rama
nuevo-menu, que no es la de producción. ¿Qué hace Vercel?2.Guardas tu clave secreta de pagos en
NEXT_PUBLIC_STRIPE_SECRET. ¿Qué problema hay?3.Cambias en el panel el valor de una variable de entorno de producción. ¿Cuándo lo verá tu app?
4.Una página usa ISR con
revalidate = 3600. Un visitante llega justo después de pasar la hora. ¿Qué recibe?5.Tu Vercel Function guarda en una variable global el carrito de cada usuario. ¿Qué fallará?