The wizard's "Mine on this machine too?" choice (local_miner.enabled) tells the operator to
install RigForge on the host afterwards. On DIY that is a real instruction. On the APPLIANCE it
is not: the machine ships with no shell in release images, and the supported management surface
is the dashboard. An appliance operator who answers Yes gets a stratum announcement pointing at
a rig that can never exist — the promise cannot be kept as shipped.
RigForge is deliberately NOT containerized (it owns host tuning: MSR, HugePages, governor —
the #78 spike recorded hugepages as load-bearing), so "just run an xmrig container" is a
different, weaker product than what Yes implies.
Options, in rough order of honesty-per-effort:
- On the installation medium, keep the question but state the real requirement inline: mining
on the appliance itself needs ssh.enabled (Advanced) + a manual RigForge install — or hide
the choice on the appliance entirely and document "the appliance coordinates; rigs mine."
- A pithead-managed miner container as an explicit lesser mode ("mine without host tuning —
lower hashrate"), so the appliance can honor Yes without a shell.
- Full RigForge-on-appliance integration (host-tuned, updated with the OS image) — the real
answer if appliance-local mining matters as a product feature.
Today the fleet story is the good one and should be the marketed path: install RigForge on
each RIG, point it at the stratum address from the credentials card, manage from the
dashboard's Workers view (list, hashrate, one-click worker upgrades since v1.10, telemetry).
The wizard's "Mine on this machine too?" choice (local_miner.enabled) tells the operator to
install RigForge on the host afterwards. On DIY that is a real instruction. On the APPLIANCE it
is not: the machine ships with no shell in release images, and the supported management surface
is the dashboard. An appliance operator who answers Yes gets a stratum announcement pointing at
a rig that can never exist — the promise cannot be kept as shipped.
RigForge is deliberately NOT containerized (it owns host tuning: MSR, HugePages, governor —
the #78 spike recorded hugepages as load-bearing), so "just run an xmrig container" is a
different, weaker product than what Yes implies.
Options, in rough order of honesty-per-effort:
on the appliance itself needs ssh.enabled (Advanced) + a manual RigForge install — or hide
the choice on the appliance entirely and document "the appliance coordinates; rigs mine."
lower hashrate"), so the appliance can honor Yes without a shell.
answer if appliance-local mining matters as a product feature.
Today the fleet story is the good one and should be the marketed path: install RigForge on
each RIG, point it at the stratum address from the credentials card, manage from the
dashboard's Workers view (list, hashrate, one-click worker upgrades since v1.10, telemetry).