RackMarshal 1.3.0 RC1
A release candidate for fresh installs on Debian 12. It fixes how a ZFS pool with permanent data errors is recorded: such a pool now opens an incident, and the incident closes only on recorded clean evidence. It also adds daily integrity-checked database snapshots and baseline adoption tools for ZFS, Home Assistant and Proxmox. There is no in-place upgrade in 1.3, so start from a fresh container or machine.
Qualified release artifacts
The installer bundle ran a 24-hour soak on a fresh Debian 12 container with no problems, and passed a separate install, uninstall, purge and reinstall test. CI passed on the exact commit, including the full test suite run as root. The release notes list every file's SHA-256 and what was not covered.
Known limits
Debian 12 is the only qualified platform. The backup domain is not supported for new installs in this candidate, and MCP client activation is not claimed. The events table has no automatic cleanup yet, so it grows over time; retention is planned for a later release.
Monitoring tells you what is happening now. RackMarshal remembers what happened.
RackMarshal maintains operational state across time: observations become evidence, meaningful changes become events, failures become incidents, and recovery is tracked instead of assumed.
Operational domains in RackMarshal 1.0
Each enabled domain has a collector and incident-processing path. Proxmox, ZFS, backup/PBS and Home Assistant also include explicit observation, comparison and event stages; hardware and mount use integrated pipelines.
Proxmox VE
Records cluster-resource observations, compares verified resource state, and opens or recovers incidents when expected VM or container status diverges and returns.
ZFS
Observes pool state through SSH, compares verified baselines, records status-change events, and tracks pool incidents through recovery.
Backup / PBS
Observes backup resources and PBS state, compares them against verified state, and tracks backup incidents and recovery.
Home Assistant
Records Home Assistant observations, compares expected resource state, records changes, and tracks incidents through recovery.
Hardware health
Tracks configured NVMe devices and temperature thresholds, including urgent conditions and sample-based recovery.
Mounts
Checks configured host, VM and container mounts, detects missing or mismatched sources, and tracks mount incidents through recovery.
What RackMarshal 1.0 was qualified against.
The 1.0 release was exercised with fictional incident open/recovery lifecycles across all six domains, notification failure/retry/recovery, and a disposable clean Debian 12 installation path.
incident lifecycles exercised
covered by CI
clean-host install, reboot and reinstall acceptance
plus publication scanning and automated release gates
A local API exposes runtime health and assembled operational status.
A verified base installation starts the local status service. The health endpoint is deliberately simple; the status endpoint assembles RackMarshal operational state from the local database and configured domains.
GET /health
GET /status
Returns the locally assembled RackMarshal status payload for the runtime and available operational domains. The default API remains bound to 127.0.0.1:9110.
Local first by design.
RackMarshal is designed to operate without turning your infrastructure telemetry into a dependency on somebody else's hosted service.
Put RackMarshal into infrastructure it wasn't built on.
We’re looking for technically experienced users willing to install RackMarshal, configure it against real systems, challenge its assumptions, and find the environments we didn’t anticipate.
Install the 1.0 release bundle
Start with a Debian/Ubuntu-compatible system using systemd and Python 3.11+.
Verify the base runtime
Confirm the status service, notification timer and local /health endpoint.
Configure one domain
Enable a domain explicitly, add its site-specific credentials or SSH access, and validate configuration before collection.
Generate observations and report what happens
Use RackMarshal in a real environment and report installation, configuration or incident-lifecycle failures as GitHub issues.
A successful base installation proves the RackMarshal runtime, database, status API and notification queue can run. It does not automatically configure access to Proxmox, PBS, Home Assistant, ZFS, hardware or mount targets.
Those integrations require site-specific configuration and credentials. The installer does not copy production credentials or discover your infrastructure automatically.
Talk to RackMarshal.
Questions about RackMarshal, testing it in your environment, contributing, or the project itself are welcome.
From one working environment to an open project.
RackMarshal was created by Michael Poteet after developing an operations system for his own self-hosted infrastructure. What began as a way to track health, failures and recovery across Proxmox, ZFS, backups, Linux systems and related infrastructure evolved into RackMarshal.
RackMarshal is now developed in the open so that operational model can be tested across infrastructure other people operate.