Mi configuración de OpenClaw: una sola máquina que puede crear sitios web

El sitio web que estás leyendo ahora mismo lo mantienen agentes de IA que corren en una pequeña máquina Linux en mi casa — y todo el montaje está pensado para que puedan hacer trabajo real sin poder jamás destrozar nada.

Antes que nada, la parte que se demuestra a sí misma: este artículo se actualiza una vez por semana gracias al mismo sistema que describe. Una tarea programada despierta a un agente de OpenClaw, que vuelve a leer esta página, corrige lo que esté desactualizado, ejecuta las comprobaciones de seguridad y sella el resultado. La fecha de “Actualizado” en la parte superior de esta página la escribe esa tarea semanal — nadie la teclea. Si esa fecha es reciente, la canalización de estos diagramas se ejecutó de principio a fin en los últimos siete días.

Toda la máquina, de un vistazo

Todo vive en una sola máquina. Los modelos sirven tokens — hoy en día sobre todo la económica API en la nube de DeepSeek, con modelos locales como reserva — el gateway de OpenClaw los convierte en agentes con herramientas, los agentes editan contenido en texto plano, un generador determinista compila el sitio, y un único script controlado es el único camino hacia el servidor.

Lo que obtienes

El estado final, antes de hablar de configuración:

• “Redáctame una entrada sobre X” en el chat → un agente escribe un artículo en Markdown dentro de la carpeta content/ del sitio, siguiendo el esquema de frontmatter y el estilo propio del sitio, y reconstruye la vista previa local.
• “Despliégalo” → el agente ejecuta el script de despliegue, que por defecto hace un dry-run: muestra exactamente qué archivos cambiarían en el servidor y no toca nada. Publicar de verdad requiere un --go explícito de mi parte, y aun así el script primero hace una copia de seguridad en el servidor y nunca borra nada.
• Una vez por semana, una tarea programada despierta a un agente para actualizar el sitio — corregir fechas obsoletas, mejorar entradas flojas, revisar enlaces — con comprobaciones de seguridad antes de que nada pueda publicarse (el Paso 3 tiene los detalles).
• laserlloyd.com se gestiona precisamente así.

La división del trabajo es justo el punto: los agentes escriben, los scripts hacen cumplir las reglas, y yo tomo la única decisión que importa: si un cambio se publica o no.

El hardware y el sistema operativo: cualquier máquina Linux sirve

Yo uso un mini PC con mucha memoria unificada porque me gusta ejecutar modelos grandes en local (la pila completa está en mi artículo hermano, Ocho agentes de IA, una máquina AMD). Pero para la gestión de sitios web en concreto, los requisitos son modestos:

• Cualquier máquina Linux de 64 bits — un mini PC, un escritorio viejo, incluso un portátil decente. Con 16 GB de RAM los modelos locales pequeños funcionan bien; con 32 GB o más se abren modelos de tamaño medio que escriben con una prosa notablemente mejor.
• Una distribución con systemd (casi todas lo tienen) — la programación y la supervisión de servicios que veremos más abajo lo dan por hecho.
• Python 3 para el generador de sitio estático, rsync + SSH para los despliegues.

Ni siquiera necesitas estrictamente una GPU. Los modelos pequeños ajustados por instrucciones funcionan de forma aceptable en CPU para redactar y editar texto. Pero seré honesto sobre dónde terminé después de meses usando ambas opciones: la API en la nube de DeepSeek es hoy el motor principal de toda mi configuración de OpenClaw. Los modelos locales abiertos eran el plan original, y siguen funcionando, pero las contrapartidas se acumulan — minutos de carga del modelo, malabares de VRAM entre servicios, y una inteligencia notablemente inferior a la de un modelo en la nube barato y de última generación que cuesta fracciones de centavo por mensaje. Lo local es mi reserva y mi nivel de privacidad, no mi opción diaria. (La factura mensual real: unos 24 dólares.)

Paso 1: instalar un gateway de agentes y un modelo local

Dos piezas: algo que sirva un modelo mediante una API compatible con OpenAI, y algo que convierta ese modelo en un agente — con herramientas, acceso a archivos y tareas programadas.

Servidor de modelos. LM Studio, Ollama, o el servidor de llama.cpp funcionan igual de bien. Elijas el que elijas, ejecútalo como un servicio de usuario de systemd para que sobreviva a los reinicios:

