---
title: Install Hollware
description: Every way to start a Hollware project, which release to take, and what the project holds.
section: guides
order: 9
---

# Install Hollware

A Hollware is a project of yours: a small Worker that depends on the packages of Hollware, with its own `wrangler.jsonc`. `npm create hollware` makes it. The [Quickstart](/docs/quickstart/) is the short way; this page is every way.

You need Node.js 24 or later. A Cloudflare account comes in when you [deploy](/docs/deploy/); everything before runs on your machine.

## A project of its own

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

It copies the starter, installs it, applies the migrations to a local database and makes your site, its owner and a first token. It asks nothing; what you would answer goes in options, after `--` with npm:

| Option | What it chooses | Default |
| --- | --- | --- |
| `--name <name>` | The name of the Worker and of its database | the name of the directory |
| `--site <key>` | The key of your site; it never changes | `my-site` |
| `--preset blog \| docs \| empty` | What the site starts with | `blog` |
| `--locales en,es` | Its locales, the first one the default | `en` |
| `--pm npm \| pnpm` | Who installs | `npm` |
| `--token-file <path>` | Write the first token to a file, never to the screen | |
| `--ip-addresses off \| hashed`, `--audit-retention-days <n>` | What the [activity log](/docs/security/#activity-log) keeps | `off`, forever |
| `--no-install` | Only copy the files: no install, no database, no site | |
| `--no-git` | No `git init` | |
| `--json` | One JSON object on stdout, for an agent or a 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
```

## Which release

| Channel | What it is | Command |
| --- | --- | --- |
| `latest` | The newest stable release | `npm create hollware my-cms` |
| `rc` | The next release, as a release candidate | `npm create hollware@rc my-cms` |
| An exact version | That release, always | `npm create hollware@1.0.0 my-cms` |

`create-hollware` of a version makes a project of that same version: it pins `hollware` and `@hollware/*` to it exactly, and the tools it was tested with (wrangler, the Cloudflare plugins, Vite+, Vitest, TypeScript) to theirs. A project never moves on its own; you [upgrade it](/docs/upgrade/) when you choose.

pnpm, from version 11, installs nothing published less than a day ago (`minimumReleaseAge`). On the day of a release, `pnpm create hollware` takes the release before it, whole. Wait a day, or make your project with npm.

## Inside a monorepo

Hollware can live next to the site that reads it, in one repository, as `apps/cms` beside `apps/web`. Make it without installing, then install from the root:

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

Then:

1. Remove `apps/cms/pnpm-workspace.yaml`: the root's is the one pnpm reads. Copy its `allowBuilds` (`esbuild: true`, `workerd: false`) into the root's.
2. Remove the `overrides` of `apps/cms/package.json`: they are for npm, which reads them only at the root.
3. Install from the root, then make the local database and your site from `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
```

Every `hollware` command runs from `apps/cms`: the CLI works on the project of the current directory. A site in the same repository reads the deployed Hollware over a [service binding](/docs/read-from-a-site/), or over HTTP with a read token.

## What the project holds

| File | Whose | What it is |
| --- | --- | --- |
| `src/worker.ts` | yours | The Worker: `createHollware()` builds it |
| `wrangler.jsonc` | yours | The Worker, its database, namespace, queues, bucket, public URL and domain |
| `vite.config.ts`, `vitest.config.ts`, `test/` | yours | The build, the local server and tests that run inside workerd |
| `AGENTS.md` | yours | What an agent working on the project needs to know |
| `worker-configuration.d.ts` | wrangler's | The types of the bindings; `npm run types` writes it |
| `node_modules/@hollware/server` | Hollware's | The code and the migrations of the database |
| `node_modules/@hollware/admin` | Hollware's | The admin, built |

The files that are yours are made once and never rewritten by Hollware, so an upgrade of the packages leaves them as they are. When a release asks for a change in one of them, its release notes and the [upgrade guide](/docs/upgrade/) say which.

Your content and the structure of your sites live in the database, never in the project: the repository holds no content, and [several sites](/docs/multiple-sites/) share one project.

## From another CMS

`hollware import` brings a directory of Markdown in, as drafts or published, and running it again changes nothing. It reads a plain layout of `<collection>/<locale>/<slug>.md`, or the `content/` of a Nuxt Content site with `--from nuxt-content`. See [the CLI](/docs/cli/#import).

## Check it

```sh
npx hollware doctor
```

It checks the flags, the bindings, the built admin, the migrations and the owner, and says what to fix.