Release Notes

• 1: Farrow 0.8.0: clearer recovery and refreshed images
• 2: Farrow 0.7.0: simpler test labs and automatic recovery
• 3: Farrow 0.6.0: Ubuntu 24.04 and smoother local labs
• 4: Farrow 0.4.0: one command, working data disks, one voice
• 5: Farrow 0.5.0: explicit disposal, explicit repositories, reproducible images
• 6: Farrow 0.3.0: explicit catalogs and actionable readiness
• 7: Farrow 0.2.0: selected convergence and release integrity
• 8: RC6 development candidate: owner-scoped Tier-1 delivery
• 9: Development snapshot: the Go 1.27 product surface

1 - Farrow 0.8.0: clearer recovery and refreshed images

Farrow 0.8.0 reduces manual work after interrupted setup and partial VM starts. It also refreshes the Debian and Ubuntu images while retaining every previous Catalog artifact and the identity of existing VMs.

What changed

• Host preparation follows the command. Interactive start, restart, and reload can prepare missing host tools and restore an intact Farrow network. On macOS, new network installation completes Homebrew discovery/installation or the verified archive download before requesting administrator authentication, so Homebrew cannot invalidate a credential acquired too early.
• A failed node does not block independent peers. A missing host share fails its own node during up or start; stopped peers can still start when a new node fails to prepare. Errors name the source and mount, and Farrow does not create an empty replacement. Restart/reload/recreate check share access before stopping existing VMs.
• Recovery preserves identity. A missing public key is derived from the original private key. A lost private key produces backup-recovery guidance instead of a new login identity. macOS vmnet log-directory recovery retains network ownership evidence and avoids false subnet-conflict reports.
• Failures keep their context. Scoped retry commands preserve the inventory, repository, and applicable flags; a start retry remains start. Setup and its retry share one operation ID, and bounded event logs work before deployment state exists. Uncached image information no longer requires QEMU.
• Cleanup reports the final result. Explicit persistent-disk deletion and purge no longer describe disks as both retained and deleted. Owned disks left by a previously removed node do not block destruction of the remaining lab.

September images

Embedded Catalog 2026092001 contains 37 artifacts across nine families, including all 27 previous artifacts. These new stable versions cover amd64 and arm64:

Debian keeps the offline XFS tools and generated en_US.UTF-8 locale, with C.UTF-8 as the default. Ubuntu keeps Canonical’s original image bytes; deployment accounts and networking are configured by cloud-init. Existing VMs and explicitly pinned image versions keep their original bases. See Images for repository and update behavior.

Install or upgrade

curl -fLO https://github.com/pgsty/farrow/releases/download/v0.8.0/install.sh
chmod +x install.sh
FARROW_VERSION=0.8.0 ./install.sh
export PATH="$HOME/.local/bin:$PATH"
farrow version

For an existing lab, review farrow plan and then run farrow up from its inventory directory. On first use, run farrow up in a terminal to prepare the host and create the default lab.

Farrow remains pre-1.0 and uses GitHub’s pre-release channel; keep the explicit FARROW_VERSION. The release includes macOS/Linux amd64/arm64 archives, Linux DEB/RPM packages, checksums, SBOMs, the installer, and a Homebrew formula. Other installation methods are in the Quick Start.

start still powers on existing nodes; up applies the inventory and retries unfinished guest setup. No separate repair command is required. The existing test-data reset policy is unchanged: confirmed unusable test filesystems can be cleared, including persistent data disks, with an explicit data-loss notice. Missing devices, failed probes, busy mounts, or host I/O errors do not authorize formatting; root disks and host shares stay outside that recovery path.

Validation and limits

Four hosts completed the seven-system pro path: two macOS arm64/HVF hosts and two Linux amd64/KVM hosts, each with Rocky Linux 9.8/10.2, Debian 12.15/13.7, and Ubuntu 22.04.5/24.04.5/26.04.1. The baseline candidate 6d7870e performed clean initialization from the LAN repository. Runtime candidate 1c054a0 then passed in-place installation, healthy repeated up, stop/start, two rounds of guest SSH, data-disk access, Ansible configuration reads, and control-node SSH. Both Macs also passed Ansible ping on all seven nodes. VM UUIDs, image identities, and healthy root/data disk paths and inodes were retained. The temporary acceptance VMs were subsequently cleaned up.

