Así está hecha esta web

Publicado el 24 de octubre de 2026

Esta web también es un proyecto de software. No es una plantilla en un servicio de alojamiento: la compilo, la empaqueto y la sirvo yo, en un servidor propio, con las mismas piezas que uso para poner en marcha herramientas de cálculo. Este artículo cuenta cómo llega un cambio desde mi editor hasta tu navegador, y por qué cada pieza está ahí.

Del commit al navegador

1. GitHub. El código de la web y los artículos viven en un repositorio. Todo cambio es un commit, incluidos los que hace el panel de publicación (más abajo).
2. Astro. Compila las páginas y los artículos (MDX) a HTML estático. Lo interactivo, como el diagrama de arriba o los visores de las simulaciones, son islas de React o Three.js que se cargan solo cuando aparecen en pantalla.
3. Docker + Nginx. Una imagen en dos etapas: la primera compila la web con Node; la segunda se queda solo con los ficheros y los sirve con Nginx. La imagen final no lleva Node ni el código fuente.
4. Coolify. Escucha al repositorio: cuando entra un commit, construye la imagen y sustituye el contenedor. Es la pieza que me ahorra escribir el despliegue a mano.
5. Traefik. El proxy de entrada: lleva cada dominio a su contenedor y pide y renueva los certificados de Let’s Encrypt.
6. HTTPS. Lo que llega a tu navegador: HTML, CSS, imágenes y vídeos ligeros, y el JavaScript de las partes interactivas.

Dos entornos: pruebas y producción

Un despliegue tarda menos de un minuto, pero en ese minuto puede haber un enlace roto. Por eso hay dos ramas y dos aplicaciones:

• desarrollo se despliega en un dominio de pruebas. Es donde trabajo y donde reviso cada cambio en el móvil y en el escritorio antes de publicarlo. Esa versión no se indexa, no carga analítica y lleva una marca roja «STG» en la esquina para no confundirla con la real.
• main es la web pública. Solo llega aquí lo que ya he visto funcionar en pruebas.

La diferencia entre las dos no está en el código, sino en una variable al compilar. Así lo que pruebo es exactamente lo que publico.

Más que una web estática

El sitio es estático, pero a su lado corren dos servicios pequeños, en el mismo docker compose:

• Un panel de publicación. Publica, programa y retira artículos cambiando su cabecera con un commit en el repositorio. Un artículo programado sale solo a su hora, y el despliegue es el mismo que el de cualquier otro cambio.
• El chat de Grullu. La grulla de la esquina responde con un modelo de lenguaje que corre en mi propio ordenador, conectado al servidor por una red privada. Las preguntas no pasan por ningún servicio de terceros. Si el ordenador está apagado, la grulla se esconde.

Los borradores tienen su propia ruta, protegida con usuario y contraseña en Nginx. La configuración falla cerrada: si una imagen se construye sin contraseña, esa ruta responde «no encontrado» en lugar de quedar abierta.

Las simulaciones

Cada visor (el invernadero, la pila SOFC, el pastoreo…) es una aplicación aparte, compilada desde su propio repositorio de simulaciones e incrustada en el artículo. No se descarga nada hasta que el visor está a punto de aparecer en pantalla, y todo se calcula en tu navegador: el servidor solo entrega ficheros.

Los fondos animados de la portada se graban fotograma a fotograma desde esas mismas escenas, a una resolución fija y con la mitad izquierda despejada para que el titular se lea. Un script mide el contraste del texto sobre cada vídeo antes de publicarlo.

Lo que no hay

No hay base de datos, ni formularios, ni cuentas de usuario. Google Analytics solo se carga si lo aceptas en el aviso de cookies. Menos piezas significa menos cosas que mantener y menos datos de los que preocuparse.

Etiquetas: DevOps · Docker · Astro · despliegue