# CLI

> Nitro ships with a `nitro` command to develop, build, preview, and deploy your project.

When `nitro` is installed as a project dependency, run it through your package manager (`npx nitro`, `pnpm nitro`, `yarn nitro`, `bun nitro`, ...) or add it to your `package.json` scripts:

```json [package.json]
{
  "scripts": {
    "dev": "nitro dev",
    "build": "nitro build",
    "preview": "nitro preview"
  }
}
```

Then use `npm run dev`, `pnpm dev`, etc. as shown in the [quick start](/docs/quick-start) guide.

::tip
Every command supports `--help` for an overview of its arguments (for example `nitro build --help`), and `nitro --version` prints the installed Nitro version.
::

All commands accept a project root directory, either as a positional argument (`nitro build ./my-app`) or with the `--dir` flag (preferred). It defaults to the current directory.

::note
Using Nitro as a [Vite plugin](/docs/vite)? Prefer the Vite CLI (`vite dev`, `vite build`, `vite preview`); the Nitro dev server does not support the Vite builder.
::

## `nitro dev`

Start the development server with hot reloading.

```sh
npx nitro dev [--dir <dir>] [--port <port>] [--host <host>]
```

| Flag | Description |
| --- | --- |
| `--dir` | Project root directory. |
| `--port` | Port to listen on. |
| `--host` | Hostname to listen on. |

The dev server watches your Nitro config: changes to `runtimeConfig` or `routeRules` are hot reloaded, while other config changes trigger a full dev server restart.

**Example:**

```sh
npx nitro dev --port 4000 --host 0.0.0.0
```

## `nitro build`

Build the project for production. Nitro prepares the build directory, copies public assets, prerenders any configured routes, and bundles the server into the output directory (`.output/` by default).

```sh
npx nitro build [--dir <dir>] [--preset <preset>] [--minify] [--builder <builder>] [--compatibility-date <date>]
```

| Flag | Description |
| --- | --- |
| `--dir` | Project root directory. |
| `--preset` | The deployment [preset](/deploy) to build for (you can also use the `NITRO_PRESET` environment variable). |
| `--minify` | Minify the output, overriding preset defaults. Use `--no-minify` to disable minification. |
| `--builder` | The bundler to use: `rollup`, `rolldown`, or `vite` (you can also use the `NITRO_BUILDER` environment variable). |
| `--compatibility-date` | The date to use for preset compatibility (you can also use the `NITRO_COMPATIBILITY_DATE` environment variable). |

**Example:**

```sh
npx nitro build --preset cloudflare_module
```

### `NITRO_PRESET` vs `--preset`

Both set the deployment preset, and the `--preset` flag takes precedence over the `NITRO_PRESET` environment variable. The environment variable is handy on deployment platforms and in CI, where you often cannot change the build command:

```sh
NITRO_PRESET=cloudflare_module npm run build
```

## `nitro preview`

Start a local server to preview the production build output.

```sh
npx nitro preview [--dir <dir>] [--port <port>] [--host <host>]
```

| Flag | Description |
| --- | --- |
| `--dir` | Project root directory. |
| `--port` | Port to listen on. |
| `--host` | Hostname to listen on. |

**Example:**

```sh
npx nitro build
npx nitro preview
```

## `nitro deploy`

Build the project, then run the deploy command of the selected preset.

```sh
npx nitro deploy [--dir <dir>] [--prebuilt] [build flags...] [-- <extra deploy args>]
```

| Flag | Description |
| --- | --- |
| `--prebuilt` | Skip the build step and deploy the existing build output. |

All [`nitro build`](#nitro-build) flags (`--preset`, `--minify`, `--builder`, `--compatibility-date`, ...) are also accepted and applied to the build step. Any arguments after `--` are appended to the underlying deploy command (or passed as `args` to a function deploy command).

::note
Not all presets support `nitro deploy`. If the selected preset does not define a deploy command (or no build output is found), the command fails with an error. In that case, use a different preset, configure a deploy command in your Nitro config, or deploy manually following the [deployment guide](/deploy) of your provider.
::

**Example:**

```sh
# Build with the cloudflare_module preset, then run wrangler deploy
npx nitro deploy --preset cloudflare_module

# Deploy an existing build without rebuilding
npx nitro deploy --prebuilt
```

## `nitro task`

Operate on [Nitro tasks](/docs/tasks) (experimental).

::important
Tasks support is experimental and requires the `experimental.tasks` flag. The `task` subcommands work against the **currently running dev server**, so run them in a second terminal while `nitro dev` is running. See the [tasks documentation](/docs/tasks) for details.
::

### `nitro task list`

List available tasks with their descriptions.

```sh
npx nitro task list [--dir <dir>]
```

| Flag | Description |
| --- | --- |
| `--dir` | Project root directory. |

### `nitro task run`

Run a task by name, optionally with a JSON payload.

```sh
npx nitro task run <name> [--dir <dir>] [--payload <json>]
```

| Flag | Description |
| --- | --- |
| `--dir` | Project root directory. |
| `--payload` | JSON string parsed and passed to the task as its payload. |

**Example:**

```sh
npx nitro task run db:migrate --payload '{"force": true}'
```

## `nitro docs`

Explore the Nitro documentation from your terminal (powered by [mdzilla](https://github.com/pi0/mdzilla)), optionally starting at a specific page path.

```sh
npx nitro docs [page]
```