Kilometer 0 Digital (KM0) es el proyecto que documenta una infraestructura pensada para trabajo colaborativo, archivo del proyecto y presencia pública controlada: un servidor propio sobre Debian, una instancia OpenCloud como espacio de ficheros y equipos, y un sitio web estático multidioma (Astro) como carta de presentación del proyecto.

Esta serie de entradas recoge la puesta en marcha desde cero: primero la base del sistema y la ergonomía del entorno de administración; después el stack de contenedores, el frontal Nginx con TLS, el endurecimiento perimetral y la web de comunicación.

Qué encontrarás en estas entradas

  • Día 0: plan técnico del arranque, preparación del VPS (discos y particiones), instalación de herramientas base, configuración del shell siguiendo una guía interna reproducible y la instalación del agente remoto para automatizar cambios.
  • Día 5: reunión de visión en Masnou (IA, soberanía digital, cloud KM0, soporte humano, prensa local y documental) — 2026-05-29.
  • Día 4: login local Dex vía LDAP contra IDM OpenCloud, certificado LDAPS con SAN opencloud, cierre GitHub #1 y autoagents 1.0.18 (2026-05-27).
  • Día 3: repos Git km0-opencloud y km0-web, migración a km0digital.com / cloud.km0digital.com, bucle autoagents, FAQ, navegación móvil y versión web 1.1.4 (2026-05-26/27).
  • Día 2: actualización OpenCloud 7.x, OIDC con Dex (Google/Apple), integración Nginx /dex/, backup integral de instalación y documentación operativa (2026-05-22).
  • Día 1: despliegue de OpenCloud con Docker Compose y overlays oficiales, publicación sólo en loopback detrás del proxy, política de firewall, Fail2ban, directorios en el host para código de despliegue y docs operativas, y la web KM0 detrás del mismo Nginx.
  • A nivel conceptual: mapa de puertos y listeners, razón de cada decisión de proxy (SSE, TUS, WebSockets), dónde viven los datos persistentes en volúmenes Docker y cómo encajan marketing (km0digital.com) y el cloud (cloud.km0digital.com) sin compartir servicios dentro del mismo virtual host.

Panorama de la arquitectura

Browser
   │  HTTPS :443  (terminación TLS en el host — certificado de prueba o Let's Encrypt en producción)
   ▼
Nginx en Debian (sites-available del proyecto)
   │  proxy HTTP sólo hacia servicios que escuchan en 127.0.0.1
   ├──► OpenCloud (Docker) — puerto publicado sólo en loopback del host
   └──► km0-web (Docker, Astro estático servido por nginx Alpine) — también en loopback
▼
Volúmenes Docker en el host (datos OpenCloud y artefactos de build gestionados aparte)

La idea central es que Internet sólo habla TLS con Nginx. Los backends no exponen interfaces en 0.0.0.0 hacia fuera; escuchan en localhost y el proxy se encarga de cabeceras (X-Forwarded-Proto), tiempos de espera largos para sincronización/subidas y desactivar buffering donde el protocolo lo exige.

Dominios y responsabilidades

  • km0digital.com: web de comunicación del proyecto (ES por defecto en raíz, rutas /ca/ y /en/). Sirve HTML estático generado por Astro con Tailwind; SEO con sitemap y alternativas hreflang.
  • cloud.km0digital.com: espacio OpenCloud para ficheros y colaboración. Convive en la misma máquina física pero con virtual host independiente y cadena de proxy dedicada.

Separar hostnames permite políticas TLS independientes (certificados SAN distintos), registro DNS claro para usuarios finales y aislamiento conceptual entre la vitrina pública y el sistema productivo.

Seguridad en capas (sin entrar en secretos)

  • UFW en el host limitando lo que llega desde Internet típicamente a administración remota y servicios web públicos.
  • Bindings en loopback para los servicios de aplicación tras Docker; el puerto que habla con OpenCloud no queda abierto al mundo.
  • TLS del lado cliente entre navegador y Nginx; entre Nginx y OpenCloud el tráfico es HTTP local — patrón habitual y seguro porque no abandona la interfaz loopback.
  • Fail2ban añadido después del primer endurecimiento para reaccionar ante patrones repetidos de intentos contra servicios expuestos.
  • Higiene operativa: ficheros .env con permisos restrictivos (chmod 600), configuración sensible fuera del control de versiones y revisión del acceso inicial de administración desde la interfaz tras el primer uso.

Los valores sensibles del despliegue no forman parte de esta serie y deben vivir sólo en la documentación operativa privada del proyecto.