The following are single measurements, not a performance distribution. The first up includes image download:

The release tag points to 320a32afa8f6fca02592215aa0d5607ca4e852b2, which changes only README and release notes relative to the tested runtime. Complete local make check and release archive/package verification passed. The source CI, independent packaging snapshot, and tag workflow all passed; the tag workflow produced 20 release assets, including 19 checksummed payloads. The release is public on GitHub’s pre-release channel. All 20 anonymous downloads returned HTTP 200; their full SHA-256 digests match the GitHub API and inspected draft, and all 19 payloads match checksums.txt.

The UX audit and image refresh record preserve the earlier regression, image-boot, and upgrade evidence.

Both official image repositories serve the same signed Catalog as the release. An isolated farrow update against each endpoint verified its signature and activated revision 2026092001. All ten new image objects at each endpoint returned HTTP 200 with matching content lengths; this was not a fresh full-body hash check of every public qcow2.

The public installer completed isolated user-directory installations on macOS arm64 and Linux amd64. Both CLIs reported 0.8.0 / 320a32a, and the installed CLI/helper bytes matched their verified public archives. The Linux download used a temporary SSH loopback forward to the existing proxy, removed afterward. Default installations and VM/network state were unchanged. These checks verify binary delivery; fresh host setup and VM boot through the public installer remain untested.

The Homebrew tap update provides 0.8.0 with all four archive checksums matching the public release. Local formula checks, strict online audit, and native arm64 brew fetch passed. Homebrew CI also passed its metadata, updater, style, platform, and audit checks on macOS and Linux. No new Homebrew install, upgrade, or brew test was performed.

This is a clean 6d baseline followed by a 1c lifecycle replay, not a second clean initialization at 1c. The Homebrew authentication-order regression fails before the fix and passes after it; its fresh formula-install path was not replayed natively after the fix. Native macOS setup used the verified LAN backend archive. Physical-host reboot, a complete Pigsty installation, and native macOS amd64 or Linux arm64 operation remain outside this run.

macOS directory sharing remains unavailable with the tested QEMU directory descriptor behavior. The new preflight improves diagnosis; it does not add sharing support. The pro inventory used no host shares. A missing control-node guest private key is now reported even if an old ready marker exists, but automatic private-key reinjection is still not implemented. Management SSH can remain usable while peer SSH carries that limitation. See Status for the full dated matrix.

2 - Farrow 0.7.0: simpler test labs and automatic recovery

Farrow 0.7.0 makes local test labs easier to start and recover. Repeat farrow up to finish interrupted work, retry incomplete guest setup, and refresh older guest helpers without restarting running VMs.

What changed

• A shorter first run. Interactive up can create the default inventory, prepare missing host tools, and restore an intact inactive Farrow network. Short checks stay quiet; long work shows progress and a compact final result.
• Usable guests stay available. Data disks, shares, guest hostnames, node-to-node SSH, and private networking initialize independently. Optional failures report specific limitations while working management SSH remains available. Healthy stages are skipped on subsequent up calls.
• Test disks recover automatically. Working filesystems are reused; unrecognized or confirmed damaged filesystems are reset and mounted again. The result explicitly reports discarded data. Probe errors, missing devices, busy mounts, and backend I/O errors do not trigger formatting.
• Fewer manual fixes. Unwritable shares fall back to read-only and retry after permissions are corrected. Occupied automatic SSH ports are reassigned for stopped guests. Interrupted image transfers resume, and official repositories can fail over without bypassing digest verification.
• Clearer output and state. Successful commands show a short summary; limitations are grouped, and JSON/YAML keep structured results. Guest warnings use a disposable cache outside the schema-2 VM documents and node artifact directories, so older releases can still read and manage the deployment.

Upgrade notes

Data disks are disposable test storage. up may clear a damaged filesystem, including one marked persistent. Persistence retains a disk across VM destroy/recreate; it does not preserve corrupt filesystem contents during recovery. Keep valuable data outside these test disks. Root disks and host shared directories are not reset by this recovery.

