Jacob McKenzieProjectsEmail
Engineering case study · independently built and operated

Make boot media repeatable and reviewable.

Harvest Boot connects an existing image library to release downloads, Ventoy profiles, and QEMU boot tests. I built it to keep the image, its metadata, and the intended USB contents in one workflow.

Python · Flask · SQLiteQEMU · noVNC · VentoySingle-user, self-hosted
Try the Library tourProduct overview
Actual Harvest Boot Library template rendered with an isolated sample database
Actual application renderer with synthetic records in an isolated database. The public interactive tour is a separate, limited recreation.

The problem

A folder of images does not explain which versions are current, whether a checksum was verified, or what belongs on a rescue USB. Preparing the drive and testing it are separate steps that benefit from a shared record.

My responsibility

I built the library workflow, download integration, Ventoy profile and sync tooling, and browser-facing VM features for use on my own infrastructure.

Architecture

  1. LibraryFlask presents image metadata stored in SQLite.
  2. SourcesScheduled release checks feed a download queue.
  3. ProfilesVentoy selections produce a preview and tracked sync.
  4. TestingQEMU launches images; noVNC exposes the console.

Decisions and tradeoffs

DecisionReason and tradeoff
Keep image files separate from application stateScanning an existing library need not rename or move it. Metadata must account for files that disappear from disk.
Separate computed and expected checksumsA computed digest alone cannot establish a match to an upstream digest. Missing expected values and mismatches remain visible.
Preview sync and track a manifestNamed profiles make selections repeatable, while previews make additions and removals reviewable before changing a USB.
Use QEMU and a browser consoleBoot testing fits the same workspace. A VM test still does not guarantee identical behavior on physical hardware.
Target a single-user home serverThe project can integrate closely with local storage and devices. It is not presented as a multi-tenant provisioning service.

Validation and current outcome

The public tour is checked for filtering, sorting, expansion, density switching, and small-screen behavior. Its screenshot is produced by the actual application renderer with sample records. Those checks verify presentation; they do not exercise USB writes or VM boot operations.

The working application provides library management, profile-based USB preparation, and boot testing in one browser workspace. It is an active personal project with an evolving API.

What this demonstrates

Connecting filesystem state to a database and UI, making destructive changes reviewable, and keeping a clear boundary between a browser demonstration and device operations.