Dev Workflow

Four commands cover the whole lifecycle of running and testing a project outside a generated Docker/Kubernetes deployment: dev for local iteration with hot reload, start for running it the way it'll actually run in production, build for just the compile step underneath both, and test for the test suite. dev and start both read src/config.ts to know which datastores to start, so there's nothing extra to configure for local development beyond what the project already has.

rapidrest dev

Runs the project locally with hot reload, the command you reach for the most while actually writing code.

rapidrest dev
rapidrest dev --inspect   # attach a debugger on localhost:9229
rapidrest dev --docker    # assume databases are already running elsewhere
rapidrest dev --port 4000 # prefer a specific port

Flag	Description
--inspect	Enables the Node inspector on port 9229
-d, --docker	Skips starting in-memory database servers (use when your datastores are already running, e.g. via Docker Compose)
-p, --port <n>	Preferred port to bind to

By default, rapidrest dev reads src/config.ts to see which datastores are configured, starts an in-memory instance of each (no local install needed, see Getting Started), and runs your server via tsx --watch. If the project has React configured, it also runs vite build --watch alongside it. Everything is cleaned up on Ctrl+C.

Ports are found automatically: starting from --port (or 3000 if omitted), RapidREST probes upward until it finds a free one. If you pass --port explicitly and that exact port is already taken, dev fails instead of silently picking a different one — the automatic fallback only applies to the default.

rapidrest start

dev's hot-reload machinery (tsx --watch, nodemon) isn't something you want running in production, it exists purely to save a restart while you're editing. start is the production-shaped equivalent: it builds the project and starts the compiled output directly, no watcher, no rebuild-on-change.

rapidrest start
rapidrest start --no-build   # skip the build step
rapidrest start --docker     # assume databases are already running elsewhere
rapidrest start --port 4000  # prefer a specific port
rapidrest start --bun        # run on Bun instead of Node.js

Flag	Description
--no-build	Skip the build step
--no-lint	Skip linting as part of that build step
-d, --docker	Skips starting in-memory database servers
-p, --port <n>	Preferred port to bind to — same automatic-fallback behavior as dev, described above
--bun	Use the Bun engine instead of Node.js. Requires Bun v1.4.0+; downloads a compatible version automatically if none is installed. See Deployment → Bun.

--bun is only available on start, not dev — the dev workflow's hot-reload tooling (tsx --watch, nodemon) runs on Node.js regardless.

rapidrest build

start already builds before it runs; build is that same step on its own, for a CI pipeline that wants to produce dist/ once and hand it to a separate deploy step, rather than building and running in the same process.

rapidrest build
rapidrest build --no-lint

Flag	Description
--no-lint	Skip linting before building

A generated project's own "build" script in package.json is just rapidrest build, so yarn build/npm run build and calling this command directly do the exact same thing. In order: lint src/test/app/apps with ESLint (unless --no-lint), clean out dist/, compile with tsc, then, if the project has React configured, compile the client tsconfig.client.json and run vite build for the hydration bundle. Fails on the first step that errors, a lint failure stops the build before tsc ever runs.

rapidrest test

Runs the project's test suite. Every generated project already has this wired up as its own "test" script, so yarn test and this command are equivalent.

rapidrest test
rapidrest test --coverage
rapidrest test --watch
rapidrest test src/routes/HelloRoute.test.ts

Flag	Description
--coverage	Run with code coverage
--watch	Watch mode instead of a single pass

A thin wrapper around Vitest, running it through your project's own detected package manager. Extra arguments (a specific test file or a glob) pass straight through to Vitest itself, exactly as if you'd run vitest directly.

rapidrest dev vs. rapidreact dev

If your project was scaffolded with rapidrest generate server, use rapidrest dev day-to-day. It already runs the Vite watcher for you when the React feature is configured. rapidreact (from @rapidrest/react directly, covered in SSR React → Dev Mode) is a lower-level tool for driving just the SSR dev workflow, useful if you're integrating @rapidrest/react outside of a CLI-scaffolded project.