There is no separate repair command. Repeating up performs recovery; start continues to power on existing nodes without applying an inventory. --no-wait skips readiness and these guest recovery checks.

A usable guest with optional limitations returns exit 0. Automation that needs all configured features must inspect nodes[].warnings in JSON/YAML. Recovery actions, including data resets, appear in nodes[].repairs. Downgrading the CLI does not restore discarded data or revert installed guest helpers.

A pre-existing 0.6.0 bootstrap failure can already have deleted the staged control-node SSH key before installing it. up restores management access and independent setup, but reports control-ssh if that key is missing. It does not reinject private keys during an in-place retry. After reviewing disk effects with farrow plan, explicitly recreate the affected control node if peer SSH is needed.

Install or upgrade

curl -fLO https://github.com/pgsty/farrow/releases/download/v0.7.0/install.sh
chmod +x install.sh
FARROW_VERSION=0.7.0 ./install.sh
farrow version
farrow up

The release includes macOS/Linux amd64/arm64 archives, Linux DEB/RPM packages, the installer, checksums, SBOMs, and a Homebrew formula. It follows the existing pre-1.0 GitHub pre-release policy; specify FARROW_VERSION when installing.

Validation

The release commit is 9c6d4896d93733d1cb60a7e5d8591e9a06659c9d. It passed the source CI and the independent packaging snapshot before tagging. The tag workflow repeated the gates and produced 20 release assets: 19 checksummed payloads plus the checksum manifest. All 20 assets downloaded anonymously with HTTP 200 and matched the inspected bytes.

The public macOS arm64 and Linux amd64 installers installed the exact archive binaries and reported version 0.7.0 with this commit. On Ubuntu 26.04 amd64 with KVM/QEMU 10.2.1 and Ubuntu 24.04 guests, the recovery matrix exercised ext4/XFS corruption, retained disks, failed probes, busy mounts, read-only share fallback, and repeated healthy up without replacing the VM process. A public 0.6.0 bootstrap that failed its management-egress probe was resumed by 0.7.0 in 3.3 seconds; the existing data disk and UUID survived the probe failure. The old 0.6.0 binary still completed status, stop, start, and destroy after the upgrade. A fresh VM from the final 0.7.0 archive started without warnings, and a deliberately damaged disposable ext4 disk was reset by the public installer in 3.2 seconds with an explicit data-loss notice while the VM process stayed in place.

That interrupted 0.6.0 bootstrap may have deleted the staged control-node SSH key before installing it. Management SSH recovers, but peer SSH remains an explicit control-ssh limitation; the key is not reinjected during an in-place retry. Recreate the affected control node after reviewing farrow plan if peer SSH is required. Fresh 0.7.0 guests install the key normally.

macOS validation includes CLI smoke checks and cross-compilation. This release does not claim a new HVF guest replay, host reboot test, Linux arm64 run, or full Pigsty installation.

3 - Farrow 0.6.0: Ubuntu 24.04 and smoother local labs

Farrow 0.6.0 defaults to Ubuntu 24.04 and improves the everyday loop of planning, starting, expanding, and rebuilding a local Pigsty lab.

What changed

• Ubuntu 24.04 by default. New inventories and the embedded catalog use u24:stable. Catalog revision 2026090501 also includes the Debian 12/13 and Rocky Linux 8/9 updates already available in the official repositories.
• Useful plans before setup. plan for Catalog images works without QEMU or host networking installed (registered local-* images still need qemu-img cache validation) and shows exact image versions, resource totals, pending starts, changed fields, disk effects, and commands that retain custom -f paths.
• Readable status and errors. Status shows images, CPU, and memory; one damaged node no longer hides healthy peers. Corrupt state names the actual file and cause. Image digest failures return exit 7; SSH exit 255 passes through unchanged. --no-wait clearly reports that readiness was skipped.
• Checks before disruption. Selected recreate detects conflicting peer changes before deleting disks. reload checks startup dependencies before stopping guests. Stop, destroy, and runtime cleanup handle deployment state consistently under the existing lock.
• Guest names stay current. Starting commands and node removal refresh Farrow-managed guest hosts entries and control-node SSH configuration. Recreated peers remain reachable without clearing guest known_hosts. User SSH text and global option scope are preserved.
• Fewer CLI surprises. Custom init paths produce usable next commands; presentation flags respect option values; malformed integer sizes and extra YAML documents are rejected without truncation. ALL_PROXY/all_proxy provides a fallback while respecting scheme-specific proxies and NO_PROXY.

