Deploy: edge, CDN o contenedor

El destino de un despliegue no es un detalle de infraestructura que se decide al final, sino la consecuencia directa de cómo y cuándo tu aplicación produce su HTML. Existen tres familias de destinos, y cada una encaja con una naturaleza de render distinta. Un sitio estático se sube a un CDN, que sirve archivos ya construidos desde el borde de la red sin ejecutar nada por petición. Una app con render en servidor puede desplegarse al edge, donde una función se ejecuta cerca del usuario en cada petición, pero dentro de un runtime restringido. Y una app que necesita un proceso vivo y persistente se empaqueta en un contenedor Docker y corre en un VPS que controlas de arriba abajo. Elegir entre las tres no es cuestión de moda ni de precio aislado: es responder con precisión una sola pregunta, dónde y cuándo se genera cada byte de tu respuesta, y aceptar quién paga la complejidad que esa respuesta arrastra.

El destino se sigue del render

Antes de mirar plataformas conviene fijar el eje que las ordena, porque sin él la elección parece un menú de marcas y en realidad es una consecuencia técnica. Dos preguntas bastan: cuándo se produce el HTML y dónde corre el código que lo produce. Un sitio generado estáticamente resuelve su HTML en build time: cuando el build termina, cada página ya existe como un archivo, y desplegar es solo mover archivos. Una app con render en servidor resuelve su HTML en request time: no hay archivo previo, hay un handler que se ejecuta en cada petición, y ese handler tiene que vivir en algún sitio capaz de ejecutar código. La segunda pregunta, la de dónde, parte ese “algún sitio” en dos: un runtime efímero y distribuido en el borde, o un proceso persistente en un servidor de origen.

De ese eje caen las tres familias sin ambigüedad, y también los híbridos. Frameworks como Astro permiten decidir el modo por ruta: una landing y un blog se prerenderizan a estático mientras un panel autenticado se sirve por SSR, de modo que la misma app reparte cada ruta al destino que le corresponde. La pregunta operativa deja de ser “estático o servidor” en bloque y pasa a ser, ruta por ruta, si su HTML puede fijarse en el build o si depende de datos que solo existen en el instante de la petición.

Ese eje también explica por qué el coste y la resiliencia cambian tanto entre destinos, y no por capricho de precios. Servir un archivo ya calculado cuesta lo mismo por petición pase lo que pase, así que el CDN absorbe picos sin inmutarse; ejecutar un handler es trabajo por petición, de modo que el edge y el contenedor escalan su cómputo con el tráfico y pueden llegar a saturarse. La naturaleza de render no solo dice dónde corre el código: predice cómo se degrada el sistema cuando llega una avalancha de tráfico.

flowchart TD
SRC[codigo fuente] --> BUILD[build]
BUILD --> STATIC[HTML estatico en build time]
BUILD --> HANDLER[handler SSR por peticion]
STATIC --> CDN[CDN sirve archivos desde el borde]
HANDLER --> EDGE[edge ejecuta en isolates cerca del usuario]
HANDLER --> CONT[contenedor con proceso vivo en un VPS]
style STATIC fill:#a6e3a1,color:#11111b
style EDGE fill:#89b4fa,color:#11111b
style CONT fill:#f9e2af,color:#11111b

Estático a un CDN

Cuando el build produce un directorio de archivos —HTML, CSS, JavaScript, imágenes—, desplegar es en esencia copiarlo al almacenamiento de un CDN que lo replicará por sus puntos de presencia. Lo que hace este destino tan barato y tan robusto es que no ejecuta nada por petición: el borde solo entrega bytes ya calculados, así que absorber un pico de tráfico es servir el mismo archivo más veces, no computar más. La pieza técnica que hay que dominar aquí no es el despliegue en sí, que es trivial, sino el cacheado, porque un CDN es antes que nada una caché geográfica y su corrección depende de las cabeceras que le mandas.

Hay dos regímenes de caché, y confundirlos rompe el sitio de una de dos formas. Los assets con nombre versionado por hash —app.9f3c2a.js— son inmutables por construcción: si el contenido cambia, cambia el nombre, así que se pueden cachear para siempre. El HTML, en cambio, conserva su URL estable y debe revalidarse; si lo cacheas eterno, servirías la página vieja apuntando a assets que ya no existen. La regla es exacta: cachea eterno lo que lleva hash y revalida lo que no.

