Cómo ejecutar OpenClaw de forma segura en un VPS

Qué es OpenClaw y por qué debe protegerlo primero

OpenClaw es un agente de IA autohospedado. Se ejecuta en su propio servidor, se conecta a un modelo de lenguaje de gran tamaño y puede ejecutar comandos de shell, controlar un navegador, leer y escribir sus archivos y actuar sobre los mensajes que le envía desde aplicaciones de chat. Ese alcance es el propósito principal de la herramienta y también constituye todo el riesgo. Un agente que puede ejecutar cualquier comando es tan seguro como el sistema donde se ejecuta y como los límites que se le apliquen.

Dos hechos marcan el enfoque de esta guía. En primer lugar, OpenClaw está diseñado para que usted lo proteja. Su modelo de seguridad deja en manos del operador la configuración de políticas estrictas para las herramientas, el uso de un entorno aislado y la asignación cuidadosa de permisos, en lugar de ofrecer valores predeterminados seguros. En segundo lugar, el proyecto ya ha sufrido un incidente de seguridad grave: en marzo de 2026 se divulgaron nueve problemas de seguridad en cuatro días, incluida una vulnerabilidad crítica de escalada de privilegios, CVE-2026-32922, con una puntuación de 9.9 sobre 10. Ninguno de estos hechos significa que deba evitar OpenClaw. Significan que no debe ejecutarlo de la forma más descuidada. Esta guía explica el enfoque cuidadoso. Parte de ese enfoque consiste en decidir de antemano qué puede hacer el agente sin pedir confirmación. Es una decisión que Claude Code hace explícita mediante sus modos de permisos, y un servidor que no está supervisando directamente requiere una configuración más restrictiva que el portátil que está observando.

También hay una buena noticia. OpenClaw ya toma una decisión segura por usted: su gateway, el único proceso que controla todo, escucha de forma predeterminada en la dirección de loopback. Por tanto, no es accesible desde Internet a menos que usted lo exponga de forma deliberada. La mayor parte del trabajo que se describe a continuación consiste en mantener esa configuración y limitar el impacto si algo sale mal.

Dale a OpenClaw su propio usuario sin privilegios

Nunca ejecutes un agente como root. Si OpenClaw se ejecuta como root y ocurre algún problema, ya sea un error, una instrucción incorrecta o una CVE como la anterior, el daño no tiene límite. Crea un usuario de sistema dedicado, sin shell de inicio de sesión y sin sudo, y ejecuta el agente con ese usuario:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

Todo lo que pertenece a OpenClaw se encuentra en /opt/openclaw y pertenece a esa cuenta. Este es el paso más importante. Es el mismo principio descrito en ejecutar servicios con un usuario sin privilegios: la cuenta con la que se ejecuta un agente determina el límite de lo que puede dañar.

Instalar OpenClaw

OpenClaw se distribuye como un paquete npm, así que instale primero Node.js si el servidor no lo tiene. Instale el paquete de forma global. Esto coloca el binario openclaw en el PATH de todos los usuarios. Después, ejecute el proceso de incorporación inicial:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

Si ejecuta la incorporación como el usuario openclaw, la configuración del agente se guarda en su directorio de inicio, /opt/openclaw, y no en el de root. El proyecto también ofrece un instalador curl -fsSL https://openclaw.ai/install.sh | bash que realiza la misma instalación con una sola línea. Omita la opción --install-daemon durante la incorporación. Esa opción registraría el servicio propio de OpenClaw, y la unidad de systemd reforzada que se crea más adelante es más estricta.

Mantenga el gateway en loopback, detrás de un firewall

El gateway se enlaza a 127.0.0.1 de forma predeterminada. Déjelo ahí. Casi nunca hay una razón para publicar ese puerto en Internet. Hacerlo proporciona a cualquiera que lo encuentre un punto de acceso remoto a un proceso que ejecuta comandos.

Coloque un firewall con denegación predeterminada delante del equipo para que nada quede expuesto por accidente:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Aquí debe evitar dos errores. Un firewall que sólo cubre IPv4 puede dejar el mismo servicio completamente expuesto en IPv6. Esa es precisamente la brecha del firewall de IPv6 que afecta a tantos administradores. Si necesita acceder al gateway desde su portátil, no abra el puerto. Acceda mediante una VPN o un túnel SSH para que el agente nunca escuche desde Internet abierta.

Aísle sus secretos

OpenClaw necesita una clave de API para el modelo de lenguaje que conecte. Esa clave puede gastar su dinero y, a través del agente, actuar en su nombre, así que debe tratarla como una contraseña. Manténgala fuera del archivo de unidad y de cualquier repositorio. Guárdela en un archivo que sólo pueda leer el usuario de OpenClaw:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