Upgrade notes

Upgrading Farrow does not replace existing disks or change an explicitly selected image. If an old inventory relied on the implicit Debian 13 default, add vm_image: d13 under all.vars before applying it with 0.6.0. Review farrow plan before applying changes; farrow start uses the applied state.

CPU and memory changes still use recreate: root and non-persistent data disks are replaced, while persistent data disks are retained. --no-wait skips both readiness and guest metadata refresh; a later farrow up completes them. Scripts should use --json or --yaml instead of parsing status columns; partial status results include healthy nodes and a failures array, with exit 5.

Install or upgrade

curl -fLO https://github.com/pgsty/farrow/releases/download/v0.6.0/install.sh
chmod +x install.sh
FARROW_VERSION=0.6.0 ./install.sh
farrow version
farrow doctor

The release also includes four platform archives, amd64/arm64 DEB and RPM packages, and a Homebrew formula. As a pre-1.0 release it keeps the GitHub pre-release flag, so the installer needs the explicit version above. See the Quick Start.

Validation

The lifecycle and UX changes passed two adversarial Claude Code Fable 5.1 reviews at xhigh effort, plus the complete local make check gate. An isolated macOS arm64/HVF lab exercised Ubuntu 24.04 boot, scale-out, control-to-peer SSH, stop/start, reload, recreate, partial status failures, and scale-in. The final guest SSH scope correction also passed effective OpenSSH configuration tests.

The tag workflow repeats source checks and verifies archives, packages, SBOMs, installer, formula, release metadata, and checksums. These checks do not imply a new Linux-host VM replay, host-reboot test, or complete Pigsty installation.

4 - Farrow 0.4.0: one command, working data disks, one voice

Farrow 0.4.0 was the public pre-1.0 release superseded by 0.5.0. It makes the first run one command, fixes the default data disk on Debian and Ubuntu images, and gives every command the same output style. The Pigsty Inventory format, the fixed-IP deployment model, the state layout, and the embedded Catalog revision 2026082903 are unchanged.

What changed

• On a terminal, farrow up runs farrow setup itself when the fixed-IP network has never been installed, shows the setup plan, asks before the privileged step, and then continues. farrow init points at farrow up.
• vm_disks[].fs defaults to auto: a blank disk is formatted XFS when the guest has mkfs.xfs and ext4 otherwise, the same choice Pigsty’s Vagrant flow makes. The old xfs default failed on Debian and Ubuntu images, which ship without xfsprogs. Deployments created with the old default are not reported as drift and their persistent disks stay compatible.
• The guest error marker carries the failing command’s last message, so up reports guest bootstrap failed during data-disks: xfs requested but mkfs.xfs is unavailable instead of an exit status.
• Lifecycle commands and status print a node table and, after up, a next: farrow ssh <node> hint. plan and validate print one line when nothing changes; image list, network status, doctor, and preflight errors use plain sentences without machine codes; spec hash and other internals moved to --json. Errors about an unknown node list the nodes.
• farrow ssh <node> -- 'df -h /data; id' passes the remote command exactly as OpenSSH does.

Upgrading

A d13, d12, or Ubuntu node created by 0.3.0 or earlier whose /data never mounted needs one farrow recreate <node>; the disk is then formatted ext4 on those images and XFS on Enterprise Linux images. Automation that runs up on an unprepared host without a terminal still needs farrow setup --yes first.

Verification boundary

Source commit 8ecb8476c7dbc934d8cbbee935ac53884d00fcdb passed the complete local source gate: unit and race tests, vet, Staticcheck, deadcode, errcheck, govulncheck, shell and module checks, four target builds, the image-pipeline and installer boundaries, and dependency licenses. The tag workflow repeated those checks and built and verified every archive, native package, SBOM, and the installer before the Release was made public.

