BuildMender website: run, test and deploy

The product website uses dataops-platform / FlowSentra as a reference for content depth, platform exploration, operator guides and static deployment separation. It presents BuildMender's implemented CI failure resolution loop, with explicit release and validation boundaries.

The display brand is BuildMender. Existing ci-resolve package names, CLI commands, environment variables, private files, SQLite data and repair branch prefixes remain compatible. This change does not migrate runtime state or credentials.

1. What is included

• Responsive desktop and mobile product website.
• Illustrated example of a failed run and its repair stages; all example data is labeled illustrative.
• Four accessible platform tabs: Collect, Reproduce, Repair and Reconcile.
• Five-stage workflow explorer with required evidence and stop conditions.
• Test protection, disposable execution and native GitHub policy explanations.
• Setup commands with a clipboard action and a useful fallback when clipboard access is unavailable.
• Implemented release versus enterprise research comparison.
• Browser-readable operating, architecture, research, validation, naming and website guides.
• Downloadable Markdown for each approved guide.
• FAQ disclosures and mobile navigation.
• Dependency-free, allowlisted standalone static export.

There are no account, billing, contact-submission or live demo integrations on this website. The illustrated run is not connected to GitHub. Live repair requires running and configuring the application separately.

2. Run with the local application

From the project checkout:

node --version
npm start

Use Node.js 24 or newer. The normal local addresses are:

When .private/automation.json exists, starting the app also starts configured collection and workers. Website viewing alone does not configure automation or grant credentials. For a preview without live automation, follow the run and test guide.

The local server retains its loopback binding, host validation, restrictive content security policy and existing API mutation controls. Guide routes serve only explicitly registered documentation, not arbitrary files.

3. Build the standalone website

npm run website:build

The build creates website/, which is Git-ignored and regenerated from committed sources. No installation, framework bundler, GitHub credentials, model access, Docker or database is needed for this build.

The output contains:

• index.html, website.css, website.js, mark.svg.
• HTML and Markdown versions of six approved guides under guides/.
• A real 404.html explaining the website/application separation.
• _headers, _redirects and robots.txt.
• An ownership marker, .buildmender-website.json, used by the builder.

Only reviewed website assets and registered documentation are copied. Application scripts, API handlers, .private/, .data/, dependencies and Git metadata are excluded. The public guide export replaces this checkout's absolute path with /path/to/ci-resolve.

Do not upload public/ as the standalone website. It also contains the workbench shell, which depends on the local application backend.

On the standalone website, workbench links become Run BuildMender locally links to the operating guide. No attempt is made to call the application API or open a visitor's loopback service.

The builder refuses to overwrite an existing website/ folder unless it carries the expected ownership marker. It also rejects symlinked input files. If an unrelated folder already uses that name, move it to a different location before building; do not delete it without inspecting its contents.

4. Preview the generated website

Run the build, then use a static file server. For example, if Python 3 is installed:

python3 -m http.server 4320 --bind 127.0.0.1 --directory website

Open http://127.0.0.1:4320/ and check the site. Stop the server with Ctrl+C.

This server is a local preview. It does not interpret deployment-specific _headers or _redirects, and it uses its own missing-page response. The automated static browser test supplies the intended CSP and custom 404 behavior explicitly. Configure the equivalent headers and redirects on hosts that do not understand those files.

Clipboard access requires a browser-supported secure context. The Copy button reports a fallback instruction if the browser denies clipboard access. It never claims a copy succeeded after a failed clipboard call.

5. Automated verification

npm run check
npm run test:website
npm test

npm run test:website validates:

1. Repeatable static builds.
2. Exclusion of app/backend/private runtime inputs.
3. All generated local links, fragment targets and assets.
4. Safe refusal to replace an unrelated output folder.
5. Rejection of symlinked public input files.
6. Escaping of raw HTML and rejection of unsafe link schemes.
7. Strict guide-route allowlisting and workstation-path redaction.

The full suite adds local HTTP checks, all existing application and automation checks, and browser checks when configured.

To enable browser verification, use Python with Playwright and Chromium installed. Set CI_RESOLVE_BROWSER_PYTHON to that Python executable or put its absolute path in .private/browser-python; see browser setup. Browser tests explicitly skip when no interpreter is configured.

Browser coverage includes:

• Desktop/mobile website layout and overflow.
• Mobile menu navigation and automatic close.
• Platform tab mouse, arrow-key, Home and End navigation.
• Workflow evidence and stop-condition changes.
• FAQ disclosures and clipboard success/fallback feedback.
• Local application navigation and existing investigation workflows.
• Operating guide navigation and mobile guide layout.
• Standalone website without the application backend.
• Markdown download and all six guides on mobile.
• No failed asset requests, external requests or application API requests from the static website.

Screenshots are generated under ignored artifacts/, including website-desktop.png, website-mobile.png, guide-desktop.png, guide-mobile.png, static-website-desktop.png and static-website-mobile.png. Review them at readable scale after visual changes.

Passing these checks does not establish live repair-model success, production GitHub permissions, Docker runtime availability or a hosted repair service.

6. Deploy to a static host

For a Git-connected static host, use:

If the application lives inside a larger repository, set the build root to the actual application directory. For manual upload, build locally and upload the contents of website/.

Do not use npm start as a static hosting build command. The Node automation service and private state run on a separate controlled host. Do not upload application credentials to the static host.

The _headers file declares a restrictive CSP, denied framing, no content-type sniffing and disabled camera/microphone/geolocation permissions. _redirects sends old /app links to setup documentation. Host support for these configuration files varies; verify equivalent behavior on the selected host.

A new Sites registration was prepared during website work, but no deployment is claimed. Repository pushes and publication are left to the owner as requested. The authoritative website source is in this application repository; npm run website:build regenerates the deployable artifact.

7. Verify after deployment

• / shows BuildMender and the product website rather than an application login or JSON error.
• Platform tabs, stage buttons, FAQ disclosures and the mobile menu work.
• Every main navigation anchor scrolls to an existing section.
• All six guide pages load and their Markdown downloads work.
• Workbench calls to action lead to setup guidance on the static deployment.
• The browser Network panel contains no application API calls, model calls or unexpected external requests.
• Unknown paths and /api/health return an HTTP 404 rather than a successful homepage fallback.
• /app bookmarks follow the configured setup-guide redirect.
• Response headers contain the intended CSP and framing controls.
• Desktop and narrow mobile screens have no horizontal overflow or touching actions.

If a host defaults to SPA fallback, configure the custom 404 behavior; this is a static documentation website, not a client-routed application.

8. Editing and maintenance

The Markdown renderer supports headings, paragraphs, code fences, lists, tables, blockquotes, bold, inline code and approved links. Raw HTML is escaped. Mermaid fences display as readable source; no third-party script is loaded to execute them. Complex Markdown extensions are not supported.

To add a guide, register its filename, HTML page name and label in websiteGuides, add a reviewed Markdown source and link it from the website. Rebuild and run link, route and browser checks. Maintain the explicit output allowlist rather than copying whole directories into the published artifact.

After changes, run the checks and static build, inspect desktop/mobile screenshots, commit with a conventional commit message, and push main when ready:

git push -u origin main

GitHub push is intentionally performed by the repository owner in this workflow.

Explore all guides · Back to top