/_astro/*
  Cache-Control: public, max-age=31536000, immutable
/*.html
  Cache-Control: public, max-age=0, must-revalidate

El otro rasgo que distingue a un CDN maduro es que el despliegue es atómico: la versión nueva de todos los archivos se publica de golpe y la invalidación del borde es casi instantánea, de modo que ningún usuario ve un estado a medias con HTML nuevo apuntando a assets viejos ni al revés. Subir archivos sueltos sin esa atomicidad abre una ventana de incoherencia visible; las plataformas serias la cierran publicando el conjunto entero como una unidad y purgando el borde en bloque.

SSR al edge

Cuando la app renderiza en servidor pero no necesita un proceso persistente, el edge es el destino natural. Un adapter —@astrojs/cloudflare, @astrojs/vercel en su modo edge, o el equivalente de Netlify sobre Deno— transforma tu app en un handler que la plataforma ejecuta en isolates de V8 repartidos por todo el mundo. La diferencia con un servidor tradicional es doble y profunda: el arranque en frío es prácticamente nulo, porque un isolate no es un contenedor que haya que arrancar sino un contexto de V8 que se crea en microsegundos; y el código corre en el punto de presencia más cercano al usuario, no en una región única, así que la latencia de red se desploma para una audiencia global.

Ese poder viene con un runtime que no es Node completo, y ese es el error que más despliegues al edge rompe. El estándar es WinterCG: fetch, Request, Response, Web Crypto y los streams web están presentes; el sistema de archivos, los sockets crudos y muchos módulos nativos no. A lo largo de 2026 la bandera de compatibilidad con Node de Workers ha cerrado gran parte de esa brecha, pero la mentalidad correcta sigue siendo la inversa: el edge es un runtime de estándares web con extras, no un Node al que le faltan cosas. Hay además límites duros de tiempo de CPU por petición y de tamaño del bundle, pensados para que miles de isolates convivan en cada máquina.

Entre el edge y el contenedor hay un tercer punto que conviene conocer: las funciones serverless con Node completo, como las de Vercel, Netlify o AWS Lambda. Ejecutan tu handler bajo demanda igual que el edge, pero en un runtime de Node de verdad, así que aceptan el sistema de archivos y los módulos nativos que el isolate rechaza; a cambio pagan un arranque en frío real —cientos de milisegundos cuando la función llevaba dormida— y suelen correr en una única región, no en todas a la vez. Son el destino natural cuando necesitas Node de verdad pero no un proceso siempre encendido.

# desplegar una app SSR a Cloudflare Workers
pnpm astro build
pnpm wrangler deploy

flowchart LR
U[usuario] --> POP[PoP edge mas cercano]
POP --> ISO[isolate ejecuta el handler]
ISO --> R[HTML por peticion]
R --> U
ORIG[origen unico y lejano] -. mayor latencia .-> U
style POP fill:#89b4fa,color:#11111b
style ISO fill:#cba6f7,color:#11111b
style R fill:#a6e3a1,color:#11111b

En un contenedor sobre un VPS

Cuando la app necesita lo que el edge te niega —un proceso vivo entre peticiones, acceso al sistema de archivos, conexiones WebSocket largas, trabajos en segundo plano, cualquier módulo nativo—, el destino es un contenedor Docker corriendo en un VPS. Aquí el adapter es @astrojs/node en modo standalone, que emite un servidor que escucha en un puerto, y el contenedor lo empaqueta con todo lo que necesita para correr en cualquier máquina igual que corre en la tuya. El patrón canónico es un Dockerfile multi-etapa: una etapa instala y construye con todo el toolchain, y una etapa final ligera se queda solo con lo imprescindible para ejecutar.

# etapa de build: instala el toolchain y construye
FROM node:22-slim AS build
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile
COPY . .
RUN pnpm build

# etapa de runtime: solo lo necesario para ejecutar
FROM node:22-slim AS runtime
WORKDIR /app
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
ENV HOST=0.0.0.0 PORT=4321
EXPOSE 4321
CMD ["node", "./dist/server/entry.mjs"]

Partir el Dockerfile en dos etapas no es cosmético: la imagen final no debe contener el toolchain de build, ni el código fuente, ni las dependencias de desarrollo, sino solo el runtime y lo que este ejecuta. Una imagen pequeña se despliega antes, arranca antes y ofrece menos superficie de ataque; por eso la etapa de runtime parte de una base ligera como slim o distroless y copia únicamente lo construido. Cada megabyte que no está en la imagen es uno que no hay que mover, escanear ni mantener.

Y como el contenedor es un proceso vivo, escalarlo horizontalmente exige que sea sin estado: si guardas sesiones o caché en la memoria de una réplica, dos réplicas detrás de un balanceador se contradicen. El estado compartido se externaliza a Redis, a la base de datos o a un almacén de sesiones, y el contenedor queda como una unidad intercambiable de la que puedes correr una o cincuenta copias idénticas. Esa disciplina sin estado es lo que convierte un servidor en una flota que escala.

El control total tiene un precio, y es todo lo que el CDN y el edge hacían por ti y ahora es tuyo. Tú terminas el TLS con un proxy inverso como Caddy o Traefik; tú supervisas el proceso para que reviva si cae; tú escalas poniendo réplicas detrás de un balanceador; tú parcheas el sistema operativo; tú cableas los logs y las métricas. Plataformas como Fly.io, Railway, Render o un PaaS autoalojado como Coolify recuperan buena parte de esa comodidad sobre contenedores, difuminando la frontera entre un VPS crudo y una plataforma gestionada. El eje real no es contenedor contra serverless, sino cuánta operación estás dispuesto a asumir a cambio de cuánto control necesitas.