Pithead v1.14.0

[1.14.0] - 2026-07-23

Added

• Node LAN exposure switches (#760) — the serving side of the remote-node modes. monero.zmq_lan_access
  publishes monerod's ZMQ feed on the LAN (with the existing rpc_lan_access, everything a remote
  P2Pool needs), and tari.grpc_lan_access publishes the bundled Tari base node's gRPC, so one
  stack's synced nodes can serve other stacks running monero.mode/tari.mode: remote (#103).
  Both default off, publish loopback-only otherwise, and flipping either to the LAN is a
  host-confirmed destructive change. The Tari gRPC and ZMQ feeds carry no authentication —
  trusted networks only (see the remote-node sections in docs/configuration.md).
  Upgrading: monerod's 18083 and the Tari node's 18142 are now published on the host from
  this release — on loopback unless you turn a switch on. If something else on the host already
  holds either port (a hand-rolled socat forward serving another machine is the likely one, since
  that is what these switches replace), free it first: Docker refuses to start the container on a
  taken port, and the upgrade stops there.
• Remote Tari node (#103). tari.mode: remote merge-mines against a Tari base node running
  elsewhere instead of the bundled one: set tari.remote.host (required) and
  tari.remote.grpc_port (default 18142). Remote mode skips the bundled tari container, its
  memory cap, and payout confirmation. The remote node's mining-template
  RPC is request-scoped, so one node can serve several pithead stacks at once, each with its own
  wallet — a shared node for a fleet or household is the intended pattern. The gRPC link stays
  plaintext and unauthenticated (p2pool has no way to speak TLS or auth to it), so use a node you
  trust: its operator, or anyone on the network path, can silently redirect Tari rewards. Monero
  mining is unaffected either way. LAN/trusted-network only for now — a .onion remote is a
  follow-up. See Configuration › Remote Tari node.
• Dual-distribution plan (#77/#78): the architecture decision record for shipping Pithead as a
  curl-installed Compose stack, a flashable immutable appliance (Debian 13 + Rugix A/B, Podman
  Quadlet), and a git clone — one release manifest across all three. Dev doc only, no behaviour
  change. See docs/dev/dual-distribution-plan.md.

Changed

• Operator-facing text no longer carries this project's internal issue numbers (#755). A message
  you read in the terminal or the dashboard is now written for you, not for the tracker; the
  numbers stay in the source comments, where they explain why the code is the way it is. A lint
  guard (make lint) keeps them out from here on.
• upgrade's help text describes what it actually does — re-render generated config, then rebuild
  and restart — for both source checkouts and extracted release bundles, instead of naming only
  git pull (#757).

Fixed

• No onion for a node that isn't here (#103). With monero.mode or tari.mode: remote, Tor
  kept publishing that node's inbound hidden service even though the container never starts, so the
  stack advertised an onion address that accepted connections into nothing. Each node's hidden
  service is now published only while that node runs locally; P2Pool's is unchanged, since p2pool
  always runs. Switching a node back to local republishes it at the same address — the key never
  left tor.data_dir — and a stack first set up in remote mode mints the address on the apply that
  makes the node local.
• Config validation closes two gaps a dashboard-committed config could otherwise walk into: a
  data_dir containing : is rejected (it would forge a third field in the container's volume
  mount and could silently turn a data mount read-only), and a tari.wallet_address containing
  whitespace is rejected instead of mining to a wrong address. A remote node's host and ports are
  validated once, at parse time, and reused verbatim by the renderer — the value that passes
  validation is the value that ships.

Ingredients — Pithead v1.14.0

• Version: 1.14.0
• Commit: 4285d37475cdae0f2829b7afbd0fcc8a1fe9285f
• Built: 2026-07-24T03:36:54Z

Published images (ghcr.io/p2pool-starter-stack, tags v1.14.0 + latest)

• ghcr.io/p2pool-starter-stack/pithead-tor:v1.14.0
  • digest: ghcr.io/p2pool-starter-stack/pithead-tor@sha256:d1e3898f54979503a00bccfb767716ccdb6fe3da2fc4db6c890fd4fb97cc1ff1
• ghcr.io/p2pool-starter-stack/pithead-monero:v1.14.0
  • digest: ghcr.io/p2pool-starter-stack/pithead-monero@sha256:c027181ba1105445d0164d325fa36b74c963c5151acae0ab7ce01deee76aca6a
• ghcr.io/p2pool-starter-stack/pithead-p2pool:v1.14.0
  • digest: ghcr.io/p2pool-starter-stack/pithead-p2pool@sha256:5d2c99f819d9bc4e50cc076d76e1eb276b55d42fd4f129ec0cf028cc523fceee
• ghcr.io/p2pool-starter-stack/pithead-xmrig-proxy:v1.14.0
  • digest: ghcr.io/p2pool-starter-stack/pithead-xmrig-proxy@sha256:79a59556a856ad91ad962d134758d3d0a362994383551f7f35de8977675f7ae7
• ghcr.io/p2pool-starter-stack/pithead-dashboard:v1.14.0
  • digest: ghcr.io/p2pool-starter-stack/pithead-dashboard@sha256:9445bcbcbe4baab53dcc943a306058c3f62c9cde9bab71e0cc7cddbfbde21d35

Upstream component pins

• p2pool: v4.16
• monerod: v0.18.5.0
• xmrig-proxy: 6.26.0
• tor base: alpine:3.24@sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b
• tari: quay.io/tarilabs/minotari_node:v5.3.1-mainnet@sha256:824fd6ec21d618805317d7eede374d6782906eeae17d2fc8aaad4df6205f94e0
• caddy: caddy:2.11.4@sha256:cfeb0b281bc44a5a51fecde39e9e577c60d863c0b6196e6bbdf58fd00960887f
• docker-socket-proxy: tecnativa/docker-socket-proxy:v0.4.2@sha256:1f3a6f303320723d199d2316a3e82b2e2685d86c275d5e3deeaf182573b47476