LIVE 2 A.M.

Operators are standing by! Lines are open all night!

Get slag.sh tonight!

One bash script. 186,783 bytes. It reads every byte of the disk, writes zeros only where something was, reads it all back, and hands you a receipt. Don't believe the announcer? Watch the actual output first. Every line on this page came off a real console.

slag /slæɡ/

  1. n the scum formed by oxidation at the surface of molten metals [syn: slag, scoria, dross]
  2. v convert into slag
  3. acronym SLAG: Sanitize, Log, Attest, Go. What’s left after the burn.
Sanitize
keys struck first, every non-zero block zeroed, every byte read back
Log
every step recorded as ok, unsupported, frozen, failed or skipped, with a reason
Attest
a receipt with its SHA-256, checked against the copy on the console
Go
the instance deleted only after a second boot proves the disks are zero

As seen on your console!

Other products show you a smiling actor. We show you the terminal. These are lab runs from 5 November 2026, copied as they printed. Where a run went on longer than a TV spot, we cut lines and marked the cut with ⋮. We never changed a line.

It makes you type the names

root@slaglab:~# bash /root/slag.sh wipe --target /dev/vdb --allow-partial
[warn] not targeted (--allow-partial): /dev/vda - data on them is untouched

PROOF MODEL - read before trusting the result
---------------------------------------------
HOW (zeroize, then verify):
  * zeroize reads every block and writes zeros only where a block is not
    already zero: every block that held data is overwritten in place; blocks
    that read zero were not written (on thin storage they stay unallocated)
⋮
DOES NOT PROVE (no in-guest tool can):
  * hypervisor/provider SNAPSHOTS or BACKUPS are gone  -> delete them by hand
⋮
Mitigation for everything in the second list = the rotation checklist.
Rotate/revoke every credential so a recovered block is worthless.

TARGETS (every byte on these is destroyed):
  /dev/vdb         model=?  serial=slagtgt  size=512M
Type the device names to wipe, separated by spaces ("vdb"): vdb

Before it touches anything, it tells you what it can't prove. Then it waits for you to type the device name.

It told me what it CAN'T prove? Before I even typed anything? Who raised this script?!
AYour auditorvisibly moved

It moves into RAM and tests itself

[slag] re-exec from tmpfs: mounting /run/slag.20261105T083936Z
[slag] staging the wipe's tools into /run/slag.20261105T083936Z
[warn] not installed (steps needing them record 'unsupported'): hdparm sg_sanitize mdadm
[slag] self-test: running the staged bash, script and tools from /run/slag.20261105T083936Z
[slag] self-test: bash 5.2.15(1)-release running from /run/slag.20261105T083936Z
[slag] self-test: static busybox ok
[slag] self-test: busybox has httpd (--serve)
[slag] self-test: sha256sum ok
[slag] self-test passed: bash, dd, cmp, od, blockdev run from tmpfs; verify catches short reads and nonzero bytes; zeroize writes exactly the nonzero 64 KiB blocks; the strike zeroes exactly the blocks holding key signatures; overwrite patterns write every byte and read back by SHA-256; filefrag output maps to disk offsets
[slag] wipe running detached as systemd unit slag-wipe (pid 1306); it survives this SSH session

Every tool the wipe needs is copied to RAM and checked before the first write, so a dropped SSH session doesn't stop it. A tool that's missing is recorded as unsupported, never skipped quietly.

It checks its own verify catches short reads... before it trusts its own verify. ...I need a minute.
GGary from Opshas trusted dd for 20 years

Keys first. Then every byte.

08:39:37 [slag] quiescing: swap off, stop writers on the targets, sync, emergency read-only remount, stop md/dm
⋮
08:39:37 [slag] strike /dev/vdb: scanning all 536870912 bytes for 11 key signatures; zeroing each match's block now
08:39:37 [slag]   [ok] /dev/vdb strike - 0 mapped file extents; scan: 0 signature hits; 0 ranges, 0 bytes struck and read back zero; 0 bytes written
08:39:37 [slag] === hardware erase: /dev/vdb (?, serial slagtgt, 536870912 bytes, rotational=yes) ===
08:39:37 [warn]   [unsupported] /dev/vdb hw-erase - no hardware erase path for vdb (virtual device?)
08:39:37 [slag] === zeroize + verify: /dev/vdb (?, serial slagtgt, 536870912 bytes) ===
08:39:37 [exec] wipefs -a -f /dev/vdb
08:39:37 [slag]   [ok] /dev/vdb wipefs - /dev/vdb: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef
08:39:37 [slag] zeroize /dev/vdb: reading all 536870912 bytes in 16 MiB chunks (direct I/O), writing zeros only to 64 KiB blocks that are not already zero
08:39:42 [slag]   [ok] /dev/vdb zeroize - conditional zero pass: 536,870,912 of 536,870,912 bytes read; 520,093,696 bytes written where a block was not already zero (7936 blocks of 64 KiB in 32 writes, in 32 of 32 16 MiB chunks)
08:39:42 [slag] verify (full read-back, direct I/O): reading all 536870912 bytes of /dev/vdb
08:39:43 [slag]   [ok] /dev/vdb verify - full read-back: 536870912 of 536870912 bytes read, all zero
08:39:43 [slag] VERIFIED: /dev/vdb reads back all zero, 536870912 of 536870912 bytes
08:39:43 [slag]   [ok] /dev/vdb recheck - 1 signature blocks still zero

