En un portátil, OpenClaw se calla en cuanto bajas la tapa: los mensajes de WhatsApp se acumulan y las tareas programadas esperan a que vuelvas. En un servidor sigue respondiendo. El problema es que la pasarela no es un widget de chat. Guarda las credenciales de tus canales y, si no activas una sandbox, ejecuta herramientas directamente en el host. Llevarla a una máquina siempre encendida solo vale la pena si el modelo de seguridad se muda con ella.
Esta guía lo hace en unos 20 minutos sobre un VPS recién creado con Ubuntu 24.04.
Última verificación el 2026-10-04 con OpenClaw 2026.9.8 (npm), Node 24.21 LTS y Ubuntu 24.04.
Qué necesitas
- Un VPS Linux. Nosotros usamos nuestro plan AI-Agent: 4 vCPU, 4 GB de RAM, 40 GB de disco, 10 $ al mes. La documentación de OpenClaw menciona 6 GB de RAM, pero es para construir su imagen Docker desde el código fuente; el paquete npm no necesita compilación.
- Una clave API de tu proveedor de modelos y las cuentas de mensajería que quieras conectar.
- Una clave SSH en tu portátil. Si aún no la tienes: acceso con clave SSH.
Un plan con NAT encaja aquí, y probablemente mejor. La pasarela nunca necesita un puerto de entrada abierto: WhatsApp, Discord y Telegram (long polling por defecto) se conectan hacia fuera, y al panel llegas por SSH. Contrata una IPv4 dedicada solo si un canal que necesitas entrega por webhook o piensas poner un proxy inverso público delante.
1. Un usuario que no sea root
OpenClaw ejecuta las herramientas como el usuario dueño de la pasarela. Si ese usuario es root, también lo es cada comando que decida lanzar un modelo confundido o manipulado por inyección de prompt. La documentación de OpenClaw califica ejecutar la pasarela como root de inseguro y no soportado. Crea un usuario dedicado sin sudo:
# como root
apt update && apt -y upgrade
adduser --disabled-password --gecos "" claw
install -d -m 700 -o claw -g claw /home/claw/.ssh
install -m 600 -o claw -g claw ~/.ssh/authorized_keys /home/claw/.ssh/authorized_keys # la clave que añadiste al hacer el pedido
loginctl enable-linger claw
La última línea importa más de lo que parece. OpenClaw instala un servicio systemd de usuario, y sin lingering ese servicio se detiene al cerrar la sesión. Es el «ayer funcionaba» más habitual en servidores.
2. Node 24 y OpenClaw
OpenClaw 2026.9.8 requiere Node >=24.16.0 <25 o >=26.1.0. El paquete nodejs de Ubuntu es más antiguo, así que tomamos la 24 LTS de NodeSource:
# como root
curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
node -v # v24.16.0 o posterior
npm install -g openclaw@latest
openclaw --version
El comando oficial de una línea (curl -fsSL https://openclaw.ai/install.sh | bash) también funciona e instala Node por ti. En un servidor preferimos los dos pasos explícitos: ves qué va a dónde, y el binario queda en /usr/bin en vez de en un directorio personal donde el agente puede escribir.
3. Onboarding como el usuario del agente
Entra como claw por SSH, no con su. Solo un inicio de sesión real arranca el gestor de usuario de systemd que necesita el servicio:
# desde tu portátil (plan NAT: añade -p <tu puerto SSH>)
ssh claw@<server>
openclaw onboard --install-daemon
openclaw gateway status
El asistente comprueba el acceso al modelo, escribe ~/.openclaw/openclaw.json, genera un token de pasarela e instala el servicio. Si systemctl --user se queja del bus, ejecuta export XDG_RUNTIME_DIR=/run/user/$(id -u) y vuelve a intentarlo.
Después, cierra los archivos. La recomendación del propio OpenClaw es 700 en el directorio de estado y 600 en la configuración:
chmod 700 ~/.openclaw && chmod 600 ~/.openclaw/openclaw.json
openclaw security audit --deep
openclaw security audit --fix aplica la parte segura de las correcciones: permisos más estrictos y listas de permitidos en lugar de políticas de grupo abiertas. No cambia la interfaz de escucha ni configura ningún firewall; la exposición de red sigue siendo cosa tuya.
4. Mantén la pasarela en loopback
La pasarela sirve su API WebSocket y el panel en un único puerto, 18789, ligado a 127.0.0.1 por defecto. Déjalo así. Una configuración mínima que lo deja por escrito:
// ~/.openclaw/openclaw.json
{
gateway: {
mode: "local",
bind: "loopback",
port: 18789,
auth: { mode: "token", token: "paste-output-of-openssl-rand-hex-32" },
},
}
Genera el token con openssl rand -hex 32 o openclaw doctor --generate-gateway-token. La pasarela rechaza tokens vacíos y los valores de ejemplo, y la auditoría avisa por debajo de 24 caracteres.
Lo que no debes hacer: poner bind en "lan" y abrir el puerto. La documentación es tajante: nunca expongas la pasarela sin autenticación en 0.0.0.0 y no redirijas el puerto de forma amplia ni siquiera con token. Quien consiga ese token pasa a ser operador de un proceso que puede ejecutar comandos en tu servidor.
En el firewall, permite SSH y nada más:
# como root
ufw allow OpenSSH
ufw enable
ufw status verbose
En nuestros planes NAT el panel muestra un puerto SSH externo, pero dentro del servidor sshd sigue escuchando en el 22. Permite OpenSSH (puerto 22), no el número de puerto externo, o ufw enable te dejará fuera. Más en la guía de UFW.
5. Accede al panel por SSH
Desde tu portátil, abre un túnel y déjalo abierto:
ssh -N -L 18789:127.0.0.1:18789 claw@<server>
# plan NAT: ssh -N -p <tu puerto SSH> -L 18789:127.0.0.1:18789 claw@<host>
Abre http://127.0.0.1:18789/ y pega el token de la pasarela. El sshd por defecto de Ubuntu permite la redirección local; si lo endureciste, AllowTcpForwarding local es el ajuste que permite -L y bloquea las redirecciones remotas. Si el túnel falla con administratively prohibited, revisa esa línea.
Un tailnet también sirve: Tailscale Serve mantiene la pasarela en loopback y gestiona el acceso. Ambas opciones valen. Un puerto público, no.
6. Emparejamiento, sandbox y quién puede hablarle
Los canales de chat son la otra puerta. Por defecto, los canales con mensajes directos obligan a los remitentes desconocidos a emparejarse primero; tú apruebas desde el servidor:
openclaw pairing approve <channel> <code>
En grupos, exige una mención para que el agente no responda a cada mensaje de la sala. La configuración endurecida de OpenClaw usa dmPolicy: "pairing" y groups: { "*": { requireMention: true } } por canal.
Dos advertencias honestas. Primera: el emparejamiento controla quién puede iniciar un turno, no lo que acaba en el contexto del modelo; un mensaje reenviado o una página web descargada todavía pueden dirigir un turno que iniciaste tú. Segunda: las herramientas de la sesión principal se ejecutan en el host hasta que actives la sandbox (agents.defaults.sandbox.mode: "non-main" aísla todo salvo tu propia sesión principal). La sandbox viene desactivada y su backend por defecto es Docker, así que instala Docker antes de activarla: Docker en un VPS. Si comparten canal con el bot personas en las que no confías, usa una pasarela aparte, idealmente en otro servidor.
7. Actualizaciones y copias de seguridad
openclaw update
openclaw gateway status
openclaw backup create --output ~/backups/openclaw --verify
~/.openclaw guarda la configuración, las credenciales de los canales (sesión de WhatsApp incluida), los perfiles de autenticación de los modelos y las transcripciones de las sesiones. Perderlo significa volver a emparejarlo todo; filtrarlo significa que otra persona es tú en WhatsApp. Haz copias y guárdalas fuera del servidor: descárgalas con scp o usa restic con cifrado.
Lista de comprobación
| Comprobación | Comando | Esperado |
|---|---|---|
| La pasarela no corre como root | ps -eo user,args | grep '[o]penclaw' | claw en la primera columna |
| Sobrevive al cierre de sesión | loginctl show-user claw -p Linger | Linger=yes |
| Escucha solo en loopback | ss -ltnp | grep 18789 | 127.0.0.1:18789 |
| Sin puerto público | ufw status | solo OpenSSH |
| Configuración no legible por todos | stat -c '%a' ~/.openclaw/openclaw.json | 600 |
| Auditoría limpia | openclaw security audit --deep | sin hallazgos críticos |
Dónde encaja EQVPS
Muchos proveedores pueden ejecutar un proceso de Node. Lo que añadimos es pago en cripto sin KYC, un plan NAT que encaja con una pasarela solo en loopback y un servidor MCP que tu agente puede usar para gestionar sus propios servidores. Si conectas OpenClaw a él, lee primero las salvaguardas MCP: un token capaz de pedir servidores merece el mismo cuidado que el token de la pasarela. Para una visión más amplia de agentes en un VPS, consulta la guía de agentes de IA.
Nuestra opinión: estos 20 minutos marcan la diferencia entre un asistente y una shell abierta con interfaz de chat. Haz al menos los pasos 1, 4 y 5 aunque te saltes el resto.
Comentarios
Aún no hay comentarios. Sé el primero.