Hosting en VPS

Este hub enlaza las guías de VPS/hosting soportadas y explica a alto nivel cómo funcionan los despliegues en la nube.

Elige un proveedor

• Railway (un clic + configuración en navegador): Railway
• Northflank (un clic + configuración en navegador): Northflank
• Oracle Cloud (Always Free): Oracle — $0/mes (Always Free, ARM; la disponibilidad/registro puede ser caprichosa)
• Fly.io: Fly.io
• Hetzner (Docker): Hetzner
• GCP (Compute Engine): GCP
• exe.dev (VM + proxy HTTPS): exe.dev
• AWS (EC2/Lightsail/free tier): también funciona bien. Video guía: https://x.com/techfrenAJ/status/2014934471095812547

Cómo funcionan los despliegues en la nube

• El Gateway se ejecuta en el VPS y es dueño del estado + workspace.
• Te conectas desde tu portátil/teléfono vía la interfaz de control o Tailscale/SSH.
• Trata el VPS como la fuente de verdad y haz backup del estado + workspace.
• Configuración segura por defecto: mantén el Gateway en loopback y accede vía túnel SSH o Tailscale Serve. Si haces bind a lan/tailnet, requiere gateway.auth.token o gateway.auth.password.

Acceso remoto: Gateway remoto Hub de plataformas: Plataformas

Agente compartido de empresa en un VPS

Esta es una configuración válida cuando los usuarios están dentro de un mismo perímetro de confianza (por ejemplo, un equipo de empresa) y el agente es solo para uso profesional.

• Mantenlo en un runtime dedicado (VPS/VM/contenedor + usuario/cuentas de SO dedicados).
• No inicies sesión en ese runtime con cuentas personales de Apple/Google ni perfiles personales de navegador/gestor de contraseñas.
• Si los usuarios son adversarios entre sí, sepáralos por gateway/host/usuario de SO.

Detalles del modelo de seguridad: Seguridad

Usar nodos con un VPS

Puedes mantener el Gateway en la nube y emparejar nodos en tus dispositivos locales (Mac/iOS/Android/headless). Los nodos proporcionan pantalla local/cámara/canvas y capacidades de system.run mientras el Gateway permanece en la nube.

Documentación: Nodos, CLI de nodos

Ajustes de arranque para VMs pequeñas y hosts ARM

Si los comandos del CLI se sienten lentos en VMs de baja potencia (o hosts ARM), habilita la caché de compilación de módulos de Node:

grep -q 'NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'
export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
mkdir -p /var/tmp/openclaw-compile-cache
export OPENCLAW_NO_RESPAWN=1
EOF
source ~/.bashrc

• NODE_COMPILE_CACHE mejora los tiempos de arranque en ejecuciones repetidas.
• OPENCLAW_NO_RESPAWN=1 evita la sobrecarga adicional de arranque por una ruta de auto-respawn.
• La primera ejecución calienta la caché; las siguientes son más rápidas.
• Para detalles específicos de Raspberry Pi, consulta Raspberry Pi.

Checklist de ajustes de systemd (opcional)

Para hosts de VM que usan systemd, considera:

• Añadir variables de entorno del servicio para una ruta de arranque estable:
  • OPENCLAW_NO_RESPAWN=1
  • NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
• Mantener el comportamiento de reinicio explícito:
  • Restart=always
  • RestartSec=2
  • TimeoutStartSec=90
• Preferir discos con SSD para las rutas de estado/caché y reducir las penalizaciones de I/O aleatorio en arranques en frío.

Ejemplo:

sudo systemctl edit openclaw

[Service]
Environment=OPENCLAW_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
Restart=always
RestartSec=2
TimeoutStartSec=90

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