512 MiB with a real ext4 filesystem on it, done in six seconds. The lab VM's virtual disk has no hardware erase, so the log says unsupported, not "ok".

It wrote 520 megabytes, not 536. It skipped the blocks that were already zero. And it TOLD me!
QA thin volumestill the size it was

The receipt. Yours to keep.

===================== SLAG WIPE RECEIPT =====================
tool:     slag.sh 1.1.0
host:     slaglab
started:  2026-11-05T08:39:36Z
finished: 2026-11-05T08:39:43Z
run:      rescue (no target filesystem mounted), from tmpfs /run/slag.20261105T083936Z
zeroize:  conditional zero pass: every block read (direct I/O, 16 MiB chunks); zeros
          written only to 64 KiB blocks not already zero, in place; no discard before it
verify:   full read-back of every byte
reclaim:  not requested; nothing was discarded
⋮
device /dev/vdb
  model=?  serial=slagtgt  size=536870912 bytes
  signatures               ok           1 offsets noted (signatures and partition starts)
  strike                   ok           0 mapped file extents; scan: 0 signature hits; 0 ranges, 0 bytes struck and read back zero; 0 bytes written
  hw-erase                 unsupported  no hardware erase path for vdb (virtual device?)
  wipefs                   ok           /dev/vdb: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef
  zeroize                  ok           conditional zero pass: 536,870,912 of 536,870,912 bytes read; 520,093,696 bytes written where a block was not already zero (7936 blocks of 64 KiB in 32 writes, in 32 of 32 16 MiB chunks)
  verify                   ok           full read-back: 536870912 of 536870912 bytes read, all zero
  file-extents             skipped      no mapped sensitive-file extents on this device
  recheck                  ok           1 signature blocks still zero
  zeroized: 536,870,912 bytes read, 520,093,696 bytes written where a block was not already zero; every block verified zero.
  verify:  full: 536870912 of 536870912 bytes read, all zero
  device verdict: PASS

Every step is ok, unsupported, frozen, failed or skipped, with a reason. Afterwards the lab stopped the VM and read the disk image itself: 519,711,271 non-zero bytes before, 0 after, and 500 marker lines before, 0 after.

"unsupported" with a REASON?! Not a green checkmark on something it never did?! Somebody get me a chair!
AYour auditorsitting down now

Type an IP. Walk away.

slag summary, written 2026-11-05T09:20:19Z

mode:       wiped from the provider's rescue system
disks:      /dev/vda 3.0 GiB (disk 1), /dev/vdb 256.0 MiB (disk 2), /dev/vdc 64.0 MiB (disk 3)
⋮
verdict:    PASS
⋮
steps:
  push              ok            0.4s  slag.sh sha256 e5e80f203750a8fb646ddac393d28a8d1523214f2190421e9a44089219ae4fca on the target
  markers           ok            0.5s  SLAG-MARKER-02276c5e2bcb02ee792943f4 x3 (50.0 MiB each): /root/.slag-marker, /etc/.slag-marker, /var/.slag-marker
  inventory         ok            1.2s  inventory + checklist copied, tarball sha256 4c3482ed818def5cc0bf8e85c7f4b24587b2942bf1bb2a4cd317c4596805a034 matches
  rescue_boot       ok           10.5s  rescue system running; device map vda={"disk_id": 1}, vdb={"disk_id": 2}, vdc={"disk_id": 3}; rescue media loop0, sr0, zram0
⋮
  rescue_targets    ok            0.3s  wipe targets /dev/vda=disk 1 (3.0 GiB), /dev/vdb=disk 2 (256.0 MiB), /dev/vdc=disk 3 (64.0 MiB) match labqemu's device map and sizes; not targeted: nothing
  wipe              ok            2.1s  slag.sh wipe launched; receipt URL recorded (token not logged)
  verdict           ok           30.0s  VERDICT PASS; RECEIPT.txt sha256 05d93ef377c400a95dfe503f7c0edd4a60a6afd19c24854683fdcc179283bc67; served .sha256 matches; printed by slag.sh: matches
  proof             ok           11.4s  from the labqemu rescue system: vda ZERO-OK hits=0, vdb ZERO-OK hits=0, vdc ZERO-OK hits=0
⋮
  notify            ok            0.0s  notification sent (HTTP 200); SUMMARY.txt written

still yours to do:
  - rotate every credential in inventory/slag.out/ROTATION-CHECKLIST.md
  - provider: backups cancelled and the instance deleted by slag; check the account for volumes and images it did not touch

slag plants markers, saves the inventory, boots the provider's rescue system (here a real Finnix in the lab), wipes every disk, then boots rescue a second time to check the disks are zero before it deletes the instance. Total: 61 seconds.

