---
title: reed dev
description: Live preview while you edit.
---

```sh
reed dev [--dir <path>] [--content <path>] [--port <n>] [--strict-tokens] [--strict-components]
```

Starts a local preview server that rebuilds as you edit `docs.json` and your content.

**Prerequisites:** a prior successful `reed prefetch` on this machine, and a
Corepack-resolvable package manager. Given those, `dev` needs no network.

## Options

<ParamField name="--dir" type="path">
  Project root. Defaults to the current directory.
</ParamField>

<ParamField name="--content" type="path">
  Content directory. Defaults to `<dir>/content`.
</ParamField>

<ParamField name="--port" type="integer">
  Port to listen on.
</ParamField>

<ParamField name="--strict-tokens" type="boolean" default="false">
  Escalate every warning except `DS-D*` to an error.
</ParamField>

<ParamField name="--strict-components" type="boolean" default="false">
  Escalate `DS-D*` design-system warnings to errors.
</ParamField>

## What dev does not produce

`dev` renders pages. It does **not** write the build-only outputs: no `llms.txt`, no
markdown mirrors, no `sitemap.xml`, no `robots.txt`, no `_headers`. The `<head>` link and
footer link that point at `llms.txt` are absent under `dev` too, since there would be no
file for them to point at.

If you are working on a derived surface rather than on pages, run `reed build` and inspect
the output directory — `dev` cannot show you those.

## Sharing one compile path

`dev` compiles through the same path as `check` and `build`, so a page that renders in
`dev` renders in `build`. The difference is which outputs get written, not how the content
is interpreted.
