Autohospedar un flujo tipo OpenClaw parece sencillo: alquilar un VPS, instalar un agente y apuntarlo a un repositorio. Lo que complica a los equipos es todo lo que rodea ese bucle: secretos, ramas, logs, límites de gasto y el camino de recuperación cuando una tarea larga se queda bloqueada a mitad de una migración.
Esta es la forma de operación que recomendamos a usuarios de OpenClaw que quieren más control sin fingir que Office Claws es un runtime nativo de OpenClaw. Office Claws gestiona estado local de escritorio y runners VPS para agentes respaldados por Codex. Si tu carga de OpenClaw es sobre todo trabajo de repositorio, esto te da la forma self-hosted útil: tus claves siguen locales, cada tarea tiene un runner aislado y cada cambio llega como una rama revisable.
Qué debería significar “OpenClaw Self Hosted”
La definición más segura no es “copiar el servicio alojado en un servidor”. Es dividir el plano de control.
| Capa | Dónde queda | Por qué importa |
|---|---|---|
| Control de escritorio | Máquina local | Tokens API, claves SSH, aprobaciones e intención del operador quedan cerca del desarrollador |
| Ejecución del agente | Runner VPS | Los trabajos largos sobreviven al reposo del portátil y al Wi-Fi inestable |
| Cambios del repositorio | Rama por tarea | Revisión, CI y rollback siguen siendo normales |
| Acceso de red | Malla privada | SSH no queda expuesto directamente a internet |
| Facturación | Suscripción + VPS pequeño | Los costes son previsibles y cada reintento ocioso no se convierte en sorpresa de API |
Ese modelo no es lo mismo que ejecutar OpenClaw como tal. No afirmamos que Office Claws importe extensiones, memoria ni automatizaciones de navegador de OpenClaw. Describimos un flujo self-hosted para usuarios de OpenClaw que sobre todo necesitan trabajo de coding autónomo en máquinas duraderas. La comparación OpenClaw vs Codex es el mejor lugar para decidir si ese intercambio encaja.
La arquitectura de referencia
Un setup self-hosted fiable tiene cuatro partes:
- Office Claws en el escritorio para aprovisionamiento, aprobaciones, estado y manejo local de claves.
- Un VPS por runner activo en Contabo, DigitalOcean, Hetzner o un proveedor en el que ya confíes.
- Tailscale o una malla privada equivalente para que los runners no expongan SSH a internet.
- Codex CLI dentro del runner para la ruta de ejecución centrada en repositorios que muchos usuarios de OpenClaw necesitan tras un cambio de suscripción o coste.
El hábito importante es una tarea, un runner, una rama. No dejes que tres agentes compartan un checkout porque parezca eficiente. Así un experimento self-hosted barato se convierte en diffs misteriosos y resultados de tests sobrescritos. La guía de OpenClaw desktop manager explica por qué la UI insiste tanto en mostrar el estado del runner: si no puedes saber qué agente posee qué repo, todavía no tienes una capa operativa.
Checklist de setup
Empieza pequeño. Un runner basta para demostrar el bucle.
# target shape, not a magic installer
1. create a VPS from a known snapshot
2. join it to your private mesh
3. authenticate Codex CLI on the runner
4. clone one repo into one task workspace
5. create a branch before the agent edits files
6. run tests and push the branch
7. destroy or reset the runner when the task is donePara usuarios de Office Claws, la app se encarga del aprovisionamiento y la capa de estado; tú sigues siendo responsable de permisos del repo, reglas de revisión en GitHub y cuenta del modelo. El plan self-hosted cuesta $4.99/mes por la gestión desktop/VPS, mientras que un runner managed cuesta $14.99/mes si quieres menos responsabilidad sobre servidores. Mantén esas cifras separadas de tu suscripción de modelo y de la factura del VPS.
Antes de darle trabajo real al runner, revisa los controles aburridos:
- Token de GitHub acotado: acceso solo al repo, no un token admin de toda la organización.
- Sin caos de
.envcompartido: pasa solo los secretos que necesita la tarea. - Límite de gasto: pon uno en el proveedor VPS y otro en el flujo de la cuenta del modelo si existe.
- Puerta de CI: nada de deploy directo desde una rama de agente.
- Camino de reset: snapshot o reconstrucción debe ser más rápido que depurar un runner contaminado.
Son los mismos controles que recomendamos en OpenClaw security best practices. Self-hosting elimina una superficie de proveedor, pero añade responsabilidad; no vuelve seguro el trabajo con agentes por arte de magia.
Fallos para los que conviene diseñar
La mayoría de problemas con agentes self-hosted son previsibles. Diseña para ellos antes de la primera ejecución nocturna.
| Fallo | Síntoma | Guardarraíl |
|---|---|---|
| Colisiones en workspace compartido | Dos agentes editan los mismos archivos | Un runner y una rama por tarea |
| SSH público expuesto | Intentos aleatorios de login en logs | Solo malla privada; cerrar SSH público |
| Secretos demasiado amplios | El agente puede leer credenciales no relacionadas | Env por tarea y tokens acotados |
| Bloqueo silencioso | El job se detiene tras un prompt o test fallido | Checks de estado, logs y recuperación explícita |
| Deriva de coste | Runners extra quedan vivos todo el fin de semana | Límites de gasto y limpieza de runners |
La capa de estado importa más de lo que parece. Un multiplexor de terminal puede mantener viva una sesión, pero no responde las preguntas del operador: quién posee esta tarea, qué rama empujó, pasaron los tests y es seguro borrar la máquina. Por eso nuestros posts sobre OpenClaw vuelven a Office Claws para usuarios de OpenClaw en vez de fingir que un VPS desnudo basta.
Recomendación
Si tu trabajo en OpenClaw es sobre todo código, autohospeda primero la capa operativa, no todo. Mantén aprobaciones y credenciales locales. Ejecuta agentes en runners VPS privados. Usa ejecución respaldada por Codex cuando encaje. Pasa cada resultado por GitHub y CI como la rama de cualquier compañero.
Si tu trabajo en OpenClaw depende de extensiones nativas, automatizaciones intensivas de navegador o flujos específicos de plataforma, no lo fuerces en este patrón. Conserva OpenClaw para esos trabajos y usa Office Claws para el trabajo de repositorio que se beneficia de runners duraderos más baratos.
El mejor setup self-hosted es aburrido a propósito: una tarea, un runner, una rama, una puerta de revisión. Ese es el punto. La programación autónoma es mucho más fácil de confiar cuando la infraestructura se niega a ser ingeniosa.