La unidad de systemd carga ese archivo con EnvironmentFile, por lo que la clave llega al proceso sin aparecer en una línea de comandos, un registro ni el historial de su shell. Este patrón se aplica a todos los secretos del servidor: una revisión de seguridad de Vaultwarden autohospedado se centra en su token de administración y su archivo de copia de seguridad, no en su cifrado, porque los permisos de archivo son los que realmente determinan quién puede leer un secreto almacenado.

Ejecutarlo como un servicio de systemd reforzado

Ejecutar el agente con systemd permite reinicios automáticos, registros centralizados mediante journalctl y, sobre todo, un conjunto de opciones de aislamiento del kernel que reducen los recursos que el proceso puede tocar incluso si el servidor está comprometido. Las opciones más importantes para un agente son NoNewPrivileges, para que nunca pueda obtener privilegios adicionales; ProtectSystem=strict, para que el sistema de archivos sea de solo lectura salvo en las ubicaciones donde permita escrituras; PrivateTmp, para proporcionarle un directorio temporal aislado; y ProtectHome, para impedirle leer los directorios personales.

Genere aquí una unidad completa y reforzada. Después, cópiela en /etc/systemd/system/openclaw.service:

La unidad inicia openclaw gateway, el proceso de larga duración que controla el agente. Si which openclaw muestra una ruta diferente en su servidor, ajuste ExecStart para que coincida. La explicación completa de estas directivas, así como de daemon-reload y enable --now, está en ejecutar un programa como servicio de systemd. Después de pegar la unidad, los pasos básicos son:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

Refuerce también la puerta de entrada

La seguridad de un equipo con un agente depende de la seguridad del servidor que lo aloja. Para completar la protección, añada dos capas más. Cambie SSH para usar únicamente autenticación mediante claves y desactive el acceso de root, como se explica en Refuerzo de SSH en un VPS. Así evita que puedan realizar ataques de fuerza bruta contra la cuenta que utiliza para administrar el equipo. Después, añada Fail2ban para bloquear los escáneres que atacan todos los puertos públicos. Ninguna de estas medidas modifica OpenClaw directamente, pero ambas cierran las rutas que usaría un atacante para llegar hasta él.

Manténgalo actualizado de forma deliberada

Las divulgaciones de marzo de 2026 son el argumento más claro para mantener el software actualizado. Un error de escalada de privilegios en un agente es mucho más grave que en una aplicación web común, porque el agente ya ejecuta comandos. Supervise las versiones del proyecto, aplique rápidamente las actualizaciones de seguridad y trate una actualización de OpenClaw como mantenimiento rutinario, no como una tarea que pueda posponer.

Para entender qué está reforzando exactamente, la arquitectura de un agente de estilo OpenClaw explica sus componentes, y crear su propio agente de IA en un VPS describe la estructura general de cualquier agente. Si termina ejecutando un segundo agente junto al primero, recuerde que dos sesiones de Claude Code en un VPS pueden pasarse trabajo entre sí, por lo que cada una necesita su propia cuenta y sus propios límites, en lugar de heredar los suyos.

FAQ

¿Es seguro ejecutar OpenClaw en un VPS público?

Puede serlo si lo refuerza. OpenClaw es potente por diseño: ejecuta comandos de shell y controla un navegador. Por eso, una configuración descuidada es realmente peligrosa. Además, el proyecto ya ha tenido una CVE crítica (CVE-2026-32922 en marzo de 2026). Su modelo de seguridad presupone que el operador debe añadir las restricciones. Ejecútelo con un usuario sin privilegios, mantenga su gateway en loopback detrás de un firewall con denegación predeterminada, aísle sus claves de API y ejecútelo como un servicio systemd reforzado.

¿Debo exponer el gateway de OpenClaw a Internet?

No. El gateway se enlaza a loopback de forma predeterminada y debe dejarlo así. Es el único proceso que controla el agente, por lo que un gateway expuesto proporciona acceso remoto a un proceso que ejecuta comandos como función principal. Si necesita acceder a él de forma remota, use una VPN o un túnel SSH en lugar de abrir el puerto.

¿Con qué usuario debe ejecutarse OpenClaw?

Con un usuario de sistema dedicado, sin shell de inicio de sesión y sin sudo; nunca con root. Si el agente se ve comprometido, su cuenta de usuario limita el alcance de los daños. Por tanto, esa cuenta sólo debe ser propietaria de sus propios archivos en un directorio como /opt/openclaw y de ningún otro recurso.

¿Cómo mantengo seguras las claves de API de OpenClaw?

Guárdelas en un archivo que sólo pueda leer el usuario de OpenClaw (modo 600) y cárguelo en el servicio mediante EnvironmentFile de systemd. Mantenga la clave fuera del archivo de unidad, del historial del shell y de cualquier repositorio git. Rótela si alguna vez sospecha que se ha filtrado.