Self-Hosted Seed Nodes

Swarmfile is LAN-first: peers on the same network exchange file data directly and only fall back to cloud storage when no local copy is available. A self-hosted seed node extends that further by letting a machine you own - a NAS, an old workstation, a dedicated on-prem box - participate permanently in the swarm as a warm cache tier.

What a seed node is#

A seed node is just a machine running Swarmfile with seeding turned on. It joins the peer-to-peer swarm like any other client, but instead of only holding what a given user happens to have opened, it holds a persistent, shared cache that the rest of your office can pull from.

The practical benefit shows up for offices that already have a lot of project data sitting on local infrastructure: rather than every workstation re-fetching the same large files from cloud storage over and over, they fetch from the seed node on the LAN instead. That's faster, and it takes load off your egress and off the cloud fallback path entirely for anything the seed already holds.

One thing worth being precise about: on the standard managed (encrypted) tier, what the seed node caches is ciphertext - reading it still needs a decryption key fetched live from the hosted hub. A seed node is a warm, on-premises cache that speeds up your office and reduces cloud round-trips, not an independently readable offline copy of your data. See Data Portability & Offboarding for what that does and doesn't mean if the hosted service is ever unreachable.

Plan requirement#

Running a seed node requires the Pro plan or above.

It's also mutually exclusive with cloud-only mode: a mount can't be both a pure cloud-only client and a seed node at the same time. If a machine is configured for cloud-only operation, you'll need to turn that off before enabling seeding on it.

The hub also gates whether a self-hosted node is allowed to announce itself to the swarm at all, based on your org's plan entitlement. If a seed or NAS node is running under a plan that doesn't include the seeding entitlement, its announces are refused outright - a hard block rather than a warning you might miss in a log.

Enabling seeding#

For a machine that's already running the regular Swarmfile client, toggle seeding with:

swarmfile seed enable

and to turn it back off:

swarmfile seed disable

Both commands restart the engine to apply the change, so expect a brief interruption on that machine.

For a dedicated, headless machine - a NAS or a box that isn't otherwise being used as anyone's workstation - run the swarmfile-engine daemon directly instead of the tray app (the tray is just a GUI wrapper around the same engine), then run swarmfile seed enable against it exactly as above.

Don't confuse this with the standalone swarmfile-seed binary. Despite the name, it isn't a way to run a seed node - it's a one-shot admin tool that uploads a single local file straight into the hub and exits, useful for scripted bulk ingestion. See swarmfile-seed for its reference.

Deliberate LAN shard placement#

By default, which peer ends up holding which erasure-coded shard of a file is opportunistic - whoever happened to fetch or cache it holds it. That's fine for most teams, but it means fault tolerance is a byproduct of usage patterns rather than something you can rely on.

If you want guaranteed redundancy across your office instead - so that losing any single machine doesn't put a file's availability at risk - turn on deliberate placement:

swarmfile ec-placement enable

This rendezvous-hashes each shard across your office roster at a replication factor of 3, so every shard has three specific, deterministic homes on your network instead of landing wherever caching happened to put it. Like swarmfile seed enable, this restarts the engine.

Reach for this when you have a real office roster of machines and want predictable, guaranteed fault tolerance - not just "probably cached somewhere."

For context, files are erasure-coded Reed-Solomon 10+4 by default, and that scheme is adaptive: it exists primarily to mask WAN latency, so once two or more LAN peers are present for a project it can automatically back off from the full redundancy it uses over a pure cloud connection. Deliberate placement overrides that automatic behavior - when you explicitly want guaranteed office-wide redundancy rather than whatever the adaptive default decides, ec-placement takes the decision out of the engine's hands. For more on the underlying security and isolation model, see Security.

Inspecting shard placement#

To see exactly where a given file's shards actually live, run:

swarmfile shards <path>

This shows, per shard: which peer holds it, whether it's a data shard or a parity shard, and whether the machine you ran the command on currently holds a copy itself. It's the tool to reach for when you want to confirm deliberate placement actually took effect, or just to understand a file's current redundancy without guessing.