Cómo autoalojar OpenClaw en 2026: Gateway, canales y seguridad

Trata OpenClaw como un sistema pequeño, no como una imagen de Docker. El objetivo de cara al usuario para OpenClaw es claro: un Gateway de asistente de IA con más de 22 integraciones de canales; el despliegue solo es aceptable cuando puedes emparejar un canal de mensajería, enviar un mensaje entrante, aprobar al remitente, invocar una herramienta inofensiva y volver a conectar la Control UI después de reiniciar el Gateway.

Esta distinción permite detectar el fallo que los operadores encuentran después de las pruebas locales: el Gateway solo se enlaza a loopback o el proxy descarta las actualizaciones de WebSocket. También hace que el plan de backup y actualización sea lo bastante específico como para poder probarlo.

Elige la topología mínima viable de OpenClaw

La topología mínima responsable de OpenClaw contiene un listener privado en 18789, una ruta de ingress y un límite de estado documentado. El requisito externo de OpenClaw es una clave del proveedor del modelo y al menos un canal emparejado. Prueba el DNS saliente, TLS y el comportamiento del proveedor sin publicar otro servicio entrante.

Valida la topología pidiendo a un cliente limpio que empareje un canal de mensajería, envíe un mensaje entrante, apruebe al remitente, invoque una herramienta inofensiva y vuelva a conectar la Control UI después de reiniciar el Gateway. Mientras se ejecuta, observa las ejecuciones paralelas de agentes, la latencia del modelo, los procesos de herramientas de navegador y el tamaño del historial de sesión acumulado. El resultado te indica si la siguiente mejora debe aplicarse en la memoria, el almacenamiento, la red o un worker independiente, en lugar de fomentar un dimensionamiento arbitrario del contenedor.

Diagnostica un OpenClaw que parece estar sano

Un health check en estado idle dice muy poco sobre OpenClaw. Observa las ejecuciones paralelas de agentes, la latencia del modelo, los procesos de herramientas de navegador y el tamaño del historial de sesión acumulado; después, genera alertas sobre el síntoma que experimentan los usuarios: el fallo de la acción «emparejar un canal de mensajería, enviar un mensaje entrante, aprobar al remitente, invocar una herramienta inofensiva y volver a conectar la Control UI después de reiniciar el Gateway». Mantén el liveness local y barato; deja que el readiness informe de las migraciones o la inicialización sin provocar una tormenta de reinicios.

El área de riesgo de una actualización es que una release puede cambiar el schema de configuración del Gateway, las skills incluidas, las dependencias del navegador o los adaptadores de canales. Lee las release notes, crea un snapshot del estado, despliega la versión objetivo sobre una copia restaurada y repite la acción de aceptación. Si el Gateway solo se enlaza a loopback o el proxy descarta las actualizaciones de WebSocket, correlaciona la solicitud del cliente con el primer log relevante de la aplicación en lugar de eliminar el estado o añadir redirects a ciegas.

Cinco comprobaciones más sólidas que la salud del contenedor

El registro de releases de OpenClaw necesita datos concretos, no un «parece correcto». Guarda el digest de imagen seleccionado, el checksum de configuración, el hostname público y un resultado con timestamp para: emparejar un canal de mensajería, enviar un mensaje entrante, aprobar al remitente, invocar una herramienta inofensiva y volver a conectar la Control UI después de reiniciar el Gateway. Usa datos de ejemplo que no sean de producción para que la comprobación pueda ejecutarse después de cada despliegue.

Demuestra por separado dos eventos del ciclo de vida. La sustitución de un contenedor debe conservar el funcionamiento normal; una recuperación limpia debe demostrar que el Gateway restaurado puede volver a abrir su workspace, reconocer el canal emparejado y usar la autenticación del proveedor sin repetir el onboarding. Mientras se ejecutan las comprobaciones, mide las ejecuciones paralelas de agentes, la latencia del modelo, los procesos de herramientas de navegador y el tamaño del historial de sesión acumulado, y conserva el resultado como el intervalo esperado para esta versión.

Prueba también una condición denegada o no válida: deniega temporalmente la ruta de prueba utilizada por una clave del proveedor del modelo y al menos un canal emparejado. OpenClaw debe fallar de forma diagnosticable y no debe sobrescribir un estado saludable. Restablece la condición válida, vuelve a ejecutar el ejemplo y adjunta los logs relevantes con los datos sensibles ocultos. Estos artefactos proporcionan evidencias concretas para una futura decisión de rollback.

Ejecuta la primera instancia con forma de producción

Mantén la primera ejecución de OpenClaw lo bastante reproducible como para revisarla en un pull request.

docker run -d \
  --name openclaw \
  --restart unless-stopped \
  -p 127.0.0.1:18789:18789 \
  -v openclaw-data:/home/node/.openclaw \
  -e OPENCLAW_GATEWAY_TOKEN=replace-with-a-long-random-value \
  -e OPENCLAW_GATEWAY_BIND=lan \
  ghcr.io/openclaw/openclaw:latest node dist/index.js gateway --bind lan --port 18789

