Deployment and Operations

This page is for technical evaluators who want to know how the product is operated before trusting it with their site data.

Ship pipeline

A change reaches production through one path:

1. Branch and change.
2. typecheck · strict TypeScript, zero errors.
3. lint · ESLint with Next.js core rules.
4. guard:no-fixture · a build-failing guard that scans for simulated or mock data reaching a report surface.
5. Full test suite · unit, integration, and contract tests.
6. Merge to main · automatic production deployment follows.

The zero-fixture guard is the operational teeth of the truth-first philosophy: a change that would render simulated data does not deploy.

Deploys and rollbacks

• Production deploys are atomic and automatic on merge.
• Incident protocol: roll back to the last known-good deployment first, then investigate. Bleeding stops before debugging starts.
• A health endpoint reports the running release, so any served page can be tied to the exact commit that built it. Verification of a deploy compares the live release against the merged branch.

Runtime surface

• /api/health · liveness plus the running release identifier.
• /docs/sitemap-docs.xml · this documentation's sitemap, referenced from the main robots.txt.
• llms.txt and llms-full.txt · machine-readable docs, generated per page.

Data operations

• Database changes ship as versioned migrations with a hygiene check for unique version stamps.
• Row-Level Security is a migration invariant: every new customer table must enable and force RLS with tenant-scoped policies, or the change does not merge.
• Account export and deletion are self-serve and tested; see Data control.

What we deliberately do not run

• No third-party analytics scripts that leak your browsing to ad networks.
• No customer-data resale, ever.
• No simulated metrics in any report, enforced by the build guard above.

Questions about operations, uptime, or a security review for your procurement process: hubseo.dev/contact.