Saltar a contenido

Multi-App VPS Governance

Objetivo

Definir reglas permanentes para convivir OpenClaw con otras aplicaciones Docker en el mismo VPS sin mezclar redes, volumenes, secretos ni responsabilidades operativas.

Decision vigente

  • La convivencia multi-app en el mismo VPS queda aprobada.
  • La aprobacion aplica a nivel conceptual y operativo futuro, no como permiso de despliegue inmediato.
  • Primero debe cerrarse la etapa VPS baseline hardening + preparacion operativa.

Regla base

  • Cada app es un stack independiente.

Estructura recomendada

  • /opt/stacks/shared
  • /opt/stacks/backups
  • /opt/stacks/apps
  • /opt/stacks/openclaw

Reglas de carpetas

  • Cada app debe tener su propia carpeta.
  • Cada app debe tener su propio docker-compose.yml.
  • Cada app debe tener su propio .env no versionado.
  • Cada app debe tener su propia carpeta de backup o plan de backup equivalente.
  • Ninguna app nueva debe escribir dentro de la carpeta de OpenClaw.

Reglas de redes

  • Cada app debe tener una red interna dedicada.
  • La unica red potencialmente compartida entre apps publicadas debe ser la red de proxy.
  • OpenClaw usara openclaw_internal como red privada.
  • Ninguna app nueva debe reutilizar el nombre openclaw_internal.
  • Si una app no necesita publicacion externa, no debe conectarse a la red proxy.

Reglas de puertos

  • Solo nginx-proxy-manager debe publicar 80/443.
  • Toda nueva app debe quedar detras de NPM salvo necesidad operativa aprobada.
  • Toda excepcion de puertos publicados debe documentarse antes de implementar.
  • Cada app publicada debe tener subdominio propio.
  • OpenClaw no debe tener puertos directos al host en su fase inicial.

Reglas de persistencia

  • OpenClaw no debe compartir volumenes ni bind mounts con otras apps.
  • Ninguna app nueva debe reutilizar nombres de volumen de OpenClaw.
  • Los secretos no deben guardarse en rutas compartidas.
  • Los backups que salgan del host no deben incluir secretos reales.

Reglas de seguridad

  • No montar docker.sock por defecto.
  • Montar docker.sock implica riesgo de control sobre el daemon Docker y potencial impacto lateral sobre otros stacks del mismo host.
  • No habilitar capacidades peligrosas inicialmente.
  • No instalar binarios dentro de contenedores en runtime.
  • Si una app necesita binarios extra, debe usar imagen propia o build controlado.
  • Toda skill, plugin o integracion de OpenClaw debe revisarse antes de habilitarse.
  • Toda app publica debe usar TLS.

Reglas de documentacion

  • Ninguna app nueva se instala sin documento de arquitectura.
  • Ninguna app nueva se instala sin runbook.
  • Ninguna app nueva se instala sin plan de backup y rollback.
  • Toda decision que afecte NPM, redes, volumenes o secretos debe quedar documentada antes de ejecutar.
  • Toda app nueva debe declarar si requiere swap, reinicio, puertos extra o acceso de alto privilegio.

Reglas de operacion

  • Tomar safe point antes de cambios relevantes.
  • Registrar el compose final aprobado por cada app.
  • Registrar la ubicacion real de persistencia de cada app.
  • Registrar el subdominio de cada app publicada.
  • Registrar si la app depende de recursos externos o de imagen derivada.
  • Planificar rollback y ventana segura de reinicio cuando el cambio pueda afectar mas de un stack.

Regla especifica para OpenClaw

  • OpenClaw debe desplegarse como stack aislado.
  • OpenClaw debe salir por subdominio dedicado.
  • OpenClaw debe usar proveedores LLM externos al inicio.
  • OpenClaw no debe arrancar con modelos locales pesados en este VPS.
  • OpenClaw no debe habilitar sandbox con docker.sock sin aprobacion explicita.
  • OpenClaw debe empezar con el perfil mas conservador posible.