Operations
These are operating lessons from a real single-host launch platform, not claims that one layout is correct for every environment.
DotMoose uses mirrored NVMe for production workloads and mirrored HDD capacity for bulk backup storage. That provides device redundancy, but one physical host remains one host. We do not call the launch topology multi-host or multi-datacentre HA.
Capacity planning should use real usable storage and leave operational headroom. Full pools make maintenance, snapshots, migrations and recovery harder, so stop new provisioning before that safety margin is consumed.
ZFS uses memory for ARC caching. On the launch host, ARC is deliberately bounded so the hypervisor retains predictable memory for guests and control-plane work. “Unused RAM” and “guest-allocatable RAM” are not the same thing on a ZFS hypervisor.
Monthly scrubs help surface latent read/checksum problems while redundancy is available. TRIM is enabled for the NVMe pool. Neither creates an independent recovery copy, so control-plane and billing data also have an off-host backup path.
Gate 15 created disposable VPS 2 and VPS 4 guests through the actual DotMoose provisioning workflow, ran bounded direct-I/O benchmarks, archived the raw evidence, then destroyed the guests. That test caught a QA-only provisioning defect that static inspection had missed.
A single physical host does not provide host-level high availability. A future cluster changes that only after placement, quorum, storage, networking and recovery are implemented and tested.
The current public architecture and its limits are maintained on the infrastructure page.
Infrastructure transparencyA mirror, snapshot and off-site backup solve different problems.
ZFS mirror guide