Self-hosted · boot media workbench

Keep the right images.
Know what you’re booting.

A folder of ISOs rots quietly: versions fall behind, downloads half-finish, and the USB stick in the drawer holds last year’s installer. Harvest Boot watches the upstreams, verifies what it fetches, syncs the drive from a profile you can review, and boots any image in a VM before you trust it.

Try the library demo ↓ Architecture & decisions What it won’t do

Python · Flask · SQLite · QEMU · Ventoy · noVNC · rootless Podman

Upstreams: 32 tracked, all resolving
Checksums: 28 of 32 publish one, read on every check
Resolvers: Mirror index, dated directory, GitHub release
Boot test: QEMU · KVM · BIOS or UEFI · noVNC console
USB: Ventoy profiles with dry-run preview
Netboot: iPXE menus exported from the same library
Runs as: Rootless Podman container behind SSO
Tests: 1,718 offline, green in CI

The library

Images grouped by family, with the awkward facts on the card.

A scan walks the library root and records every image it finds: version, variant, architecture, size, and what its checksum says. Families collapse into one card, so a shelf of thirty distributions reads as thirty lines rather than three hundred files — and the card carries the counts you actually care about, including the ones that are missing from disk or no longer match their published hash.

The library view: distribution families as cards with latest version, image count and size, each marked with how many images verified, are unscanned, or are missing. — The application’s own library view, rendered against an invented database. Every screenshot on this page is the real interface; none of them is this machine’s library.

Verified, unscanned, missing, mismatched

Four states, shown per image and summed per family. A mismatch is loud on purpose: it means the bytes on disk stopped agreeing with the hash the project published.

Metadata you can correct

Version, variant, architecture, release date and product key are editable in bulk, because filename conventions never survive contact with a real collection.

Duplicates and strays

Finds images that exist twice under different names, and entries whose file has gone, so the library and the disk can be reconciled deliberately.

Upstream tracking

Thirty-two upstreams, checked on a schedule.

Each source knows how to find the current release for one distribution: where the mirror is, which file is the image, and where the checksum lives. A scheduled check asks all of them and records what it finds, so “is there a newer Debian?” stops being a browser tab.

The repos view: configured upstream sources as cards, each showing its resolver type, target library folder, latest discovered version, and buttons to test the source or download the latest image. — The shipped catalogue, as the app renders it. A source is one row of configuration, so adding your own is the same shape as the ones that come with it.

Walk the mirror index

The common case: read the directory listing, pick the image by pattern, read the checksum file beside it. Ubuntu, Debian, Arch, Fedora, openSUSE and twenty others.

Descend a dated directory

CachyOS publishes /ISO/desktop/260809/ and Tails a folder per version. The resolver picks the newest directory first, then the image inside it.

Read a GitHub release

Rescue images often ship only as release assets. The resolver takes the latest release, picks the asset by pattern, and reads a checksum asset when the project publishes one.

Ordering is by the date in the filename, not alphabetical. EndeavourOS names its images after codenames and spells its own prefix two different ways — sorted as text, the newest image is a 2023 one.

Every source in the catalogue

Linux

BSD

FreeBSD 14
GhostBSD
NetBSD 10
OpenBSD 7

Tools

Clonezilla Live
Rescuezilla
ShredOS

Downloads

Fetched in the background, verified on arrival.

Queue a release and a worker fetches it into the right folder, then hashes it and compares against the checksum the project published. A download that does not match is a failure, not a file you discover is bad six months later when a machine will not boot.

The downloads view: an active queue above a collapsible history of completed and failed jobs, each with the release, size and progress. — Active jobs sit above the history; repeated retry-and-fail cycles collapse to one entry per release so a flaky mirror cannot bury the rest.

Ventoy

A USB you can review before it is written.

A profile is a named selection of images with a layout and a target drive. Sync previews the exact adds, updates and removals first, and every file it writes is recorded in a manifest — so the drive can be pruned later without guessing which files the app put there and which you did.

A profile is the unit you review: Preview lists the changes, Sync makes them. Drives are identified by UUID, not mount path, so the same stick is the same stick after a reboot.

