reed dev

sh

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

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

--dirpath

Project root. Defaults to the current directory.

--contentpath

Content directory. Defaults to <dir>/content.

--portinteger

Port to listen on.

--strict-tokensbooleandefault: false

Print every warning except DS-D* as an error. Unlike check and build, dev still starts: it refuses to start only on diagnostics that are errors in their own right.

dev does not honor --strict-components. To gate on DS-D* warnings, run reed check --strict-components.

What dev does not produce

dev renders pages and serves the per-page .md mirrors, kept in sync as you edit. It does not write the build-only outputs: no llms.txt, no sitemap-index.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.