Hi HN - Tom here, I built scsipub.
The short version: it's iSCSI targets on the public internet. Pick an image, get a block device. The free tier doesn't need a signup at all - iscsiadm -m discovery -t sendtargets -p scsipub.com and --login to iqn.2025-01.pub.scsipub:blank lands you a 64 MB scratch disk. There's a small catalog of OS images you can mount the same way.
The paid tier is where it gets less hobby-shaped: sessions survive disconnects, a single target can expose multiple LUNs, and SCSI-3 Persistent Reservations work end-to-end (REGISTER / RESERVE / RELEASE round-trip clean against sg_persist). That last bit is the cluster-storage primitive — Pacemaker, ESXi HA, and Windows MSCS all use PR for fencing — so you can actually back a 2-node failover cluster off a target on the public internet.
The post linked in the submission is the architectural decision log: Ranch 2.x listeners, a BEAM process per session, COW overlays with per-sector bitmaps, Caddy-managed Let's Encrypt for the iSCSI-TLS port without restarting the listener, and the four open-iscsi quirks that each cost me few hours. There's a section on what we're deliberately not solving (multi-region, RDMA, etc.) so you know the scope.
Two companion projects ship as embedded sub-sites on the front page — one turns an ESP32-S3 into a wireless iSCSI-to-USB bridge, one lets a Raspberry Pi 3/4/5 netboot directly from a target. Both linked from the landing page under "Hardware initiators".
Happy to answer any questions about the protocol, the deployment, or the BEAM-side design choices.
I dislike neg comments but really curious - I can see the how but absolutely clueless about the why. Running a block device over a high latency WAN link seems like a terrible idea, what's the use case?
I've answered some down the tree a bit for the inspirational use case for it.
Since I built it, I've started seeing it as a hammer for many nail-like problems - I think that would die down over time;
but.. I have my ESP32 "pendrive" that's net-synced. I have used it to install OS through UEFI-built-in initiator. I have added iSCSI targets to my windows laptop machine (and VMs) - while you need to deal with disconnects and reconnects, it actually works well enough.
It is a terrible idea, that doesn't sound as terrible for odd use-cases. But yes, the ESP32 over 2.4GHz over 3G internet is slow as molasses (20-30kB/s) - but when the alternative is 0.. or walking over there with a laptop, it works OK.
I don’t have a use case, but I was thinking the same thing. But then I realized that the WAN speeds available now are equal to or faster than the LAN speeds I had when I had reason to use iSCSI. And things worked out decently well then, so I can see this being useful.
https://scsipub.com/blog/an-esp32-as-a-network-attached-usb-...
Apparently, exposing small USB sticks to industrial equipment that uses it for loading/saving configs and screenshots and being able to 'network' it with shared iSCSI drives.
"The scope writes screen_001.png to “USB”; the file appears in a directory on my desktop, in the iSCSI overlay. Combined with a dropbox-style sync I no longer need to walk over and pull the stick out."
Quite brilliant and clever, if you ask me.
I'm wondering now about using an ESP32 stick and an iSCSI image of Windows install media - that could make for some fun in-house computer imaging setups.
That was indeed one of the main drivers for it! ESP32 (especially with 2.4GHz WiFi latencies) is not super well suited for OS installs, but... many UEFI firmwares (and some network drivers!) will let you boot iSCSI directly.
The other one is the Raspberry Pi{3,4,5} iSCSI shim linked there as well - I have a bunch of them for a bunch of paying clients CI/CD kinds of work, and I wanted these to boot from network, not from microSD.
Both of these projects could've benefited from a public demo iSCSI endpoint, we have http://example.com and whateveryouwant@mailinator.com - why not iSCSI
I saw the mention of BEAM in the article, and immediately wanted to know more. But I don't have any specific questions unfortunately...