No dependas de latest cuando ya existan datos reales. Captura el digest que funciona, el usuario del contenedor y los permisos del mount. Sigue el log de la aplicación durante una prueba completa —emparejar un canal de mensajería, enviar un mensaje entrante, aprobar al remitente, invocar una herramienta inofensiva y volver a conectar la Control UI después de reiniciar el Gateway— y anota cualquier migración antes de poner la ruta detrás del tráfico de producción.

Haz medible la recuperación de OpenClaw

Una imagen de contenedor se puede volver a descargar; el workspace, el estado de los canales y la configuración de OpenClaw no. Monta /home/node/.openclaw antes del bootstrap, escribe datos de ejemplo inofensivos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Inspecciona el mount efectivo en lugar de confiar en un nombre de archivo de Compose y comprueba que el usuario de runtime puede escribir donde OpenClaw lo espera.

Elige la retención y un destino externo al host, y después ensaya la recuperación sin tocar producción. El simulacro solo se supera cuando el Gateway restaurado puede volver a abrir su workspace, reconocer el canal emparejado y usar la autenticación del proveedor sin repetir el onboarding. Para estados respaldados por una base de datos, combina los snapshots de almacenamiento con exports coherentes con la aplicación, como se describe en recuperación a un punto en el tiempo frente a snapshots.

Prueba OpenClaw desde fuera del servidor

Trata la URL externa de OpenClaw como una configuración que debe sobrevivir a los redeploys. Primero configura la dirección pública del Gateway y un proxy compatible con WebSocket; después, dirige el hostname al puerto 18789 conservando intactos el host y el scheme originales.

La checklist de reachability del despliegue puede demostrar que las solicitudes entran en el contenedor. A partir de ese punto, el fallo conocido —el Gateway solo se enlaza a loopback o el proxy descarta las actualizaciones de WebSocket— debe investigarse en OpenClaw, en su estado o en su workload, no en la automatización de certificados.

Reduce la autoridad que posee OpenClaw

Las credenciales de bootstrap son temporales; el modelo de confianza es permanente. Con OpenClaw, presta atención a que el token del Gateway no quede sin definir o a que se aprueben emparejamientos de canales desconocidos, y usa un límite de confianza por Gateway, revisa cada emparejamiento de DM y aplica sandboxing a las herramientas que acceden al host.

Trata OPENCLAW_GATEWAY_TOKEN según su función en OpenClaw: mantén los valores sensibles fuera de Git, documenta los efectos de la rotación y no sustituyas nunca un ejemplo público en producción. Ejecuta la imagen sin capabilities de Linux innecesarias y expón únicamente la ruta pública de la aplicación. Mantén visible la actividad de administración sin registrar valores secretos.

Integra OpenClaw en el ciclo de vida de Dockup

La capa de plataforma para OpenClaw está formada por el puerto 18789, el ingress, TLS, la configuración de runtime, el almacenamiento y la reachability de las dependencias. Dockup puede reproducir estas piezas para su propia infraestructura o para un servidor que conecte el cliente.

Después, el operador completa la capa de producto: configura la dirección pública del Gateway y un proxy compatible con WebSocket; aplica esta regla de acceso —usa un límite de confianza por Gateway, revisa cada emparejamiento de DM y aplica sandboxing a las herramientas que acceden al host—; y ejecuta «emparejar un canal de mensajería, enviar un mensaje entrante, aprobar al remitente, invocar una herramienta inofensiva y volver a conectar la Control UI después de reiniciar el Gateway». Registrar esta prueba junto al despliegue evita confundir el aprovisionamiento automatizado con la disponibilidad de la aplicación.

Preguntas frecuentes

¿Qué necesita OpenClaw para un despliegue de producción?

Dirige el contenedor de OpenClaw en el puerto 18789 a través de un único origen HTTPS. El requisito externo de entrega es una clave del proveedor del modelo y al menos un canal emparejado. No consideres que OpenClaw está listo hasta que puedas emparejar un canal de mensajería, enviar un mensaje entrante, aprobar al remitente, invocar una herramienta inofensiva y volver a conectar la Control UI después de reiniciar el Gateway.

¿Qué datos de OpenClaw deben incluirse en un backup?

Haz persistente /home/node/.openclaw e incluye el workspace, el estado de los canales y la configuración de OpenClaw en el mismo manifest de recuperación. Una restauración limpia de OpenClaw solo se supera cuando el Gateway restaurado puede volver a abrir su workspace, reconocer el canal emparejado y usar la autenticación del proveedor sin repetir el onboarding.

¿OpenClaw necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de OpenClaw y mantén el puerto 18789 en la ruta interna. Aplica correctamente la configuración de OpenClaw: configura la dirección pública del Gateway y un proxy compatible con WebSocket. En OpenClaw, HTTPS protege las credenciales o el contenido del usuario durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo debe probarse una actualización de OpenClaw?

Restaura el estado actual de OpenClaw en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque una release puede cambiar el schema de configuración del Gateway, las skills incluidas, las dependencias del navegador o los adaptadores de canales. Conserva la imagen anterior de OpenClaw hasta comprender los límites de migración de datos y rollback.