# ~/.config/systemd/user/model-server.service
[Unit]
Description=Local LLM server
[Service]
ExecStart=/path/to/your/model-server --port 1234
Restart=on-failure
[Install]
WantedBy=default.target

systemctl --user enable --now model-server
curl -s http://localhost:1234/v1/models   # sanity check

Gateway de agentes. Yo uso OpenClaw, un gateway abierto y autoalojado que aloja agentes con nombre, les da herramientas (shell, lectura/escritura de archivos, búsqueda web), enruta cada agente a un modelo (local o en la nube, con opciones de reserva) y expone una interfaz de chat. Instálalo, apunta un agente “webmaster” a tu modelo local, y dale acceso a herramientas limitado al directorio del sitio web. Dos reglas de configuración que importan sin importar qué gateway elijas:

• Vincula el gateway a loopback y pon cualquier interfaz de chat detrás de autenticación. Un agente con acceso a shell no es algo que se deba dejar abierto en tu red.
• Limita el directorio de trabajo del agente al repositorio del sitio. Necesita editar content/, no tu directorio personal.

Dos niveles: agentes locales para lo rutinario, un modelo potente en la nube para las reparaciones

Una sola máquina, dos niveles de capacidad. Los agentes de OpenClaw — apoyados en la económica API de DeepSeek, con modelos locales detrás como reserva — se encargan del trabajo cotidiano y de gran volumen: redactar, editar, revisar enlaces, la actualización semanal. Pero cuando el propio sistema se rompe (una regresión de configuración, un gateway que se cae, una compilación que no arranca), escalo a un modelo de programación potente en la nube que trata la máquina entera como su paciente. Conté esa historia por separado en Cuando OpenClaw se rompe, lo arreglo con Claude Code: los agentes de OpenClaw son la mano de obra, el modelo de programación potente es el mecánico.

El equipo: todos los bots de la máquina

El gateway aloja una plantilla de agentes con nombre, cada uno enrutado al modelo que mejor encaja con su trabajo. Todos aparecen en DisPatch, la aplicación de chat que usa la familia — pero no todos en ambos modos: el bloqueo por PIN de DisPatch divide la plantilla en un conjunto seguro siempre disponible y un conjunto de plena potencia que solo aparece tras desbloquear.

Bot	Función	Corre en	DisPatch (bloqueado)	DisPatch (desbloqueado)
Bits	Recepción — el agente con el que hablas; entiende la petición y la deriva al especialista correcto	DeepSeek flash (nube)	—	✔
Brains	El pensador profundo — especificaciones, auditorías, todo lo que merece la pena esperar	DeepSeek reasoner (nube)	—	✔
Flash	Trabajos rápidos y seguimientos programados — el vigilante que persigue el trabajo atrasado	DeepSeek flash (nube)	—	✔
Hermes	El puente hacia el agente de programación — trabajo de programación derivado	DeepSeek (nube)	—	✔
Doxy	Caballo de batalla local — trabajos masivos y privados que no deben salir de casa	Modelo local de 122B (vLLM)	—	✔
Charley	Visión — "¿qué hay en esta foto?", tareas que requieren entender imágenes	Gemma 31B (local, LM Studio)	✔	✔
Alpha y Beta	Ayudantes generales aptos para toda la familia — preguntas de tareas escolares, charla cotidiana	DeepSeek flash (nube)	✔	✔
Terminex	No es un agente — es la terminal de programación Reasonix de DisPatch, un PTY real en el navegador	DeepSeek (nube)	—	✔

Cómo rinden, con honestidad:

• Los bots respaldados por DeepSeek son los caballos de batalla diarios. Los agentes de nivel flash (Bits, Flash, Alpha, Beta) responden en segundos, cuestan fracciones de centavo por mensaje y nunca necesitan calentarse. Brains, en el nivel reasoner, tarda notablemente más por respuesta — ese es justo el punto, es al que le entregas los problemas que merecen pensarse — y aun así cuesta centavos por sesión. La factura medida de toda la pila está en el artículo de costes.
• Los bots locales son más lentos y menos inteligentes, pero privados y gratuitos. El modelo de 122B de Doxy tarda minutos en cargarse en memoria y sus turnos largos pueden extenderse varios minutos más; los tiempos de espera del gateway tuvieron que ampliarse específicamente para acomodarlo. El modelo de visión de Charley es la excepción que se mantiene ocupada — la descripción de imágenes es algo que ningún nivel barato en la nube hace aquí, así que un modelo local se gana su VRAM.
• El conjunto seguro es deliberadamente aburrido. Alpha, Beta y Charley forman la plantilla del modo bloqueado: información general y visión, sin herramientas que toquen archivos o sistemas. Eso es lo que hace que darle el teléfono a un niño no sea ningún acontecimiento.

