No code changes. Cuts a fresh release purely so a host on v0.1.2 can run `banger update` and confirm v0.1.2's install.toml-refresh fix actually works when v0.1.2 is the code driving the update — during the v0.1.1→v0.1.2 update the buggy v0.1.1 code was still in the driver seat, so live verification of the fix needs one more cycle. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6.8 KiB
Changelog
All notable changes to banger are documented here. The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
The version line printed by banger version is the canonical reference
for what's installed; this file is the canonical reference for what
changed between versions.
Unreleased
v0.1.3 - 2026-04-29
No functional changes. Verification release: v0.1.2 fixed
banger update's install.toml handling, but the fix only takes
effect when v0.1.2 (or later) is the driver of an update. v0.1.3
exists so a host running v0.1.2 can update to it and confirm the
fix works end-to-end with the new code in the driver seat.
v0.1.2 - 2026-04-29
Fixed
banger updatenow writes the freshly-installed binary's commit and built_at fields to/etc/banger/install.toml, not the running CLI's. Previously install.toml'sversionwas correct after an update butcommit+built_atstill pointed at the pre-update binary's identity, which madebanger doctorraise a false-positive "CLI/install drift" warning on every update. Caught by the v0.1.0 → v0.1.1 live update smoke-test.
v0.1.1 - 2026-04-29
Added
install.sh— one-command installer published athttps://releases.thaloco.com/banger/install.sh. Runs as the invoking user, downloads + verifies the latest signed release with the embedded cosign public key, and re-execssudoonly for the actual system-install step. Pre-sudo summary explains in plain language why elevation is needed.BANGER_INSTALL_NONINTERACTIVE=1env var oninstall.shfor non-interactive use throughcurl | bash(CI, automated provisioning).
v0.1.0 - 2026-04-29
First public release. banger runs disposable development sandboxes as Firecracker microVMs: each sandbox boots in a few seconds, gets its own root filesystem and network, and exits on demand.
Added
Sandbox VMs
banger vm runboots a microVM, drops you into ssh, and tears it down on exit. Optional positional path ships a host repo into the guest;-- cmd argsruns a command non-interactively and exits with its status.- Long-lived VMs via
vm create/vm start/vm stop/vm restart/vm ssh/vm exec/vm logs/vm stats/vm ports/vm kill.vm listandpsenumerate state;vm prunedeletes every non-running VM. vm workspaceships a host repo into a guest and pulls diffs back.- Per-VM cgroup-isolated firecracker process under jailer chroot; daemon restarts do not interrupt running guests.
Images
banger image pull <name>pulls a curated rootfs+kernel bundle from the banger image catalog.image pull <oci-ref>pulls any OCI image.image list/image show/image delete/image promote/image registerround out the lifecycle.image cachemanages the OCI layer-blob cache.- Concurrent pulls of the same image are coalesced; the first pull wins, the rest wait.
Kernels
banger kernel pull <name>pulls a Firecracker-compatible kernel from the banger kernel catalog.kernel list/kernel show/kernel rmmanage the local store.
Host networking
- Per-host bridge with NAT; per-VM tap device; deterministic IPv4 assignment; iptables rules installed/removed with VM lifecycle.
- DNS routing: local resolver on
127.0.0.1:42069answers queries for<vm>.vmso plainssh <vm>.vmreaches the guest. banger ssh-configwrites a one-time~/.ssh/configinclude so ssh, scp, and rsync resolve<vm>.vmfrom any terminal.
System install
sudo banger system installinstalls an owner-mode daemon (bangerd.service) and a root-helper (bangerd-root.service) as systemd units. The owner daemon runs as the invoking user; only the root helper holds privilege, and only for a vetted set of operations.system status/system restart/system uninstallround out the lifecycle.daemonis a thin alias.banger doctoraudits host readiness: architecture, CLI/install version drift, state store, host runtime, vm lifecycle prerequisites, vsock guest agent, vm defaults, ssh shortcut, /root work disk, DNS, NAT, firecracker binary version, systemd units, socket permissions, helper unit hardening directives.
Self-update
banger updatedownloads, verifies, and installs newer releases from the public manifest. Flow: fetch manifest, refuse if any VM operation is in flight, download tarball +SHA256SUMS+SHA256SUMS.sig, verify the cosign signature against the embedded public key, verify the tarball hash, stage to a scratch dir, runbangerd --check-migrationsagainst the staged binary, atomically swap the three banger binaries, restart the systemd units, runbanger doctor, finalise the install record.- Pre-restart abort and post-restart auto-rollback both restore the previous install on failure.
banger update --checkreports whether a newer release is available without applying it;--to vX.Y.Zpins a specific version;--dry-runprints the plan;--forceskips the in-flight-op refusal.
Trust model
- Every release is cosign-signed. The public key is embedded in the
banger binary at build time; the signed payload is
SHA256SUMS, which in turn covers the release tarball. Verification uses the Go standard library (crypto/ecdsa.VerifyASN1); cosign is needed only for signing, not for verification. - The release manifest URL is hardcoded into the binary so a compromised daemon config cannot redirect the updater to a different bucket.
CLI surface
- Top-level:
vm,ps,image,kernel,ssh-config,system,daemon,doctor,update,version,completion. banger versionreports the version, commit SHA, and build timestamp baked in via ldflags at release-build time.
Compatibility
- The host-side and guest-side vsock agent protocol is informally
stable across patch versions (v0.1.x). Minor-version bumps
(v0.2.x) may change it; existing VMs created against an older
minor will need to be re-pulled.
banger doctorwarns when a running VM's agent is older than the daemon expects but does not block lifecycle operations. - The on-disk store schema is forward-only. Downgrading the binary
against a database written by a newer binary is unsupported; the
updater detects this via
bangerd --check-migrationsand refuses the swap rather than starting up against an incompatible store. - Linux only. amd64 only. KVM required.