The new first-run path (up running setup) is covered by unit tests and was not replayed on a fresh host before this release. The dated macOS arm64/HVF and Ubuntu amd64/KVM evidence remains listed on the Status page; source, package, release, and native-host evidence remain separate gates.

Install or upgrade

Download the installer and assets from the Farrow 0.4.0 GitHub Release:

curl -fLO https://github.com/pgsty/farrow/releases/download/v0.4.0/install.sh
chmod +x install.sh
FARROW_VERSION=0.4.0 ./install.sh
farrow version
farrow doctor

Homebrew formula and amd64/arm64 DEB/RPM packages are attached to the same pre-release. Existing deployment and Catalog state remains readable.

5 - Farrow 0.5.0: explicit disposal, explicit repositories, reproducible images

Farrow 0.5.0 was the public pre-1.0 release superseded by 0.6.0. It adds an explicit command for disposable labs, makes repository geography an operator choice, and adds a reproducible path for preparing the next official guest images. The Pigsty Inventory contract, deployment state format, and embedded Catalog revision 2026082903 are unchanged.

What changed

• farrow purge (alias farrow rm) removes the complete deployment, persistent data disks, deployment keys and state, and the default SSH fragment without confirmation. The verified image cache and host-global network remain. Absence is idempotent, while unidentifiable residual node artifacts still fail closed.
• Released binaries use https://repo.pigsty.io/farrow by default. Long-only --mirror selects https://repo.pigsty.cc/farrow; --repo remains the highest-precedence override, followed by --mirror, FARROW_REPO, and the global default. Both official roots keep canonical signed-Catalog trust.
• Catalog upstream URLs are provenance, not a fallback. A selected repository must contain the exact Catalog-named qcow2 or the pull fails with guidance to choose another root or import a local image.
• The source tree now has a digest-pinned offline builder for Debian 12/13 and Rocky Linux 8/9 on amd64/arm64. It records the exact package closure, SBOM, provenance, and testing manifest, and can assemble an unsigned candidate repository for later native smoke and signing review.
• The pinned source/release toolchain moves to Go 1.27.1, GoReleaser 2.18.0, golangci-lint 2.13.2, and current selected Go modules.

Image boundary

The eight-target matrix fixes concrete guest prerequisites: Debian 12/13 gain the XFS userspace needed for explicitly XFS-formatted data disks; Rocky Linux 8 gains /usr/bin/python3, working SSH drop-in inclusion, and clean interface naming state; Rocky Linux 9 receives the same legacy-network cleanup.

Those are candidate-build inputs, not newly published Catalog artifacts. Every result remains unsigned and testing until native boot/readiness smoke, repeat-build comparison, production signing, upload, and Catalog publication complete.

Upgrade and disposal

No state, Inventory, or Catalog migration is required from 0.4.0. Existing cached images remain usable. New downloads use the global repository unless --mirror, --repo, or FARROW_REPO selects another root.

purge is deliberately non-interactive and irreversible for deployment disks and keys. Continue to use confirmed farrow destroy when preserving persistent disks or removing selected nodes.

Verification boundary

Release source commit fc85b65ff6a24b0933b56ae1179be9ada2ba91b1 passed the complete local source gate: module and shell checks, unit and race tests, vet, Staticcheck, deadcode, errcheck, govulncheck, four target builds, simulated image-pipeline boundaries, installer tests, and exact dependency-license verification. GoReleaser 2.18.0 also accepted the release configuration.

The tag workflow independently repeats those checks and builds and verifies every archive, native package, SBOM, formula, installer, release metadata file, and checksum before the pre-release is published. No new native VM lifecycle replay or published-image claim is inherited from these source gates.

Install or upgrade

Download the installer and assets from the Farrow 0.5.0 GitHub Release:

curl -fLO https://github.com/pgsty/farrow/releases/download/v0.5.0/install.sh
chmod +x install.sh
FARROW_VERSION=0.5.0 ./install.sh
farrow version
farrow doctor

The same pre-release includes the Homebrew formula and amd64/arm64 DEB/RPM packages.

6 - Farrow 0.3.0: explicit catalogs and actionable readiness

Farrow 0.3.0 was the public pre-1.0 release superseded by 0.4.0. It removes implicit Catalog refreshes, turns guest bootstrap failures into actionable per-node results, and simplifies the CLI without changing the Pigsty Inventory or fixed-IP deployment model.

