BootProof Wants to Replace the README's "It Works on My Machine" With a Signed Receipt

Anyone who has cloned a promising-looking repository and burned an afternoon on dependency errors knows the gap between a project that claims to run and one that demonstrably does. BootProof is a command-line tool built around that gap. Its pitch fits in a single line from the project itself: "The honest Run Button for repos, with proof, not vibes."

The core idea is narrow and, refreshingly, self-limiting. You point BootProof at a repository, it inspects the code, builds an evidence-based plan for how to install and start the application, runs only the steps it can justify, watches for an HTTP health signal, and then writes a signed record of what actually happened. If it never observes a live service answering on a port, there is no success. As the documentation puts it bluntly, "No proof, no green check."

The problem it actually solves

Most tooling in this space optimizes for making things appear to work. CI badges go green, quickstart scripts exit zero, and a reader assumes the project boots. BootProof inverts that incentive. It distinguishes diagnosis from proof, and it will happily tell you a run failed while still giving you something useful.

Consider one of its sample failure messages. When a repository declares it needs pnpm 10.24.0 but the environment has 9.15.4, BootProof refuses the install rather than pushing through and hoping. It reports the exact mismatch, explains why an install with the wrong package manager version cannot be trusted, and hands back a concrete next step: run corepack enable && corepack prepare [email protected] --activate, then try again. The failure is classified, not vague. That is the difference between a tool that wastes your time and one that saves it.

One engine, two audiences

BootProof runs the same logic for humans and machines, which is a smart structural choice. A developer types bootproof up . and gets a diagnosis plus a runbook. An automated pipeline types bootproof up . --ci --json and gets a single deterministic JSON object on stdout conforming to a bootproof/result/v1 schema, plus an exit code that means exactly one thing.

The exit code contract is strict. Zero requires both booted === true and healthVerified === true. Everything else, every refusal, ambiguity, install failure, service failure, or health timeout, returns one. There is no partial credit. The JSON payload carries fields like booted, healthVerified, failureClass, and a path to the attestation file, so a build system can branch on the verdict without parsing prose.

The honesty contract

The most interesting part of the project is a section literally titled the Honesty Contract, a list of things BootProof promises never to do. It will not render success for skipped steps. It will not invent secrets. It will not write to .env, .env.local, .env.development, or .env.production. It will not silently patch your project, guess a workspace when a monorepo is ambiguous, or claim generated scaffolding exists unless it was actually written. It signs failed attestations, not just successful ones, and it uploads no telemetry.

That last cluster of constraints is doing real work. A tool that executes arbitrary repository code is a security surface, and BootProof treats it that way. Point it at a remote GitHub URL and it clones the repo credential-free over HTTPS, inspects the contents, and then stops. It refuses to execute remote code until you explicitly acknowledge the risk with --provider local --unsafe-local, and dependency installation with its lifecycle scripts only runs when you add --install on purpose. Remote --dry-run is rejected before cloning even starts, on the logic that a dry run promises to write nothing and cloning writes something. The reasoning is consistent all the way down.

What it can and cannot do yet

BootProof is candid that detection is broader than orchestration, which is a distinction more projects should make. It can recognize Python/Flask/React/Celery stacks, Go and Node hybrids, Docker service dependencies, and monorepo candidates. Recognizing them is not the same as claiming it can fully run them. A Superset-like Flask repo gets detected and then honestly refused with a python_flask_setup_required classification. A Grafana-like Go/Node hybrid is detected without pretending that a frontend file watcher constitutes the whole application. Parallel monorepo root commands are refused until you select a specific workspace.

The attestations themselves are signed with Ed25519 and currently carry a trust level of local_developer_signed. The project does not oversell this. Local attestations are described as useful evidence, while CI and OIDC-backed signing, which would constitute stronger supply-chain proof, is reserved as a future ci_oidc_signed level that is explicitly not emitted today. A Git-native registry and an OIDC trust model are listed as designs in progress, not deployed services.

Why it is worth watching

The market positioning here is unusual because the product refuses to expand to fill the space around it. BootProof states plainly what it is not: not a deployment platform, not a general CI replacement, not a magic environment fixer. In a category crowded with tools that promise to make everything work, a tool whose main feature is a principled refusal to lie about what works is a genuine contrast.

There is no funding announcement attached to this, no investor list, no valuation. It is an Apache-2.0 licensed, early-alpha project from a single developer, installable today via npx bootproof up .. Whether it grows into the proof-linked badges and verified public index its roadmap describes is an open question, and the near-term work, broader Python and Go support, stronger multi-service orchestration, and additional remote providers, is substantial.

The bet underneath BootProof is that verifiable evidence is more valuable than optimistic green checkmarks, for both the human reading a runbook and the pipeline reading an exit code. That is a reasonable bet. The interesting test will be whether enough developers want honest failure badly enough to adopt a tool that, by design, refuses to turn every repository green. You can read the full design notes, including the failure taxonomy and the honesty contract, in the repository documentation.