---
title: Instalar Hollware
description: Todas las formas de empezar un proyecto de Hollware, qué release tomar y qué contiene el proyecto.
section: guides
order: 9
---

# Instalar Hollware

Un Hollware es un proyecto tuyo: un Worker pequeño que depende de los paquetes de Hollware, con su propio `wrangler.jsonc`. Lo crea `npm create hollware`. El [Inicio rápido](/docs/quickstart/) es el camino corto; esta página reúne todos.

Necesitas Node.js 24 o superior. La cuenta de Cloudflare entra cuando [despliegas](/docs/deploy/); todo lo anterior corre en tu máquina.

## Un proyecto propio

```sh
npm create hollware my-cms
```

Copia el starter, lo instala, aplica las migraciones a una base de datos local y crea tu sitio, su dueño y un primer token. No pregunta nada; lo que responderías va en opciones, después de `--` con npm:

| Opción | Qué elige | Por defecto |
| --- | --- | --- |
| `--name <nombre>` | El nombre del Worker y de su base de datos | el nombre del directorio |
| `--site <clave>` | La clave de tu sitio; nunca cambia | `my-site` |
| `--preset blog \| docs \| empty` | Con qué parte el sitio | `blog` |
| `--locales en,es` | Sus idiomas, el primero es el por defecto | `en` |
| `--pm npm \| pnpm` | Quién instala | `npm` |
| `--token-file <ruta>` | Escribe el primer token en un archivo, nunca en pantalla | |
| `--ip-addresses off \| hashed`, `--audit-retention-days <n>` | Qué guarda el [registro de actividad](/docs/security/#registro-de-actividad) | `off`, para siempre |
| `--no-install` | Solo copia los archivos: sin instalar, sin base de datos, sin sitio | |
| `--no-git` | Sin `git init` | |
| `--json` | Un objeto JSON en stdout, para un agente o un script | |

```sh
npm create hollware my-cms -- --site acme --preset docs --locales en,es --token-file owner.token
pnpm create hollware my-cms --pm pnpm
```

## Qué release

| Canal | Qué es | Comando |
| --- | --- | --- |
| `latest` | El release estable más reciente | `npm create hollware my-cms` |
| `rc` | El próximo release, como release candidate | `npm create hollware@rc my-cms` |
| Una versión exacta | Ese release, siempre | `npm create hollware@1.0.0 my-cms` |

`create-hollware` de una versión crea un proyecto de esa misma versión: fija `hollware` y `@hollware/*` exactamente en ella, y las herramientas con que se probó (wrangler, los plugins de Cloudflare, Vite+, Vitest, TypeScript) en las suyas. Un proyecto nunca se mueve solo; lo [actualizas](/docs/upgrade/) cuando tú decides.

pnpm, desde la versión 11, no instala nada publicado hace menos de un día (`minimumReleaseAge`). El día de un release, `pnpm create hollware` toma el release anterior, completo. Espera un día, o crea tu proyecto con npm.

## Dentro de un monorepo

Hollware puede vivir junto al sitio que lo lee, en un mismo repositorio, como `apps/cms` al lado de `apps/web`. Créalo sin instalar y luego instala desde la raíz:

```sh
pnpm create hollware apps/cms --pm pnpm --no-install --no-git --name my-cms --site my-site
```

Después:

1. Borra `apps/cms/pnpm-workspace.yaml`: pnpm lee el de la raíz. Copia su `allowBuilds` (`esbuild: true`, `workerd: false`) en el de la raíz.
2. Borra los `overrides` de `apps/cms/package.json`: son para npm, que solo los lee en la raíz.
3. Instala desde la raíz, y crea la base de datos local y tu sitio desde `apps/cms`:

```sh
pnpm install
cd apps/cms
pnpm exec hollware migrate --local
pnpm exec hollware init --site my-site --local --token-file owner.token
```

Cada comando de `hollware` se ejecuta desde `apps/cms`: la CLI trabaja sobre el proyecto del directorio actual. Un sitio del mismo repositorio lee el Hollware desplegado por un [service binding](/docs/read-from-a-site/), o por HTTP con un token de lectura.

## Qué contiene el proyecto

| Archivo | De quién | Qué es |
| --- | --- | --- |
| `src/worker.ts` | tuyo | El Worker: lo construye `createHollware()` |
| `wrangler.jsonc` | tuyo | El Worker, su base de datos, namespace, colas, bucket, URL pública y dominio |
| `vite.config.ts`, `vitest.config.ts`, `test/` | tuyos | El build, el servidor local y tests que corren dentro de workerd |
| `AGENTS.md` | tuyo | Lo que necesita saber un agente que trabaja en el proyecto |
| `worker-configuration.d.ts` | de wrangler | Los tipos de los bindings; lo escribe `npm run types` |
| `node_modules/@hollware/server` | de Hollware | El código y las migraciones de la base de datos |
| `node_modules/@hollware/admin` | de Hollware | El admin, compilado |

Los archivos tuyos se crean una vez y Hollware nunca los reescribe, así que una actualización de los paquetes los deja como están. Cuando un release pide un cambio en alguno, sus notas y la [guía de actualización](/docs/upgrade/) dicen cuál.

Tu contenido y la estructura de tus sitios viven en la base de datos, nunca en el proyecto: el repositorio no guarda contenido, y [varios sitios](/docs/multiple-sites/) comparten un proyecto.

## Desde otro CMS

`hollware import` trae un directorio de Markdown, como borradores o publicado, y ejecutarlo de nuevo no cambia nada. Lee una estructura simple de `<collection>/<locale>/<slug>.md`, o el `content/` de un sitio de Nuxt Content con `--from nuxt-content`. Ver [la CLI](/docs/cli/#import).

## Revísalo

```sh
npx hollware doctor
```

Revisa los flags, los bindings, el admin compilado, las migraciones y el dueño, y dice qué corregir.