Saltar al contenidoCECO LabDigital lab / web engineering
CAESEN
Solicitar propuesta
NRS Home Server

Guía / Self-hosting web

Cómo publicar webs estáticas y apps Node con Caddy y GitHub

Autoalojar una web no consiste solo en copiar archivos a un PC. Hay cuatro piezas distintas: el build que produce el contenido, el proceso que lo sirve localmente, la frontera pública HTTPS y el mecanismo que sustituye una revisión por otra. Separar esas piezas hace más fácil diagnosticar fallos y evita exponer servicios internos que no deberían ser públicos.

Autoría editorial · CECO LabActualizado · 02/10/2026Caddy · Node · GitHub

01 / Arquitectura

Primero separa las cuatro responsabilidades

01

Build

Una web estática puede generar HTML/CSS/JS en una carpeta de salida; una app Node necesita código, dependencias y un entrypoint que permanece en ejecución.

02

Servicio local

Los archivos estáticos necesitan un file server. Una app Node debe escuchar en una dirección y puerto controlados, preferiblemente loopback si Caddy será la única entrada pública.

03

Frontera pública

Caddy recibe el dominio, termina HTTPS y decide si sirve archivos o envía la petición al proceso Node. El panel de administración no debería compartir esa superficie por defecto.

04

Actualización

GitHub puede ser la fuente del código y un runner self-hosted puede ejecutar build, pruebas y despliegue, pero actualizar una revisión es distinto de mantener vivo el servicio.

02 / Caddy

Caddy: archivos estáticos y reverse proxy son dos casos distintos

Para una web estática, Caddy puede servir directamente una raíz de archivos con file_server. Para Node, el patrón habitual es dejar la aplicación en un puerto local y colocar Caddy delante con reverse_proxy. Cuando la configuración usa un dominio público y DNS/puertos están preparados, Caddy puede gestionar HTTPS automáticamente.

  • En estático, publica solo la carpeta de salida del build; no expongas el repositorio, .git, archivos .env ni directorios de trabajo.
  • En Node, escucha en loopback cuando solo Caddy deba hablar con la aplicación. No hace falta abrir el puerto interno en el router.
  • El dominio público debe apuntar a la IP correcta y TCP 80/443 debe llegar a Caddy si quieres certificados públicos automáticos.
  • Valida la configuración antes de recargarla y comprueba el dominio real después del cambio.
  • Un 200 del backend local y un 200 del dominio público son pruebas diferentes: necesitas ambas.
Caddy Docs: HTTPSCaddy Docs: file_serverCaddy Docs: reverse proxyGitHub Docs: self-hosted runnersGitHub Docs: uso seguro de GitHub Actions

03 / GitHub

GitHub es la fuente de revisión, no el supervisor del proceso

Un workflow con runner self-hosted puede hacer checkout, instalar dependencias, ejecutar tests, generar un build y preparar una revisión nueva en el propio servidor. Eso no convierte GitHub Actions en un gestor de procesos. El servicio estático o Node necesita su propio mecanismo de ejecución, reinicio o sustitución controlada, y el despliegue debe saber qué revisión queda activa.

Flujo que conviene poder auditar

  • Commit o SHA que se quiere desplegar y rama de origen.
  • Resultado de build y pruebas antes de tocar el servicio activo.
  • Directorio o revisión preparada fuera de la publicación actual.
  • Cambio atómico o paso explícito de activación y reinicio del proceso Node.
  • Smoke local y después smoke HTTPS del dominio público.
  • Revisión anterior disponible para rollback si el cambio falla.

04 / Caso real

Caso real: NRS Home Server

NRS Home Server aplica esta separación en Windows. Los despliegues conservan procedencia GitHub e historial; StaticHost y AppHost mantienen servicios independientes del panel; y la publicación Caddy es opt-in por dominio. Caddy sigue siendo externo: NRS Home Server no lo instala ni modifica DNS, router, firewall o certificados del sistema.

  • Las webs estáticas se registran y se sirven mediante un StaticHost independiente; las apps Node usan puertos loopback reservados.
  • La publicación de un dominio solo apunta a servicios registrados. El panel, Drive, backups y administración de Minecraft no se convierten en targets públicos.
  • Antes de recargar Caddy, la configuración generada se valida. Un gateway preparado no se presenta como alcanzable desde Internet si DNS o la red externa no se han comprobado.
  • Los proyectos GitHub conservan revisión desplegada, comprobación manual de frescura y una revisión anterior compatible para recuperación.
  • El modelo ligero de persistencia arranca después de iniciar sesión en Windows; no equivale a hosting 24/7 antes del login.
Ver la ficha de NRS Home Server

05 / Checklist

Checklist de publicación

  1. 01

    Decide si el proyecto es estático o necesita un proceso Node persistente.

  2. 02

    Mantén la app Node en loopback y publica solo Caddy hacia Internet.

  3. 03

    Comprueba DNS, puertos 80/443 y firewall antes de esperar HTTPS público.

  4. 04

    Ejecuta build y QA sobre la revisión exacta que quieres desplegar.

  5. 05

    Prepara el cambio fuera del servicio activo y conserva una vía de rollback.

  6. 06

    Verifica primero el servicio local y después el dominio HTTPS real.

  7. 07

    No permitas que un workflow no fiable ejecute código con permisos del servidor.

06 / Límites

Lo que esta arquitectura no resuelve sola

Caddy no sustituye backups, monitorización, gestión de procesos, actualizaciones del sistema ni una política de seguridad. Un runner self-hosted tampoco es una caja de arena: ejecuta workflows dentro de una máquina que controlas y puede conservar estado entre jobs. Si el servidor es crítico, necesita más disciplina operativa que un PC doméstico encendido de forma puntual.