Presets

Eleven built-in selections — latest of everything, rescue tools, Windows current, Raspberry Pi, minimal — as a starting point rather than a hand-picked list.

Dry run first

The preview is the same code path as the sync, so what it lists is what will happen.

Themed

Per-profile Ventoy theme and wallpaper, written alongside the images.

Boot testing

Boot it before you trust it, in the browser.

Any image in the library launches as a QEMU virtual machine with KVM, BIOS or UEFI firmware, and a console you drive from the browser over noVNC. The stick itself can be booted too: the physical drive is attached read-only, through a snapshot, so a test cannot write to the media you are about to rely on.

The VMs view: a launch form with an ISO picker, resource presets from lightweight to maximum, RAM, CPU cores, a temporary disk, display and network options, above the running and saved machine lists. — KVM is used automatically when the host has it. Saved configurations keep a persistent disk, so a half-finished installation survives to the next session.

The emulator is chosen from the image’s architecture, so an aarch64 image boots under qemu-system-aarch64 rather than failing confusingly on x86.

Netboot

iPXE menus, generated from the same library.

The library doubles as a netboot menu: entries are exported as iPXE scripts a machine can chain-load, so a bare machine on the LAN can install from the same images the drawer stick carries. Any entry can be tried first in a throwaway VM that netboots it, so a broken recipe fails on screen rather than on real hardware.

The netboot view: menu counts, a VM test lab showing the iPXE ROM ready and the guest URL, filters by recipe type, and a recommended Arch Linux netboot entry with a Test VM button. — The test lab boots a menu item in QEMU through the same iPXE path real hardware takes, fetching from the app over the emulator’s gateway.

A booting machine has no browser session, so those two endpoints answer without a login — on the LAN only. Reached through the public address they redirect to sign-in, because otherwise they enumerate the whole library and the internal address with it.

Interactive

Explore the library the way the app organises it.

A sample-data recreation of Harvest Boot’s library view. Filter by platform or checksum state, expand a family, and inspect its images. Scans, uploads and edits belong to the installed app and are not wired up here.

How it runs

One container, one worker, no cloud.

It runs as a rootless Podman container on a home server: the image carries the dependencies, the checkout is mounted read-only, and a deploy is a pull and a restart. Sign-in is OIDC against a self-hosted Authentik; the public address is a Cloudflare tunnel to a local reverse proxy. State is one SQLite file and the image folder — both plain enough to back up and to walk away from.

What the container is allowed to touch, and the feature that needs it.
Opening	Why it exists
KVM device	Boot tests run at native speed instead of emulating a CPU.
Live device tree	A USB stick plugged in after the container started still appears, which is what booting the physical drive requires.
Removable mounts	Ventoy sync writes to the drive where the desktop mounted it.
Host networking	Each VM console gets its own port, and netboot guests reach the app through the emulator’s gateway.
One display socket	“Open in native viewer” draws on the desktop. Only that socket is passed in, never the rest of the session.

Limits

What it won’t do, and why.

Nine popular distributions have no source in the catalogue, because there is nothing dependable to point at. They are listed in the code with the reason rather than quietly omitted, so the gap reads as a decision.

Checked on 20 September 2026; each is revisited when the upstream changes.
Distribution	Why there is no source
Pop!_OS	The image host answers 403 to anything that is not a browser.
Manjaro	Downloads go through a redirect page; there is no index to walk.
Zorin OS	Per-release CDN links, with no listing to discover them from.
elementary OS	The download is a form submission behind a pay-what-you-want page.
Nobara	The download host did not resolve when the catalogue was built.
Bazzite	Ships as container images; the release carries no ISO to fetch.
NixOS	The channel URL redirects to a build, with no index behind it.
MX Linux	The published mirror path lists no images.
Raspberry Pi OS	Compressed card images rather than ISOs, which this app does not track.

NetBSD resolves without a checksum on purpose: it publishes SHA-512, and the download path records every checksum as SHA-256, so storing it would guarantee a false mismatch. Multi-algorithm support is its own piece of work, not a line of configuration.

Keep the right images.Know what you’re booting.