Hotswap station

The Hotswap station is the bulk-erasure variant of the AVERASE erasure engine: a separate bootable ISO built for drive chassis and servers with hot-swap bays, where the job is erasing loose drives in volume rather than processing one whole machine.

What it is

Where the erasure engine boots on the machine whose drives you are erasing, the Hotswap station boots on a host — a JBOD chassis, a disk shelf on an HBA, or a server with hot-swap bays — and erases the drives you load into it. It is the same live system underneath: a self-contained Alpine Linux 3.21 x86_64 image that runs entirely from RAM, boots on both BIOS and UEFI machines, and launches a full-screen kiosk with no desktop or shell behind it.

The station shares the engine's whole erasure core. What changes is the workflow around it: the hardware-test pages are gone (you are not auditing a laptop's webcam), and in their place sits a chassis mapping screen that lets you name the physical bays of your chassis so results and inventory records read as bay positions instead of raw device paths.

Getting the Hotswap ISO

The Hotswap station is its own product with its own ISO. On the Download page in the web app (admins only), you'll see two cards: AVERASE (the engine) and AVERASE Hotswap. Each card issues its own token-embedded ISO — a Hotswap download arrives as averase-hotswap-<id>.iso, with your account's device token spliced into the image exactly as it is for the engine.

The Hotswap card is gated by provisioning: until the Hotswap image has been provisioned for your environment, the card renders a muted Provisioning state instead of a download button. Once available, it shows Download for subscribed accounts (or View plans otherwise).

See Downloads for issuing, revoking, and suspending ISOs, and License tokens for how entitlement works end to end.

How it differs from the engine

The station has five screens, in workflow order:

Screen	Band title	What it does
Dashboard	Device fingerprint	The host chassis's hardware audit — same fingerprint dashboard as the engine.
Mapping	Chassis map	Name the chassis's bays and save the map to your account. See Chassis mapping.
Erase configuration	Drives	Select drives, pick a method per drive, commit the erase.
Wipe in progress	Wipe progress	Live per-drive progress and cancellation, all drives in parallel.
Summary	Summary	Per-drive result and disposition.

The sidebar carries exactly three destinations — Overview (the dashboard), Mapping, and Erase — plus the same Power, Network, and Worker controls as the engine. There are no hardware-test pages: keyboard, display, webcam, audio, USB, and battery tests exist only on the engine.

What it shares with the engine

• The same licensing lock. The station boots locked, unlocks only on an affirmative online license verification, and checks in with the server immediately before every erase run. A denied token — or any network failure — blocks the wipe. There is no offline unlock. See Booting & verification.
• The same NIST 800-88 wipe stack. Methods NIST 800-88 R2 Clear and NIST 800-88 R2 Purge, the full technique ladder (NVMe Sanitize/Format, ATA Sanitize/Security Erase, SCSI Sanitize, TCG Opal PSID Revert, zero overwrite), and read-back verification are identical to the engine's. See Wiping drives.
• The same fingerprint dashboard. The Overview screen is the engine's device-fingerprint audit of the host chassis, and the station reports that fingerprint to your account's inventory once per boot, after verification.
• The same results pipeline. One wipe result per drive, one certificate per drive, issued by AVERASE cloud — never by the station. See Results & certificates.

Hardware requirements

The station erases internal SATA, SAS, and NVMe drives.

• The HBA must be in IT mode (passthrough). The station needs to address each drive directly as a block device. Drives hidden behind RAID virtual disks are not wipeable — a RAID controller presenting a virtual disk stands between the station and the physical media. Flash the controller to IT mode or move the drives to a passthrough HBA.
• Drives are enumerated at startup (with a manual Refresh available), and each is either a wipe target or excluded with a reason shown verbatim in its Method cell as excluded — {reason}:

Condition	Exclusion reason
Drive hosts the running OS or /boot	a reason naming the OS
Removable drive	removable device
USB or MMC transport	removable transport ({transport})
iSCSI / FC / FCoE transport	network/SAN transport ({transport})

The kernel boots with libata.allow_tpm=1, which is required for ATA Secure Erase and Sanitize plus the boot-time unfreeze of firmware-frozen disks — no operator intervention needed.

---

Planned: the bay grid

The Hotswap station is converging on a continuous-flow model built around the physical chassis:

• A one-page bay grid. Instead of the engine's select-then-commit workflow, the station will boot into a single page of bay tiles matching your chassis: insert a drive, confirm it on its tile, watch it wipe, pull it when it's done — with many bays in different states at once.
• Per-drive check-in and quota. Each drive will check in individually, getting its own job id and consuming one quota unit per drive. Today the station checks in once per erase run, so a run consumes one quota unit regardless of how many drives it erases.
• Boot-time chassis-map lookup. The station will fetch your saved chassis map at every boot, so bay labels survive reboots and the grid lays itself out to match the physical chassis. The server side of this already exists — see Chassis mapping.

Where to next