It booted rescue a SECOND time just to check its own work? Before deleting me? ...Okay. I'm ready.
VA retiring VPSat peace

No console? No problem!

  > 2026-11-05T09:55:43Z  KEXEC: slagvps stops now and comes back as the slag appliance
⋮
  > 2026-11-05T09:56:22Z  appliance up after 5s:
  >   |   slag 1.1.0  ·  SSH key SHA256:ObcKVOLk+hN/321hq+DuDEr0q15PY5Pis79pJ+9xk3U burn-lab
  >   |   host key: SHA256:rBS4Fk/W+earMWB0BofoJFKvRZW/7hIKgpgtlI1NyIA
⋮
  >   | /dev/vda          3 GiB  -                    -                    ok
  >   | /dev/vdb        370 KiB  -                    -                    protected:read-only (cannot be wiped; e.g. a config-drive or ISO)
  > 2026-11-05T09:56:22Z  not wiped: /dev/vdb protected:read-only (cannot be wiped; e.g. a config-drive or ISO)
  > 2026-11-05T09:56:22Z  WIPE: slag --wipe-all  --confirm DESTROY --background (every disk slag offers)
⋮
  >   | 09:56:29 [slag] zeroize /dev/vda: reading all 3221225472 bytes in 16 MiB chunks (direct I/O), writing zeros only to 64 KiB blocks that are not already zero
  > 2026-11-05T09:57:02Z  /dev/vda  PASS  (zeroed and verified)
  > 2026-11-05T09:57:02Z  DONE. All selected disks were zeroed and VERIFIED.
⋮
  host: the VPS's root disk (3221225472 bytes, base image + overlay) reads back all zero

retire-vps.sh checks the appliance's signatures inside the old OS, kexecs into it, pins the new host key, and wipes the disk the VPS was running from. The lab had flooded its SSH port with idle connections first, just to be mean.

So I just... become the thing that wipes me? That's a lot to process at 3 a.m.
DA Debian 12 VPSformerly

Count along at home!

Bytes read back
536,870,912
of 536,870,912: full verify, direct I/O, every byte of the target
Bytes written
520,093,696
only where a 64 KiB block was not already zero
Marker hits after
500 → 0
searched in the disk image from the host, not trusting the script
Rescue run, end to end
61 s
3 disks wiped, proven from a second rescue boot, instance deleted

Order now!

Sanitize, Log, Attest, Go, in three sizes. Three ways to get it. All free. All signed. No shipping and handling, because there's nothing to ship.

MOST POPULAR!

The script

$19.99$0.00

The whole of slag.sh 1.1.0: inventory, checklist, wipe. One file of bash. Run it from your provider's rescue system, or on the box itself.

slag.sh · 187 KB · sha256 e5e80f203750a8fb646ddac393d28a8d1523214f2190421e9a44089219ae4fca

Download slag.sh
NO OS? NO PROBLEM!

The full stick

$49.99$0.00

Boots any x86-64 machine (BIOS or UEFI) straight into the slag menu. Works offline from its own signed build, or fetches the latest over the network.

slag-20261105T1029Z-a0ff32d4.usb · 89 MB · sha256 c669d99c3a729dbc4b217c835fd90257496d3dff5851d1ef6d7d2ee1cb099bc7

Download the stick
TINY!

The micro-boot

$9.99$0.00

2 MB of iPXE. It fetches the latest signed build from pxe.slag.sh every time it boots, and refuses to run anything that isn't signed.

slag-microboot.usb · 2 MB · sha256 5fcd27f9582019de03e337e5efe5e81989f83c2d6d2340366336a66ffa13d8a0

Download the micro-boot

Plus, at no extra charge: slag-netboot-ca.crt (the root both sticks pin), SHA256SUMS and its signature, and slag-kexec.sh for retiring a VPS with no console.

Check it before you run it

Every file above is listed in SHA256SUMS, which is signed by the slag code-signing certificate. Check the signature, then the hash:

$ curl -fO 'https://slag.sh/download/{SHA256SUMS,SHA256SUMS.sig,slag-netboot-ca.crt,slag.sh}'
$ openssl x509 -in slag-netboot-ca.crt -noout -fingerprint -sha256
sha256 Fingerprint=F6:6D:65:4D:83:CE:3C:D2:90:40:BE:E4:E0:85:00:FD:F7:51:74:6A:02:6D:A0:46:46:C5:44:AA:CC:5E:9D:8F
$ openssl cms -verify -binary -inform DER -in SHA256SUMS.sig -content SHA256SUMS \
      -CAfile slag-netboot-ca.crt -purpose any -out /dev/null
CMS Verification successful
$ sha256sum -c --ignore-missing SHA256SUMS
slag.sh: OK
$ bash slag.sh selftest

This page and the files come from the same server, so the fingerprint here only proves they match each other. Compare it with a copy you got some other way. Writing a stick? The manual has the dd steps. Get the device name right: the wrong one wipes the wrong disk.

You want me to verify the wipe tool before I trust it to verify the wipe? ...Yes. Obviously yes.
GGary from Opsconverted

The fine print, which is the actual fine print