In mid-2026 Crankk paused operations after the Kadena blockchain it depended on collapsed. Their cloud went down and has not come back. If you own one of their multi-miner gateways, you may have noticed something worse than a dead dashboard: the device itself started freezing.
Mine did. The web panel hung on an infinite spinner, and after a while SSH stopped answering too. A power cycle bought a few minutes before it locked up again. This is what was actually happening, and how I got the box stable — still mining Helium, which does not depend on Crankk at all.
Symptoms
- Local web panel loads forever, never renders.
- SSH accepts the connection but never returns a prompt, or times out.
- The device answers ping while being otherwise unusable.
- A power cycle restores access for a few minutes, then it degrades again.
The tempting conclusion is a dying SD card or a failing power supply. It was neither.
Diagnosis: it was RAM, not the network
These gateways ship with 2 GB of RAM and no swap. Mine was running about ten miner containers at once. When memory filled up, the kernel started thrashing — constantly evicting and reloading pages it still needed.
If you can get a shell during the boot window, this is what it looks like:
# Load average and memory pressure
uptime
free -m
# Which container is eating the memory
docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}"On my box the numbers were unambiguous: load average 29, 12 MB of RAM free, and 53% iowait with kswapd pegged. At that point sshd cannot even complete a key exchange, which is why the device looks dead on the network while still replying to ping.
Why you cannot just SSH in and fix it — once memory is exhausted, the SSH daemon has no room to fork a session. You have to pull the power for about ten seconds and work fast during the boot window, before the containers start and fill the RAM again. Have your commands ready to paste.
Culprit one: the Grass container
Grass mines bandwidth by launching Chromium. Several browser processes, on a 2 GB box, with no swap. It alone was consuming most of the available memory.
docker stop Grass
docker rm -f Grass
docker rmi sicnull/grassLoad dropped from 29 to 1.18 immediately, and free memory went from 12 MB to roughly 1470 MB. The panel came back.
Culprit two: the Crankk panel is now a memory leak
A few hours later the device started thrashing again, with Grass long gone. Something was consuming over 1 GB in 10 to 15 minutes, steadily.
It was the crankk container — the web panel itself. With Crankk’s cloud dead, its Node process sits in an infinite retry loop trying to reach an endpoint that will never answer, and those retries leak memory. The dashboard is not just useless now; it is actively killing the device.
Stopping it is reversible, so this is not a destructive fix:
# Stop it AND stop it coming back on reboot
docker update --restart=no crankk crankk-update
docker stop crankk crankk-updateThe memory trace after pausing it, sampled every two minutes:
10:26 avail=1603MB load=2.81
10:28 avail=1614MB load=0.86
10:30 avail=1613MB load=0.73Flat memory, load collapsing. That is what a fixed leak looks like.
Result
Load average went from 29 to 0.7, and free RAM from 12 MB to about 1600 MB. The device has been stable since.
- Still running: the Helium miner, the LoRa packet forwarder, the ChirpStack gateway bridge, and the lighter bandwidth miners.
- Paused: the Crankk panel and its updater.
- Removed: Grass.
The important part: Helium keeps mining normally. It talks straight to the Helium network and never needed Crankk’s cloud. Losing the panel costs you the local dashboard, nothing else.
Expected side effect — with the panel paused, the local web UI on port 17080 stops responding. That is correct behaviour, not a new fault. Manage the device over SSH instead.
Bringing the panel back if Crankk ever returns
ssh crankk@192.168.1.50 # replace with your device's address
docker update --restart=unless-stopped crankk crankk-update
docker start crankk crankk-updateNote that on these gateways the crankk SSH user is root, and its password is the one set from the web panel, not a separate account. If your panel is paused you cannot change it, so make sure you know it before you stop the container.
Two things worth knowing about these boxes
The root filesystem is read-only. If you need to drop a script somewhere, write it to /tmp, which is a RAM-backed tmpfs. It will not survive a reboot — which is also a reason not to keep anything important there on a box with 2 GB of RAM.
Your Helium identity is safer than you think. The private key lives in an ECC608 secure element, referenced in the config as something like:
GW_KEYPAIR=ecc://i2c-2:96?slot=0It is not a file on disk. You cannot export it, and you cannot accidentally delete it — short of physically destroying the board. Still, back up your settings.toml and your hotspot identity somewhere off the device:
scp crankk@192.168.1.50:/etc/helium_gateway/settings.toml ~/backups/helium/The lesson
A 2 GB gateway with no swap cannot run every miner you can install on it. The failure mode is not a clean error message — it is the whole device becoming unreachable, which looks like hardware failure and sends you chasing the wrong problem for a day.
If you add a heavy container back, cap it so it cannot take down the host with it:
docker run --memory=256m --memory-swap=256m ...And if your Crankk box has been unstable since the shutdown: it is almost certainly the panel. Stop it, and get your Helium mining back.