La CLI de hollware

La CLI viene con cada proyecto como dependencia de desarrollo. Ejecútala con npx hollware o pnpm exec hollware, desde dentro del proyecto: lee el wrangler.jsonc del proyecto y ejecuta su propio wrangler. Cada comando responde a --help.

Los comandos que tocan la base de datos reciben --local (por defecto) o --remote, y --database para otra base de datos D1 que no sea el binding DB. Los comandos sobre un sitio reciben --site cuando la base de datos tiene varios.

init

hollware init --site my-site [--preset blog | docs | empty] [--locales en,es] [--owner-name "Ada"]
              [--ip-addresses off | hashed] [--audit-retention-days 365]
              [--token-file owner.token] [--json]

Crea el sitio, su dueño y un primer token personal, e imprime un enlace para configurar la passkey del dueño. El sitio parte de una plantilla, un blog en inglés salvo que indiques otra cosa, al que luego das forma en el admin. En una base de datos que ya tiene dueño, agrega el sitio a ese dueño. Un proyecto que todavía tiene un hollware.config.ts lo conserva: su Worker lo traslada a la base de datos. --ip-addresses y --audit-retention-days eligen qué guarda el registro de actividad del sitio: ninguna dirección y todas las líneas, salvo que indiques otra cosa (Tokens, OAuth y passkeys).

Para un agente, dos flags sirven en cada comando que crea un token o entrega una respuesta: --token-file <ruta> escribe el token en un archivo que solo tú puedes leer (modo 0600) e imprime la ruta en su lugar, y --json imprime un solo objeto JSON y nada más (init, token create, invite, doctor y npm create hollware).

dev

hollware dev                 # en primer plano, hasta Ctrl+C
hollware dev --detach        # en segundo plano; imprime la URL y vuelve
hollware dev --stop          # detiene el que inició --detach

Inicia el servidor local del proyecto y dice Hollware is ready at http://localhost:5199 cuando ya responde. Ctrl+C, o --stop, lo termina junto con cada proceso que inició. --json imprime la URL como JSON, para un agente.

mcp-config

hollware mcp-config [--client claude-code | cursor | vscode | json] [--url https://cms.example.com]

Imprime lo que conecta un cliente MCP con este Hollware: la línea claude mcp add para Claude Code, o el bloque JSON de .mcp.json para Cursor, VS Code y los demás. El header nombra la variable de entorno HOLLWARE_TOKEN, nunca el token: defínela desde tu archivo de token con export HOLLWARE_TOKEN="$(cat owner.token)".

migrate

hollware migrate [--check]

Aplica las migraciones que le faltan a la base de datos. Con --remote, primero exporta un respaldo en .wrangler/hollware-backups, salvo que la base de datos sea nueva. D1 no puede exportar una base de datos con un índice de texto completo, que todo Hollware tiene desde 0.5: en ese caso guarda un marcador de Time Travel y muestra el comando que restaura la base de datos a ese punto. --check solo lista lo pendiente.

deploy

hollware deploy [--url https://cms.example.com]

Despliega con wrangler, que crea los recursos que faltan la primera vez (la base de datos, el namespace, las colas y el bucket de imágenes), configura la URL pública, crea HOLLWARE_SECRET cuando el Worker no lo tiene (sella los secretos que crea Hollware, como los de los webhooks) y migra la base de datos remota. A un proyecto ya desplegado lo migra primero, mientras su Worker sigue sirviendo, así que el Worker nuevo nunca sirve una base de datos sin sus tablas. --url en un dominio tuyo también escribe su ruta en wrangler.jsonc como dominio personalizado.

doctor

hollware doctor [--remote] [--json]

Revisa los flags, la URL pública, los bindings (entre ellos el bucket y el binding de Images de las imágenes), el cron, la cola de eventos, el rate limit, el admin compilado, las migraciones y el dueño de la base de datos local, o de la remota con --remote, y dice qué corregir. Un proyecto sano termina con "Everything Hollware needs is in place."

token

hollware token create --label ci [--scopes content:read,content:write] [--expires-in-days 30] [--token-file ci.token] [--json]
hollware token create --label my-site --read
hollware token list
hollware token revoke tok_...

Un token vence después de --expires-in-days, de 1 a 365, y nunca si no lo indicas; hollware token revoke lo termina de inmediato. El primer token de hollware init vence a los 90 días.

invite

hollware invite --role editor
hollware invite --owner

import

hollware import ./content --url https://cms.example.com --token-file ./token.txt [--publish] [--dry-run]

Importa un directorio organizado como <collection>/<locale>/<slug>.md, por MCP, con las imágenes de su _assets/ cuando las tiene. Primero valida cada archivo y no escribe nada si alguno sería rechazado; ejecutarlo de nuevo no cambia nada.

Para traer un sitio de Nuxt Content, --from nuxt-content lee su content/ como los archivos que importa Hollware:

hollware import ./content --from nuxt-content --collection docs --locale-dirs --url https://cms.example.com --token-file ./token.txt

Una página conserva su Markdown, con su slug tal como lo enruta Nuxt Content y un title tomado de su primer título cuando no tiene uno. Con --locale-dirs, la primera carpeta es el locale, y las páginas con la misma ruta son traducciones entre sí.

export

hollware export ./backup --url https://cms.example.com --token-file ./token.txt [--published] [--collection blog] [--locale en]
                [--assets public/images/cms --assets-url /images/cms/] [--dry-run]

Escribe cada entrada como <collection>/<locale>/<slug>.md, exactamente como la guarda Hollware, en un directorio vacío: con los borradores, o solo lo publicado con --published. hollware import la recibe de vuelta sin cambios, así que una exportación es también un respaldo de tu contenido en archivos simples.

Las imágenes que muestran las entradas van a _assets/, tal como se subieron, con un assets.json que hollware import vuelve a subir antes que las entradas. Con --assets <dir> --assets-url <ruta>, en cambio, van a <dir> tal como se sirven, y cada referencia asset: apunta a <ruta>: para un sitio que se construye desde la exportación y sirve sus imágenes él mismo. Ver Imágenes.

Con --published, las entradas que cambiaron de slug quedan también en redirects.json, cada una con su ruta anterior y la nueva: un sitio estático las convierte en 301.

backup

hollware backup list --url https://cms.example.com --token-file ./owner.token
hollware backup get 2026-10-18 ./restore --url https://cms.example.com --token-file ./owner.token [--published]

Los respaldos diarios que tu Hollware guarda en su bucket de R2 (Despliegue). list dice cuáles hay, con su tamaño. get escribe el de una fecha en un directorio vacío como <collection>/<locale>/<slug>.md, el formato que lee hollware import, con site.json, la definición del sitio: la última revisión de cada entrada fuera de la papelera, o solo lo publicado con --published. Ambos requieren un token personal de un dueño (schema:admin).