Hosting

Servidor Linux

Ejecuta el Gateway de OpenClaw en cualquier servidor Linux o VPS en la nube. Esta página ayuda a elegir un proveedor, explica cómo funcionan los despliegues en la nube y abarca ajustes genéricos de Linux aplicables en cualquier entorno.

Elegir un proveedor

Azure
DigitalOcean
exe.dev
Fly.io
GCP
Hetzner
Hostinger
Northflank
Oracle Cloud
Railway
Raspberry Pi

AWS (EC2 / Lightsail / nivel gratuito) también funciona bien. Hay disponible una guía en vídeo de la comunidad en x.com/techfrenAJ/status/2014934471095812547 (recurso de la comunidad; podría dejar de estar disponible).

Cómo funcionan las configuraciones en la nube

  • El Gateway se ejecuta en el VPS y gestiona el estado y el espacio de trabajo.
  • La conexión se realiza desde un portátil o teléfono mediante la interfaz de control o Tailscale/SSH.
  • Se debe tratar el VPS como la fuente de verdad y realizar copias de seguridad periódicas del estado y el espacio de trabajo.
  • Configuración segura predeterminada: mantener el Gateway en la interfaz de bucle invertido y acceder mediante un túnel SSH o Tailscale Serve. Si se vincula a lan o tailnet, el Gateway requiere un secreto compartido (gateway.auth.token o gateway.auth.password), salvo que la autenticación se delegue en un proxy de confianza.

Páginas relacionadas: Acceso remoto al Gateway, Centro de plataformas.

Proteger primero el acceso administrativo

Antes de instalar OpenClaw en un VPS público, se debe decidir cómo se administrará el propio servidor.

  • Para el acceso administrativo exclusivo desde la red Tailscale: instalar primero Tailscale, unir el VPS a la red Tailscale, verificar una segunda sesión SSH mediante la IP de Tailscale o el nombre de MagicDNS y, después, restringir el acceso SSH público.
  • Sin Tailscale: aplicar una protección equivalente a la ruta SSH antes de exponer más servicios.
  • Esto es independiente del acceso al Gateway. OpenClaw puede seguir vinculado a la interfaz de bucle invertido y se puede usar un túnel SSH o Tailscale Serve para el panel.

Las opciones del Gateway específicas de Tailscale se describen en Tailscale.

Agente empresarial compartido en un VPS

Ejecutar un único agente para un equipo es una configuración válida cuando todos los usuarios pertenecen al mismo límite de confianza y el agente se utiliza exclusivamente para fines empresariales.

  • Se debe mantener en un entorno de ejecución dedicado (VPS/máquina virtual/contenedor y usuario/cuentas del sistema operativo exclusivos).
  • No se deben iniciar sesiones en ese entorno de ejecución con cuentas personales de Apple/Google ni perfiles personales de navegador o gestor de contraseñas.
  • Si los usuarios pueden actuar de forma maliciosa entre sí, se deben separar por Gateway/host/usuario del sistema operativo.

Detalles del modelo de seguridad: Seguridad.

Uso de nodos con un VPS

Es posible mantener el Gateway en la nube y emparejar nodos en dispositivos locales (Mac/iOS/Android/sin interfaz). Los nodos proporcionan capacidades locales de pantalla/cámara/lienzo y system.run, mientras el Gateway permanece en la nube.

Documentación: Nodos, CLI de nodos.

Ajustes de inicio para máquinas virtuales pequeñas y hosts ARM

Si los comandos de la CLI parecen lentos en máquinas virtuales de baja potencia (o hosts ARM), se puede habilitar la caché de compilación de módulos de Node:

bash
grep -q 'NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cachemkdir -p /var/tmp/openclaw-compile-cacheexport OPENCLAW_NO_RESPAWN=1EOFsource ~/.bashrc
  • NODE_COMPILE_CACHE mejora los tiempos de inicio de los comandos repetidos; la primera ejecución prepara la caché.
  • OPENCLAW_NO_RESPAWN=1 mantiene los reinicios habituales del Gateway dentro del mismo proceso, lo que evita transferencias adicionales entre procesos y simplifica el seguimiento del PID en hosts pequeños.
  • Para obtener información específica sobre Raspberry Pi, consultar Raspberry Pi.

Lista de comprobación de ajustes de systemd (opcional)

Para hosts de máquinas virtuales que utilicen systemd, se recomienda considerar:

  • Variables de entorno del servicio para una ruta de inicio estable: OPENCLAW_NO_RESPAWN=1 y NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
  • Comportamiento de reinicio explícito: Restart=always, RestartSec=2, TimeoutStartSec=90
  • Discos respaldados por SSD para las rutas de estado y caché, a fin de reducir las penalizaciones de arranque en frío por operaciones de E/S aleatorias.

La ruta estándar openclaw onboard --install-daemon instala una unidad de usuario de systemd; se puede editar con:

bash
systemctl --user edit openclaw-gateway.service
ini
[Service]Environment=OPENCLAW_NO_RESPAWN=1Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cacheRestart=alwaysRestartSec=2TimeoutStartSec=90

Si se ha instalado deliberadamente una unidad del sistema, se debe editar mediante sudo systemctl edit openclaw-gateway.service.

Cómo ayudan las políticas de Restart= a la recuperación automatizada: systemd puede automatizar la recuperación de servicios.

Para obtener información sobre el comportamiento de OOM en Linux, la selección de procesos secundarios que se finalizarán y los diagnósticos de exit 137, consultar Presión de memoria y finalizaciones por OOM en Linux.

Contenido relacionado

Was this useful?
On this page

On this page