Paso 2: un sitio estático más un script de despliegue controlado

Los agentes y WordPress combinan mal — una base de datos, un inicio de sesión, plugins y PHP son, todos ellos, superficie de ataque y modos de fallo. Un generador de sitios estáticos es el compañero natural de un agente: todo el sitio son archivos de texto plano en una carpeta, la compilación es un solo comando, y “publicar” es copiar archivos. Mi generador son unos cientos de líneas de Python (Jinja2 + Markdown + YAML); Hugo, Eleventy o Zola funcionan igual. Lo que importa es el contrato:

• El contenido son archivos Markdown con frontmatter. Un LLM los edita de forma nativa y un git diff muestra exactamente qué hizo.
• La compilación es determinista. El mismo contenido de entrada produce un sitio idéntico byte a byte — así que cualquier cambio en la salida se puede rastrear hasta un cambio de contenido.
• Solo existe un camino de despliegue, y es un script con la seguridad integrada, no un conjunto de instrucciones que se confía en que el agente siga.

Ese último punto es el corazón de todo este montaje. Así es el mío:

./deploy.sh preflight   # checks SSH, target webroot, size budget
./deploy.sh             # build + DRY-RUN rsync — prints what would change
./deploy.sh --go        # build + server-side backup + publish + verify

Y lo que el script garantiza, en orden de importancia:

1. Dry-run por defecto. Ejecutarlo sin argumentos nunca puede modificar el servidor. Un agente puede ejecutarlo libremente para mostrarme un despliegue pendiente.
2. Nunca borra. rsync se ejecuta sin --delete. Un agente confundido puede sobrescribir una página con una versión más nueva; no puede borrar el sitio.
3. Hace copia de seguridad primero. Con --go, el script genera un tarball del webroot en el servidor antes de sobrescribir ningún archivo (conservando las últimas copias). Si la copia de seguridad falla, el despliegue se aborta.
4. Fail-closed. Un manifiesto ausente, un host inalcanzable o un valor de configuración de relleno abortan el proceso antes de que se ejecute rsync. Los archivos fuente (plantillas, scripts, configuraciones) están excluidos de forma rígida, para que nunca puedan llegar al webroot público.
5. Verifica después. Descarga la página principal en producción y busca con grep una marca que la compilación incrusta — un simple HTTP 200 puede ser un falso positivo si un alojamiento antiguo todavía responde por ese dominio.

Al agente se le permite ejecutar el dry-run y el preflight cuando quiera. La bandera --go está reservada para mí. Esa única asimetría convierte “una IA tiene acceso casi-SSH a mi sitio en producción” de algo aterrador en algo aburrido.

Paso 3: actualizaciones semanales programadas, con barreras de seguridad

La última pieza es la que hace que todo se mantenga solo. Un temporizador de systemd se dispara una vez por semana y le entrega al agente un encargo permanente: revisar el sitio, actualizar lo que esté desactualizado, ajustar las entradas flojas, verificar los enlaces internos, y dejar el resultado listo para revisión — no publicarlo. Ese mismo trabajo es el que mantiene este artículo: parte de su encargo es “volver a leer el artículo sobre la configuración de OpenClaw, corregir cualquier cosa que se haya alejado de la realidad, y sellar la fecha updated:”. La fecha en la parte superior de esta página es ese sello.

# ~/.config/systemd/user/site-refresh.timer
[Unit]
Description=Weekly website content refresh
[Timer]
OnCalendar=Sun 06:00
Persistent=true
[Install]
WantedBy=timers.target

El servicio que dispara llama a la API (o CLI) del gateway con el encargo, y luego ejecuta las comprobaciones de seguridad sobre lo que el agente haya dejado listo:

