Si estás intentando ejecutar OpenClaw por primera vez, lo que normalmente te frena no es el comando de instalación. Es elegir el camino equivocado antes incluso de empezar.

La mayoría cae en el mismo bucle. Ves instalación desde código fuente, Docker, onboarding por CLI, instalación local, despliegue en la nube y, de repente, una pregunta sencilla se convierte en un pequeño proyecto de investigación. ¿Debe ir en mi portátil o en un servidor? ¿La instalación desde source es la forma “correcta”? ¿Docker es automáticamente más fácil? Si solo quiero que funcione hoy, ¿qué camino resulta realmente menos molesto?

Después de volver a revisar el README de OpenClaw y la documentación oficial de Docker, la respuesta parece bastante menos dramática de lo que sugieren los resultados de búsqueda. No es realmente una cuestión de qué comandos son mejores. Es sobre todo una cuestión de si quieres usar OpenClaw ahora mismo o si quieres asumir desde el primer día la responsabilidad sobre su runtime y su proceso de build.

Primero decide: ¿quieres usarlo o hacerte cargo de él?

Si eres un usuario normal y el objetivo es simplemente poner OpenClaw en marcha en tu propia máquina, no empezaría por la instalación desde código fuente. El README ya muestra el camino pensado para usuarios: ejecuta un entorno Node reciente, actualmente Node 24 o al menos Node 22.16+, instala la CLI y comienza el onboarding:

npm install -g openclaw@latest
openclaw onboard --install-daemon

Ese flujo se siente exactamente como lo que pretende ser: el punto de entrada para el usuario. Instalas la CLI, dejas que el onboarding te guíe por la configuración inicial y averiguas si el producto realmente te resulta útil.

La ruta desde source tiene una forma muy distinta:

git clone https://github.com/openclaw/openclaw.git
cd openclaw

pnpm install
pnpm ui:build
pnpm build

pnpm openclaw onboard --install-daemon
pnpm gateway:watch

Eso no es simplemente otro método de instalación. Se parece mucho más a asumir un entorno de desarrollo. Estás clonando el repositorio, construyendo la UI, compilando el proyecto y colocándote en una situación en la que los futuros problemas de build también pasan a formar parte de tu vida. Es estupendo si quieres control. No tanto si solo quieres tener OpenClaw funcionando antes de cenar.

Creo que aquí es donde mucha gente se complica. La instalación desde source suena más seria, así que puede parecer la opción “correcta”. Pero para la mayoría de usuarios que empiezan es, sobre todo, la opción más pesada. Heredas preocupaciones sobre la versión de Node, instalación de dependencias, pasos de build, compilación de UI y fricción en futuras actualizaciones antes incluso de decidir si quieres seguir usando la herramienta.

Docker no es automáticamente más ligero: portátil frente a servidor

Docker genera una confusión parecida. La gente oye “Docker” y supone que eso significa más fácil. A veces sí. Otras veces, no. La documentación Docker de OpenClaw es bastante honesta: Docker es opcional. Tiene sentido cuando quieres un gateway contenerizado, un entorno aislado o un camino de despliegue en un host que conviene tratar más como infraestructura que como tu ordenador diario. Si estás en tu propia máquina y solo quieres el camino más corto hacia una instalación funcional, la documentación te devuelve al flujo normal.

Esta distinción importa mucho. En un equipo local, Docker suele traer su propio coste de preparación. Necesitas Docker Desktop o Docker Engine, Compose v2, memoria suficiente para construir o ejecutar la imagen y algo más de paciencia si la máquina es modesta. La documentación incluso señala que el build de la imagen necesita al menos 2 GB de RAM; de lo contrario, pnpm install puede ser terminado en un host con poca memoria. Nada de eso hace malo a Docker. Solo significa que Docker no es automáticamente el camino de menor resistencia en un portátil.

