Cómo alojar un sitio Astro: opciones estáticas y SSR

Astro puede entregar tu sitio de dos formas muy distintas, y la que elijas decide dónde y cómo lo alojas. Por defecto Astro construye una carpeta de simples archivos HTML, CSS y JS — archivos que cualquier alojamiento estático puede servir. Pero Astro también puede ejecutarse en un servidor, renderizando páginas bajo demanda (SSR) para cosas como autenticación, formularios o datos por petición. Esta guía explica ambos modos de salida, los comandos de build que hay detrás, cómo encajan los adaptadores, y cómo elegir un alojamiento para cada uno.

Estático vs servidor: la decisión central

Toda elección de alojamiento para Astro nace de una pregunta: ¿necesita tu sitio un servidor en ejecución en el momento de la petición?

• Estático (el modo por defecto). Las páginas se renderizan una vez, en el momento del build, en archivos HTML. No hay proceso de servidor — subes la carpeta construida a un CDN o alojamiento estático y este sirve los archivos. Lo más rápido, lo más barato, lo más simple. Ideal para blogs, documentación, sitios de marketing y la mayoría de los sitios de contenido.
• Servidor / SSR. Las páginas se renderizan por petición mediante un proceso Node (o edge). Necesario cuando el contenido depende de la petición: usuarios autenticados, manejo de formularios, personalización al vuelo, o datos que deben estar frescos en cada carga.

También puedes mezclar ambos: mantener el sitio mayormente estático y optar por renderizar bajo demanda rutas específicas. La idea es renderizar de forma estática allí donde puedas, y pagar por un servidor solo donde realmente lo necesites.

Los comandos de build

Sea cual sea el modo, el flujo de trabajo son los mismos dos comandos — instalar, luego construir:

# install dependencies
npm install

# produce the production build
npm run build

# preview the production build locally before deploying
npm run preview

Por defecto npm run build escribe un sitio estático en la carpeta dist/. Esa carpeta es todo tu sitio desplegable en modo estático — no hay nada más que ejecutar.

Configurar el modo de salida

Controlas el modo en astro.config.mjs. El estático es el modo por defecto, así que una configuración mínima no necesita nada especial. Para renderizar en el servidor, añades un adaptador — un pequeño paquete que le enseña a Astro cómo ejecutarse en una plataforma específica (Node, o un runtime edge/serverless):

// astro.config.mjs — server (SSR) output with the Node adapter
import { defineConfig } from 'astro/config';
import node from '@astrojs/node';

export default defineConfig({
  output: 'server',
  adapter: node({ mode: 'standalone' }),
});

Con el adaptador Node standalone, npm run build produce un punto de entrada de servidor que inicias como cualquier app Node:

# after building with the Node adapter
node ./dist/server/entry.mjs

Si solo necesitas un puñado de rutas dinámicas, mantén la salida estática por defecto y saca páginas individuales del prerenderizado en lugar de cambiar todo el sitio a modo servidor:

---
// src/pages/dashboard.astro — render this page per request
export const prerender = false;
---

Elegir un alojamiento por modo

Alojamiento estático

Para la salida estática solo necesitas algún sitio donde servir el contenido de dist/ por HTTPS, idealmente desde un CDN. Los ajustes de build/publicación son simples:

Build command:    npm run build
Publish/output:   dist

Muchas plataformas hacen esto — alojamientos estáticos gestionados, almacenamiento de objetos tras un CDN, o un alojamiento de propósito general que pueda servir una carpeta. Como no hay servidor que mantener vivo, el alojamiento estático es barato y sin esfuerzo de escalar. Alojar en infraestructura europea es una buena opción aquí cuando tu audiencia o tus necesidades de residencia de datos apuntan en esa dirección.

Alojamiento de servidor (SSR)

El SSR necesita un runtime que mantenga un proceso vivo. Dos vías generales:

• Un alojamiento Node / VPS. Con el adaptador Node construyes un servidor standalone y lo ejecutas como cualquier servicio Node. Un VPS te da control total sobre el proceso, el entorno y el escalado — útil si ya ejecutas otros servicios allí.
• Serverless / edge. Adaptadores específicos de plataforma empaquetan tu app para ejecutarse como funciones. Menos que gestionar, pero quedas atado al modelo de esa plataforma.

Una forma simple de ejecutar el build de Node en tu propio servidor es un gestor de procesos para que se reinicie ante un fallo o reinicio:

# example: keep the Astro Node server running with PM2
npm install -g pm2
pm2 start ./dist/server/entry.mjs --name astro-site
pm2 save

Referencia rápida

Necesidad	Modo	Qué alojar
Blog, documentación, marketing, contenido	Estático (por defecto)	La carpeta dist/ en un CDN/alojamiento estático
Mayormente estático, unas pocas rutas dinámicas	Estático + prerender = false por página	Un alojamiento/adaptador que soporte rutas bajo demanda
Auth, formularios, datos por petición en todas partes	Servidor (SSR)	Un runtime Node / VPS o plataforma serverless

Cómo decidir

Empieza estático — es el modo por defecto por una razón: más barato, más rápido y más simple de alojar. Recurre al adaptador de servidor solo cuando un requisito real (estado autenticado, procesamiento de formularios, datos siempre frescos) obligue al renderizado por petición, e incluso entonces considera sacar solo esas rutas del prerenderizado en lugar de ejecutar todo el sitio en un servidor. Ajusta el alojamiento al modo con el que acabes: un alojamiento estático respaldado por CDN para los archivos construidos, o un VPS con capacidad Node / plataforma serverless cuando genuinamente necesites un servidor.