Why it matters
Headless mirror nodes gives ForkMesh a concrete mechanism for turning servers and VMs into non-GUI preservation nodes. One command turns any Linux box or VM into a mirror node. The installer registers its account, syncs its repositories, and starts serving, no GUI required.
Code disappears from a network when one hosted account, one VM, or one storage path becomes the only way to reach it. In ForkMesh, headless mirror nodes addresses that need at the feature level, keeping the behavior close to the repository instead of buried in a detached hosted layer.
How ForkMesh handles it
ForkMesh handles headless mirror nodes through the same split it uses across the product: nodes keep real Git mirrors, while the Worker coordinates signed HTTPS discovery, health, presence, account lookup, and clone routing.
The behavior is intentionally narrow: One command turns any Linux box or VM into a mirror node. The installer registers its account, syncs its repositories, and starts serving, no GUI required. The Worker helps find and route a live host, but it is not canonical Git storage.
Where it fits
Use headless mirror nodes when availability, clone routing, and preservation need to be handled by the mesh instead of by a single origin.
It pairs with the rest of Distributed hosting & preservation because Headless mirror nodes keeps turning servers and VMs into non-GUI preservation nodes connected to the repository, its signatures, and the nodes that serve it.