Hosting direction

Maintainer HQ ships as a local-first Node.js application. Its CLI, loopback dashboard, and stdio MCP server work without a hosted account, remote database, or browser-visible secret. Hosting is an extension of those same domain contracts, not a separate product model.

Documentation deployment

This documentation is a static VitePress artifact served by an assets-only Cloudflare Worker. The deployment has no Worker script, runtime binding, application credential, analytics tag, or remote browser asset. A dedicated documentation GitHub environment holds deployment authority outside the repository. Deployment-level controls prevent account-wide analytics or other browser assets from being injected at the canonical origin.

The verification workflow builds once, checks the artifact, stamps the exact source revision, validates the Worker configuration, and uploads that artifact. The deployment job downloads the verified artifact rather than rebuilding it, publishes through Wrangler, and then requires the canonical HTTPS origin to return the same revision marker. Its browser-shaped live request also rejects deployment-layer remote assets, including an accidentally re-enabled analytics beacon.

Publishing the canonical site is not part of contributor bootstrap. A fork must configure its own Worker name, origin, protected environment, credentials, routes, and equivalent privacy controls before enabling the publication workflow. Account-specific recovery procedures stay in the deployment operator's private infrastructure runbook.

npm run docs:build
npm run docs:check
npm run deploy:docs:dry-run
npm run docs:preview

Future application runtime

A Cloudflare Workers deployment can replace the local adapters while preserving workspace-scoped project, activity, plan, apply, verification, and recovery operations.

Local adapter	Hosted seam
Private atomic JSON files	Durable workspace storage with revision and concurrency control
Local Git and authenticated gh reads	Bounded GitHub API transport scoped to enrolled repositories
Loopback session capability	Validated request identity plus explicit workspace authorization
Process-local confirmation state	Short-lived authenticated plan state bound to method and workspace
Local actor ID	Verified external subject mapped to an operator role

Cloudflare Access can provide the upstream authentication gate. It is not, by itself, application authorization. A hosted adapter must validate the Access assertion, resolve an allowed workspace, and authorize the exact read or mutation before constructing the same bounded service used locally. Ambient identity headers, request-selected workspace IDs, and authentication without operation authority remain insufficient.

Deployment boundaries

The public documentation Worker and a future application Worker remain separate. That keeps documentation cacheable and credential-free while allowing the application to use Cloudflare Access, durable storage, provider bindings, and stricter response policy without expanding the static site's authority.

A hosted application must retain these invariants:

• Central workspace and activity records never appear in logs, static assets, URLs, or client-side persistence
• Browser and MCP callers receive only bounded projections and purpose-built operations
• Every write remains revision-bound, exactly planned, separately confirmed where provider authority applies, and verified after execution
• Provider reads and writes stay allowlisted and scoped to recorded project or repository identities
• Authentication, workspace membership, and operation authorization are distinct checks
• Local operation remains supported without a hosted dependency