What changed

• up, plan, and ordinary image commands use one active local Catalog snapshot and never fetch Catalog metadata implicitly. farrow update explicitly fetches the configured repository; image sync activates an exact URL or file.
• Guest bootstrap writes an atomic failure stage. Partial operations report every failed node, stage, and error, and readiness failures point directly to farrow logs <node>.
• Already-running guests can be rechecked without restarting QEMU. A partial lifecycle still rebuilds the SSH client configuration from every committed node.
• Netplan matches deterministic MAC addresses without renaming interfaces. vm_disks[].fs: auto prefers XFS and falls back to ext4 when necessary.
• The redundant ss command and ambiguous root/flag shorthands are removed. image reset replaces reset-manifest, which remains an alias.

Verification boundary

Source commit da6d02426da93c677c94c67fec4eb4fcecf4766a passed the complete local source gate and a full GoReleaser snapshot: unit and race tests, vet, Staticcheck, govulncheck, four target builds, image-pipeline and installer boundaries, archive/package parity, dependency licenses, SBOMs, and native Linux package verification. The tag workflow repeated those checks before the Release was made public.

This release does not claim a new native VM replay. The dated macOS arm64/HVF and Ubuntu amd64/KVM evidence remains listed on the Status page; source, package, release, and native-host evidence remain separate gates.

Install or upgrade

Download the installer and assets from the Farrow 0.3.0 GitHub Release:

curl -fLO https://github.com/pgsty/farrow/releases/download/v0.3.0/install.sh
chmod +x install.sh
FARROW_VERSION=0.3.0 ./install.sh
farrow version
farrow doctor

Homebrew formula and amd64/arm64 DEB/RPM packages are attached to the same pre-release. Existing 0.1/0.2 deployment and Catalog state remains readable; Catalog refresh is now always explicit.

7 - Farrow 0.2.0: selected convergence and release integrity

Farrow 0.2.0 was the public pre-1.0 release superseded by 0.3.0. It keeps the Pigsty inventory and on-disk deployment format introduced by 0.1.0 while fixing the network and selected-convergence boundaries found during the final native replay.

What changed

• A less-specific VPN exclusion such as 10.0.0.0/8 no longer blocks Farrow’s owned 10.10.10.0/24; equal or more-specific foreign routes, overlapping interfaces, occupied addresses, and a missing owned route still fail closed.
• farrow up <node> downloads and prepares only the selected node. Desired inventory peers without state appear as absent; SSH/hosts/provisioning, UUID and port allocation, lifecycle commands, and persistent-disk checks use the committed node set without losing future scale-out intent.
• New guests write # farrow-deployment-host and remove both that marker and the released # farrow-project-host marker before adding current host rows.
• Command cancellation, structured output, confirmation, reload, diagnostic redaction, installer retention, and the smaller dependency graph from the unpublished intermediate work are included directly in 0.2.0.

Native and release evidence

The exact source commit completed a macOS arm64/HVF replay with MonoProxy active: selected u24-1 create/SSH/stop/start, incremental cached el9-1 create, two-node SSH, five explicit absent peers, and whole destroy all passed. On Ubuntu 26.04 amd64/KVM, the current Linux binary audited an existing four-node deployment and reached its control guest without mutation.

Local make check, source CI, and the complete packaging workflow passed. The tag workflow built four archives, amd64/arm64 DEB and RPM packages, SPDX SBOMs, Homebrew formula, installer, checksums, and release metadata. GitHub Actions uploads those verified CI outputs to a draft for review before public release, without a separate application signature or provenance bundle.

The signed image Catalog remains revision 2026082903 with 9 families and 27 architecture artifacts. The default repository remains https://repo.pigsty.cc/farrow; repo.pgsty.com/farrow is an independently verified source/alternate endpoint, not the compiled default.

Install or upgrade

Download install.sh and the assets from the Farrow 0.2.0 GitHub Release:

chmod +x install.sh
FARROW_VERSION=0.2.0 ./install.sh
farrow version
farrow doctor

