← All blog posts

Distributed hosting

Packfile-free routing relay

The main Worker stores discovery and health metadata, not Git packfiles. Repository bytes stream from selected independent origins over ordinary HTTPS.

Feature 02 of 72FeatureDistributed hosting & preservation3 min read
Abstract ForkMesh artwork for a packfile-free routing relay

Why it matters

Packfile-free routing gives ForkMesh a control plane without turning it into canonical Git storage. The Worker tracks signed endpoint registration, generalized health, integrity state, and selection metadata; repository bytes remain on independent mirror nodes.

Code becomes fragile when one hosted account, VM, or storage path is the only way to reach it. This routing boundary keeps repository bytes separate from the coordination layer.

How ForkMesh handles it

Desktop and organization nodes keep real Git mirrors. A proxied Cloudflare Tunnel terminates public TLS at each node’s loopback-only read gateway. The Worker verifies the node identity and signed repository proof, chooses a fresh healthy origin, issues a single-use request capability, and streams the response while the public ForkMesh URL stays unchanged.

Git clone, browse, raw files, search, and release downloads use normal HTTPS. Multiplayer sockets are reserved for small presence, chat, movement, and invalidation events. The Worker is service discovery and bounded failover, not repository or wallet custody.

Private or unknown repositories produce the same response for unauthorized callers. Private mirror bytes remain in opaque client-encrypted replicas and are never enabled by adding a public gateway path.

Where it fits

Use packfile-free routing when availability, clone routing, and preservation need to be handled by the mesh instead of by a single origin.

The claim is intentionally scoped: the Worker has no packfile or wallet-key custody, but it does store bounded coordination metadata. Chat is a separate relay-readable encrypted service with bounded message retention.