Post-deploy: operar el sitio en producción

Hay un espejismo peligroso el día que el sitio se publica: creer que el trabajo terminó. En realidad acaba de empezar otro distinto. Un sitio en producción es un sistema vivo que recibe tráfico real, guarda secretos, puede degradarse y a veces hay que devolver a un estado anterior a toda prisa. Operarlo bien exige cinco disciplinas que nada tienen que ver con escribir componentes: gestionar las variables de entorno sin filtrar secretos, montar observabilidad para saber qué pasa dentro, tener rollbacks listos para deshacer un mal despliegue, exponer healthchecks que confirmen que el sitio responde, y administrar el dominio con su DNS y su TLS. Esta lección es sobre lo que ocurre después del despliegue: el oficio silencioso de mantener algo en pie.

Variables de entorno en producción

El código es el mismo en todas partes; lo que cambia entre tu máquina y producción son los valores: la URL de la API, la clave de un servicio, el identificador de analítica. Esos valores no se escriben en el código —se inyectan como variables de entorno—, y Astro 7 los gobierna con astro:env, un módulo que los declara con tipo y, sobre todo, con una frontera clara entre lo público y lo secreto.

// astro.config.mjs
import { defineConfig, envField } from 'astro/config';

export default defineConfig({
  env: {
    schema: {
      API_URL: envField.string({ context: 'server', access: 'secret' }),
      PUBLIC_ANALYTICS: envField.string({ context: 'client', access: 'public' }),
    },
  },
});

La distinción context y access es el corazón del sistema. Una variable de context: 'server' y access: 'secret' nunca sale al navegador: vive solo en el runtime, y si por error intentas usarla en el cliente, el build te detiene. Una public sí puede viajar al cliente porque no esconde nada sensible. Consumirlas es una importación tipada, no un acceso a un objeto global sin garantías.

import { API_URL } from 'astro:env/server';
// tipado, validado en el build, e imposible de filtrar al cliente

Las dos dimensiones —context y access— se combinan en un pequeño mapa que conviene tener claro para no filtrar nada por descuido:

• server mas secret: una clave de API o un token; vive solo en el runtime y jamás llega al navegador.
• server mas public: un valor no sensible que solo usa el servidor, como una región o un modo.
• client mas public: un identificador de analítica o una URL pública; puede viajar al cliente sin riesgo.
• client mas secret: una combinación que no existe, porque un secreto en el cliente ya no es secreto.

Observabilidad: ver dentro de la caja

Una vez desplegado, tu sitio es una caja que recibe peticiones y devuelve respuestas, y sin instrumentación no tienes ni idea de qué ocurre dentro. La observabilidad son las tres ventanas que abres para verlo, y cada una responde una pregunta distinta.

En un sitio estático la observabilidad la aporta casi entera el CDN —códigos de estado, aciertos de caché, ancho de banda—. En SSR se vuelve crítica: cada ruta bajo demanda ejecuta tu código, y necesitas ver sus logs, medir su latencia y saber su tasa de error. La regla práctica es registrar con intención —un log por evento significativo, con contexto suficiente para reconstruir qué pasó— y no ahogar la señal en ruido. Los logs que nadie lee son coste sin valor; los que cuentan una historia son lo primero que agradeces a las tres de la mañana.

Las métricas, además, solo cobran sentido cuando les pones un umbral. Un número aislado —cien milisegundos de latencia— no dice nada; comparado con el objetivo que te fijaste, se vuelve una señal accionable. Definir esos umbrales por adelantado —cuánta latencia toleras, qué tasa de error dispara una alerta— es lo que convierte un panel bonito en un sistema que te avisa antes de que el usuario se queje. Sin umbrales, la observabilidad es decoración; con ellos, es un sentido que se activa solo.

Rollbacks y healthchecks

Por muy buena que sea tu observabilidad, algún despliegue saldrá mal. La pregunta no es si ocurrirá, sino cuánto tardarás en recuperarte, y dos mecanismos definen esa respuesta.

Un healthcheck es un endpoint mínimo que confirma que el sitio está vivo. La plataforma lo consulta a intervalos, y si deja de responder correctamente, sabe que algo se rompió sin esperar a que un usuario lo reporte.

// src/pages/health.ts  -> una ruta bajo demanda que solo dice ok
export const prerender = false;
export const GET = () => new Response('ok', { status: 200 });

Un rollback es volver a la versión anterior cuando la nueva falla. Aquí brilla la disciplina de las lecciones previas: si cada despliegue corresponde a un commit y cada build es un artefacto inmutable, volver atrás es reactivar el artefacto anterior, no reconstruir a la carrera bajo presión. Las plataformas Git-driven lo ofrecen con un clic —promover un despliegue previo— y esa es justamente la recompensa de haber hecho los despliegues reproducibles: el peor momento, el de un fallo en producción, se resuelve con una operación tranquila y ya probada.

Sobre esa base de artefactos inmutables, las plataformas ofrecen estrategias que reducen aún más el riesgo de cada publicación:

• Despliegue progresivo: la versión nueva recibe primero un porcentaje del tráfico y solo crece si se comporta bien.
• Azul-verde: dos entornos idénticos conviven, y publicar es apuntar el tráfico de uno al otro, reversible al instante.
• Inmutabilidad: cada versión conserva su artefacto, así que volver atrás nunca implica reconstruir nada bajo presión.

Dominios, DNS y TLS

La última milla es la dirección por la que el mundo llega a tu sitio. Un dominio se apunta a tu despliegue mediante registros DNS —un CNAME hacia la plataforma, o un A hacia una IP— y esa propagación tarda un tiempo en verse en toda la red. Sobre el dominio se monta el TLS: el certificado que habilita HTTPS, hoy emitido y renovado de forma automática por casi todas las plataformas, de modo que el candado del navegador no exige gestión manual.

# El patron habitual de DNS para un despliegue moderno:
# raiz     -> registro A o ALIAS hacia la plataforma
# www      -> registro CNAME hacia el destino del proveedor
# el TLS lo emite y renueva la plataforma sin intervencion

Aquí se cierra el círculo con las claves de configuración de Astro: el dominio que apuntas por DNS debe coincidir con el site que declaraste, porque de él dependen el sitemap, las etiquetas canónicas y los enlaces absolutos. Un dominio nuevo sin actualizar site produce un sitio que funciona pero se enlaza a sí mismo con la dirección vieja.

El despliegue de un dominio serio sigue siempre la misma secuencia, y saltarse un paso deja el sitio a medias:

• Apuntar los registros DNS al destino y esperar a que la propagación se complete en toda la red.
• Verificar la propiedad del dominio si la plataforma lo exige, para que emita el certificado a tu nombre.
• Confirmar que el TLS se emitió y que HTTPS responde, y que el tráfico HTTP redirige hacia él.
• Alinear el site de Astro con el dominio final, para que sitemap y canónicas nombren la dirección buena.

flowchart TD
DEP[nuevo deploy en produccion] --> HC[healthcheck responde ok]
HC --> OBS[logs metricas y trazas]
OBS --> SANO[todo sano la version sigue viva]
OBS --> MAL[error o latencia demasiado alta]
MAL --> RB[rollback a la version previa]
RB --> HC
style DEP fill:#89b4fa,color:#11111b
style RB fill:#f38ba8,color:#11111b