--- title: La CLI de hollware description: Cada comando de la CLI de hollware, que trabaja sobre el proyecto del directorio actual a través de su wrangler. section: reference order: 1 --- # 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 ```sh 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](/es/docs/security/#registro-de-actividad)). Para un agente, dos flags sirven en cada comando que crea un token o entrega una respuesta: `--token-file ` 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 ```sh 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 ```sh 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 ```sh 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 ```sh 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 ```sh 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](/docs/images/)), 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 ```sh 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 ```sh hollware invite --role editor hollware invite --owner ``` ## import ```sh hollware import ./content --url https://cms.example.com --token-file ./token.txt [--publish] [--dry-run] ``` Importa un directorio organizado como `//.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: ```sh 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 ```sh 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 `//.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 --assets-url `, en cambio, van a `` tal como se sirven, y cada referencia `asset:` apunta a ``: para un sitio que se construye desde la exportación y sirve sus imágenes él mismo. Ver [Imágenes](/docs/images/#tus-imágenes-en-tu-sitio). 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 ```sh 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](/es/docs/deploy/#restaurar)). `list` dice cuáles hay, con su tamaño. `get` escribe el de una fecha en un directorio vacío como `//.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`).