• Escaneo de secretos. Un análisis de patrones sobre el diff en busca de cualquier cosa con forma de clave de API, token, contraseña u host privado. Herramientas como gitleaks hacen esto de fábrica. Cualquier coincidencia aborta la ejecución — fail-closed, sin excepciones.
• Comprobación de contenido profesional. Una segunda pasada de LLM, con un prompt distinto al del redactor, revisa los cambios listos frente a una sola pregunta: “¿estaría una empresa cómoda publicando esto?” Tono, afirmaciones, TODOs sin terminar, texto de relleno. Si falla, los cambios quedan listos para revisión humana en lugar de desplegarse.
• La compilación debe pasar, incluido el verificador de enlaces y recursos — una imagen rota o un enlace interno muerto hace fallar la ejecución antes de que llegue siquiera al script de despliegue.

Solo cuando las tres comprobaciones pasan la tarea llega siquiera a simular un despliegue — y en este sitio, la publicación real sigue esperando mi --go. Si con el tiempo confío lo suficiente en la canalización como para dejar que la tarea semanal publique de forma autónoma, las barreras de seguridad más el script de despliegue que nunca borra y siempre hace copia de seguridad primero limitan el peor escenario a “se publicó un artículo malo y lo restauré desde la copia de seguridad”.

Cómo replicar esto

Todo lo anterior se puede construir a partir de esta descripción — no hay nada propietario en ello. La receta, condensada:

1. Elige una máquina Linux e instala un servidor de modelos local (LM Studio, Ollama, llama.cpp) como servicio de systemd.
2. Instala un gateway de agentes (OpenClaw o similar) vinculado a loopback; crea un agente webmaster con herramientas de archivos/shell limitadas al directorio del sitio.
3. Pasa el sitio a un generador estático si aún no lo está — contenido en Markdown como entrada, un comando de compilación como salida.
4. Escribe el script de despliegue controlado con las cinco garantías de arriba: dry-run por defecto, sin borrados, copia de seguridad primero, fail-closed, verificación posterior al despliegue. Esta es la pieza que merece más cuidado; son unas 150 líneas de bash.
5. Añade el temporizador semanal y las dos comprobaciones de seguridad (escaneo de secretos + revisión de contenido por LLM), en modo fail-closed.
6. Mantén --go en manos humanas hasta que la canalización se haya ganado lo contrario.

Siguiendo la convención de este sitio, el recuadro de “impleméntalo tú mismo” al principio del artículo significa exactamente lo que dice: este escrito está deliberadamente detallado como para que puedas entregarle el artículo completo a tu propio LLM y pedirle que construya cada pieza para tu sitio. La lista de garantías del script de despliegue es, en la práctica, su especificación.

Trampas comunes

• El script de despliegue debe ser el único camino. La primera vez que tú (o un agente) improvisáis un rsync “solo por esta vez”, habéis creado el incidente que el script existía para evitar. El mío excluye de forma rígida los archivos fuente y rechaza configuraciones de relleno precisamente porque un comando puntual no lo haría.
• Un simple HTTP 200 no es un despliegue exitoso. Durante mi migración de WordPress, el alojamiento antiguo seguía respondiendo por el dominio — cada “verificación” pasaba mientras los archivos nuevos estaban ahí, sin usarse. Incrusta una marca de generador en tu compilación y busca esa marca con grep en la página en producción.
• Los agentes siguen el esquema que les muestras, TODOs incluidos. Si la plantilla de tu artículo tiene texto de relleno, un modelo perezoso publicará TODO: excerpt here tal cual. Esa es la mitad de la razón por la que existe la comprobación de contenido profesional.
• No dejes que el redactor se revise a sí mismo. Mismo modelo, mismo prompt, mismos puntos ciegos. El revisor necesita, como mínimo, un prompt distinto; idealmente, un modelo distinto.
• Las tareas de LLM programadas necesitan tiempos de espera y un valor por defecto de “listo para revisión, no publicado”. Una tarea semanal que puede publicar sin supervisión, tarde o temprano publicará algo raro un domingo a las 6 de la mañana. Dejarlo listo para revisión no cuesta nada más que una revisión.
• Los escaneos de secretos van en la canalización, no en las instrucciones del agente. “Nunca incluyas secretos” en un prompt es un deseo; un escaneo fail-closed sobre el diff es un control.