En un VPS o un servidor Linux la historia cambia. Si el plan es mantener OpenClaw ejecutándose allí a largo plazo, Docker empieza a sentirse mucho más natural. No porque sea mágico, sino porque encaja mejor con el trabajo. El aislamiento del runtime ayuda. Los rebuilds son más limpios. Moverlo a otra máquina resulta más fácil de razonar. En ese contexto, Docker se siente menos como un atajo de instalación y más como el límite de despliegue correcto.

El workflow oficial de Docker refleja eso. No está escrito como un tutorial simpático de una línea. El flujo documentado principal consiste en ejecutar ./scripts/docker/setup.sh desde la raíz del repositorio y dejar que gestione la imagen, el onboarding, .env y el arranque con Docker Compose. Si no quieres construir localmente, la documentación también muestra cómo apuntar primero a una imagen preconstruida:

export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./scripts/docker/setup.sh

Eso dice mucho sobre lo que pretende hacer la ruta Docker. No intenta ocultarte todas las piezas móviles. Empaqueta el runtime. Incluso la documentación distingue entre acciones de configuración y el workflow CLI posterior al arranque. En otras palabras: esto es terreno de despliegue, no “primera instalación de software en un portátil nuevo”.

Resumen en una línea: elegir camino es elegir coste de mantenimiento

Si tuviera que decirlo de forma simple: si OpenClaw va a vivir en tu propio ordenador, empieza por el onboarding oficial de la CLI. Si va a un servidor Linux en la nube y esperas mantenerlo allí, Docker probablemente encaje mejor. Si ya sabes que quieres inspeccionar internals, cambiar comportamiento, trabajar cerca del repo y asumir el proceso de build, entonces la instalación desde source por fin tiene sentido.

Para mí, la diferencia real entre source y Docker no es el número de comandos. Es dónde quieres que viva la carga de mantenimiento. El source te da transparencia y flexibilidad, pero también convierte instalación de dependencias, builds de UI, drift del entorno y cambios a nivel de repositorio en tu problema. Docker mueve gran parte de eso dentro del límite del contenedor, algo estupendo en servidores, aunque sigues teniendo que pensar en persistencia, puertos, health checks, actualizaciones de imagen y exposición. La documentación habla de healthz, readyz, lan, loopback e incluso políticas de firewall Docker en hosts públicos, una pista bastante clara de que esto es un workflow de despliegue para operadores.

Los cuatro errores más comunes

Los errores suelen ser previsibles. Se trata la instalación desde source como camino predeterminado cuando en realidad se parece más a un modo de desarrollo. Se asume que Docker debe ser más fácil incluso en una máquina local. Se ignoran requisitos de runtime como la versión de Node y después se pierden horas depurando síntomas en lugar de la causa. O se consigue que un despliegue de servidor arranque una vez y se olvida que persistencia y recuperación importan más que el primer boot exitoso.

Si planeas mantener OpenClaw en un servidor, ese es también el momento en que los backups dejan de ser opcionales en la práctica. Mi artículo anterior sobre copias de seguridad de volúmenes Docker en GitHub como camino de recuperación de bajo coste está exactamente en esa zona. No es tan emocionante como la instalación, pero se vuelve mucho más valioso la primera vez que necesitas reconstruir algo.

Lo que me gustó de la documentación de OpenClaw, cuando dejé de leerla como una guía genérica de instalación, es que en realidad separa bastante bien a distintos tipos de usuario. Hay un camino para quien quiere usar la herramienta, otro para quien quiere desplegarla y otro para quien quiere trabajar sobre ella. La mayor parte de la confusión viene de mezclar esos roles demasiado pronto.

Si estás construyendo tu propio workflow de servidor, también merece la pena mirar el hub de despliegue. Seguiré añadiendo artículos en este mismo cluster: configuración local, despliegue en VPS, trade-offs de Docker y cómo evitar convertir instalaciones sencillas en algo innecesariamente pesado.