0.1.0 deployment state remains readable. Run farrow status while retained VMs are live to converge any pre-release process-birth identity. Existing guests adopt the new /etc/hosts marker when recreated.

Because Farrow is still below 1.0, GitHub labels 0.2.0 as a pre-release.

8 - RC6 development candidate: owner-scoped Tier-1 delivery

Piglet 1.0.0-rc.6 is the owner-scoped local development candidate for the single native-QEMU path. It closes the requested Quick and exact four-node full scenarios on both Tier-1 hosts and adds durable privileged-network transactions. It is deliberately not a public release.

Frozen identity

Four requested product scenarios

All eight final full-profile guests reported Ubuntu 24.04.4. The projects were destroyed through Piglet after assertions; shared image caches, project markers, and keys were intentionally retained.

Durable native networking

Network install and uninstall now use one root-owned strict-prefix transaction:

• root planning returns an owner/host/prestate-bound token;
• apply replans under the host-global lock and accepts only that token;
• a typed, fsynced journal is published before mutation;
• each fixed action is checkpointed after exact postcondition verification;
• interrupted work blocks ordinary private mutation until an explicit forward or rollback recovery plan is separately token-approved.

Darwin completed a real interrupted forward recovery and ended protected and healthy in default host mode. Linux completed real install, rollback/retry, four-node operation, uninstall, and host restoration before the final adversarial patch. That patch closed socket-state canonicalization, overly broad systemd enablement, NetworkManager ordering, and field-scoped recovery effects, then passed consolidated source/race gates.

Per the owner’s final direction, no VM or network test ran after that last patch. Therefore the post-audit Linux install/uninstall/reinstall replay is explicitly not run. This page does not upgrade source/race evidence into a native result.

macOS shared mode and subnet conflicts

The supported default remains socket_vmnet host mode. Shared mode passed a two-node contract on a proven-free alternate subnet, but it is an explicit fallback and not an isolation boundary.

The historical default-subnet failure was VMNET_SHARING_SERVICE_BUSY (1009). VirtualBox was a plausible contaminant, not a proven owner of that incident. Immediately before the final migration, the observed subnet interface was the older Piglet-created bridge100. Preflight now rejects foreign interfaces by identity instead of adopting a matching .1/24 address. Operators can remove the confirmed owner or move the whole lab to one warned canonical RFC1918 /24; Piglet never changes only the guest addresses or selects a random escape subnet.

Reproducible local archives

Two independent local RC6 output trees passed the strict release verifier and were byte-identical for the four archives, checksums, release metadata, and formula:

The formula is an inert build artifact. Earlier candidates exercised offline RPM/DEB consumption and ephemeral Cosign/SLSA round trips, but those results are mechanism evidence and are not relabeled as RC6 publication/signing.

What remains public-GA work

• literal reboot persistence on both Tier-1 hosts;
• current native smoke on macOS amd64 and Linux arm64;
• the deliberately deferred Linux final network replay;
• remaining image normalization, byte-reproducibility decision, hosting, and active/standby manifest-key custody;
• production release identity, signing/attestation, published Homebrew and Linux package channels, and clean-host consumption;
• a durable owner-operated macOS HVF runner and explicit release authorization.

See the current tutorial, design, and status for the maintained boundary.

9 - Development snapshot: the Go 1.27 product surface

Piglet’s 2026-08-24 source snapshot has moved well beyond an initial QEMU spike. It now presents one coherent local-VM product: zero-configuration Quick, fixed-address private labs, 13 Piglet-owned profiles, an audited Pigsty inventory boundary, explicit persistence/state migration, diagnostics, and a reproducible release toolchain.

It is still a development snapshot—not a stable release.

One native runtime

Piglet directly drives native QEMU through HVF on macOS and KVM on Linux. It owns strict specification resolution, image/qcow2 verification, pure-Go NoCloud CIDATA, QMP/process identity, SSH readiness, atomic state, journals, events, repair, and bounded deletion. QEMU runs as the invoking user and never silently falls back to TCG.

There is no second provider/runtime path and no arbitrary QEMU-argument escape.

Quick on both Tier-1 hosts

