Skip to content
BreachPilot

Releases

Stable by default, edge when you ask

The hosted installers pin a stable tag, never a moving branch. The version below is derived from the upstream repository at build time, and the full history lives on GitHub.

v0.49.2v0.68.4 packageApache-2.0Commit b942b9a5994f
Release notes for v0.49.2Install guideFull history on GitHub

For authorized testing only. Run BreachPilot only against systems you own or have explicit permission to test.

Latest stable tag

v0.49.2

Pinned by the hosted installers, never a moving branch.

Package version

v0.68.4

From upstream pyproject.toml at build time.

Built from commit

b942b9a5994f

Stale metadata. Upstream checkout was missing at build.

Channels

Install a channel

Stable is the default and the only supported choice for assessments. Edge tracks the main tip and moves under you. Contributors only.

Stable (default)

pinned stable install
curl -fsSL https://breachpilot.dev/install.sh | bash -s -- --version v0.49.2

Resolves the newest v* tag and checks it out detached, with no branch movement. Omit --version to take the latest tag automatically.

Edge (main)

edge install
curl -fsSL https://breachpilot.dev/install.sh | bash -s -- --channel edge

Tracks main tip. Moves under you. Only for contributors testing unreleased work. Never use edge for an assessment you need to reproduce.

Timeline

How a release ships

No hand-kept changelog on this page. Tags, notes, and history are published upstream on GitHub, and this page points at them.

  1. Stable tag is cut upstream

    Maintainers cut a versioned tag in the upstream repository. The tag is the release. There is no separate binary channel to drift from.

  2. Hosted installers pin the tag

    The install scripts resolve the newest tag and check it out detached. Omitting the version flag takes the latest tag automatically; nothing ever follows a moving branch unless you ask for edge.

  3. You verify what landed

    Every install prints the exact ref and commit SHA it checked out, so the running tree can be matched back to the published release notes before first run.

  4. You upgrade by re-pinning

    Upgrades are the same pinned command with the new tag. Back up config first, re-pin, verify the SHA, then restart the WebUI.

Upgrade notes

Upgrade without surprises

Upgrading is re-pinning to the new tag, then restarting the WebUI (default port 8765). Read the notes first. Breaking changes are announced there, not here.

  1. Read the release notes for the target tag, checking for breaking config or WebUI changes.
  2. Back up your config directory (for example, C:\BreachPilot\config) so you can roll back.
  3. Re-run the pinned stable install with the new tag. Never switch an install to a moving branch to upgrade.
  4. Confirm the printed ref and commit SHA match the published notes, then restart the WebUI.
upgrade to v0.49.2
curl -fsSL https://breachpilot.dev/install.sh | bash -s -- --version v0.49.2

Replace v0.49.2 with the target tag from the GitHub releases history. If the new WebUI does not come up, confirm nothing else is bound to port 8765 before retrying.

Trust

Verify what you installed

checksum-pinned install
BREACHPILOT_SHA256=<expected> bash install.sh --version v0.49.2

Every install prints the exact ref and commit SHA. Hard checksum verification needs the upstream repository to publish SHA256SUMS per release tag. Until then, pin with BREACHPILOT_SHA256. See the installer header for the full upstream requirement.

Never miss a release

Watch the upstream repository for releases only. Security fixes ship as stable tags.

Watch on GitHub