Docs Deployment

The site produces static VitePress output. Earlier documentation described Cloudflare Pages; the actual hosting, deployed revision and access controls behind menzzo-docs.trydev.ovh remain unverified. Treat the settings below as the historical target, not a live infrastructure inventory.

Setting	Value
Project	menzzo-docs
Repository	axelites/menzzo-docs
Build command	npm run build && npm run docs:check
Output directory	build
Production branch	main

For the VitePress candidate, choose the VitePress preset, leave the root directory blank (repository root), and override the build output to build. Set NODE_VERSION=24.12.0 for Production and Preview, matching .nvmrc. Keep automatic dependency installation enabled; if an existing SKIP_DEPENDENCY_INSTALL=true setting is retained, use npm ci && npm run build && npm run docs:check instead. Git-integrated Pages needs no separate deploy command.

These are the target settings, not a claim that the live project already uses them. Cloudflare documents build configuration and Node version overrides. Project creation, custom domains, DNS, and redirects must be confirmed before mutation.

Verify the local candidate

Run from the repository root using .nvmrc:

npm ci
npm run build
npm run docs:check
npm run serve -- --host 127.0.0.1

Inspect onboarding, a project page, a flow and a runbook. Check search result navigation, Mermaid diagrams and direct deep links. Site configuration is in .vitepress/config.mts; navigation is in .vitepress/navigation.ts.

Host requirements

Serve build/ at the domain root. The host must resolve clean /docs/... URLs and nested directory indexes. static/_redirects and static/_headers are copied to the output root for compatible hosts; other servers need equivalent rules. Local preview alone does not apply or prove Cloudflare redirects or response headers.

Check the emitted asset filenames before configuring cache rules: hashed assets may be cached immutably, while HTML must revalidate. Preserve existing access controls; do not expose internal documentation by changing hosting defaults.

Approved rollout and rollback

Before production inspection or deployment, establish the exact system and show the command for individual approval. Before a GitHub write, verify repository, destination, author/committer, effective account and actual push transport identity. Determine whether a branch push triggers deployment before pushing.

Keep the previously deployed artifact and host rules available for rollback. After an approved rollout, verify the deployed revision, old redirects, deep-link refresh, access behavior, search, assets and representative reader journeys. Reverting host rules or deploying an older artifact is also a production change requiring approval.