The retained Go 1.27 Quick runs cover the public no-YAML path on macOS arm64 and Linux amd64. The contract is meta/dba, 2 vCPU, 4 GiB memory, 64 GiB root, sparse 64 GiB /data, user NAT, SSH, and four loopback forwarding conventions.

The product supports plan, up, status, SSH/exec, stop/start/restart, drift classification, guarded recreate/destroy, no-wait, persistent-disk retention, key retirement, logs, repair, and redacted debug bundles.

Those forwards do not install applications. Pigsty/PostgreSQL bootstrap remains a separate integration gate.

Private labs and host networking

Private mode now has public preflight/status/install/uninstall flows on both Tier-1 host families. macOS uses pinned socket_vmnet v1.2.2 with host mode by default and evidence-backed shared/FD paths. Linux uses a reversible systemd-networkd/NetworkManager/bridge-helper transaction. Both keep QEMU unprivileged and block uninstall while the global lease is active.

The default 10.10.10.0/24 can be replaced by one explicit canonical RFC1918 /24. Profile, host install, lease, state, node addresses, and Pigsty inventory must move together. No random collision escape is chosen.

Retained four-node full and MinIO runs exercised fixed IPs, control-only lateral SSH, management internet, storage identity, stop/start persistence, and clean destroy on both Tier-1 paths. Earlier runs also cover crash recovery and 30/30 soak. The MinIO profile runs validate 16 VM data disks, not the MinIO application.

Schema-3 owned profiles and Pigsty inventory

The 13 embedded profiles contain 85 nodes, all using dba. Ordinary nodes have one 128 GiB /data; MinIO nodes have four 32 GiB disks. Catalog schema 3 owns scalability, image policy, and Pigsty inventory binding, with direct and build_subset modes.

piglet pigsty inventory reads a real Pigsty source tree, classifies and validates host/VIP/admin/service address semantics, rebases a coordinated custom subnet, and can atomically publish a mode-0600 marker-owned output. pigsty-vm exposes the same profile, network, lifecycle, and inventory contract through a small typed environment.

The wrapper has no provider fallback. Operational rollback means a prior verified Piglet artifact plus matching state backup.

Persistence, upgrade, and automation

Disks marked persistent: true survive ordinary destroy and compatible recreate. The current safety contract requires an independent TTY phrase or destroy --force --delete-persistent --yes-delete-persistent; project keys have a separate default-dry-run project purge-keys --yes boundary.

Schema 0→1 migration is stopped-only, no-lease, backup-first, atomic, and explicit through project upgrade-state --dry-run|--yes. Newer schemas are refused rather than downgraded.

Private node selectors, --no-wait, stable JSON responses, typed exit classes, shell completion, SSH config, marker-owned hosts blocks, per-node logs, and redacted support bundles complete the current operator/automation surface.

Images and release mechanisms

The formal embedded image set is el9, el10, d12, d13, u22, u24, and u26 on both Tier-1 native architectures. Retained matrix records report 7/7 per architecture; EL8 was retired from v1 because its arm64 kernel cannot satisfy the tested native HVF contract. The entries remain testing pending a production image channel and custody.

The source tree can build and verify four native archives, a Homebrew formula, Linux amd64/arm64 RPM and DEB packages, checksums, SPDX SBOMs, a combined release assembly, and Cosign signature/SLSA-provenance positive and tamper tests. Isolated package install/verify/remove and two-run reproducibility passed for the tested snapshots. The checked-in release workflow has not executed for a real tag.

Evidence must follow exact bytes

At this snapshot, catalog schema 3 and inventory integration had changed the checked-in profile/resolved digests after the retained full/MinIO runs, so exact-current native refresh was still required. Custom-subnet hosts publishing, applied storage.data_root/ssh.wait_timeout, and generic Quick users were also open.

RC6 later closed those implementation and exact-profile gaps. Historical native runs remain valid only for the bytes and behavior they actually exercised.

What remains before v1.0

The snapshot’s exact-profile, Pigsty-bootstrap, and Rocky 9.8 private-host gates were later exercised. The current remaining gates are production image/manifest/release custody, durable runner ownership, literal reboot recovery, Tier-2 native smoke, published package consumption, and a real signed/attested tag-bound release.

See the current tutorial, design, and status for the maintained boundary.