Joining as a provider
The shape of onboarding a Flare node — four steps, and what each one is for.
Contributing a machine to Kumulus means running a small agent on it that takes work from the network. This page describes the shape of that process. Step-by-step instructions will follow once the flow settles.
1. Describe the machine
In the provider console you say what the machine is — processor, memory, storage, whether there is a GPU — and, separately, what you are willing to host.
Those two questions are not the same, and the second one is yours to answer. Capable hardware does not imply consent to run anything; see capability is not consent. What you choose here decides what gets installed, so it is worth answering deliberately.
2. Run one install command
The console gives you a single command containing a registration token. It installs a small Kubernetes distribution, the Kumulus agent, and the networking the node needs.
Two things worth knowing about this step:
- No inbound ports and no public IP. The node reaches out to the network, never the reverse, so an ordinary home connection behind a router works.
- You never handle network credentials. Connectivity is provisioned on our side and the machine receives only a scoped token. Nothing asks you to paste an API key, and you should be suspicious of any instruction that does.
3. The machine reports back
When the install finishes, the machine reports what was actually found on it — architecture, whether hardware virtualisation is present, GPU, free disk, which runtimes installed.
The console shows this next to what you declared, and that comparison is the useful part. A machine that claimed a GPU and has none, or that offered strongly isolated workloads on hardware that cannot provide them, will not receive that kind of work — and the mismatch is visible immediately instead of surfacing weeks later as work that never arrives.
A gap does not fail the install. A machine that cannot do one thing is still good capacity for everything else, and losing the whole node over one missing feature would be the worse outcome.
4. Work starts arriving
From here the node is a candidate. What it receives depends on what it can do (MOSAIK) and how it compares to other providers at the moment work needs placing (BIDEEW).
A new node is usually in the Flare tier. Nothing needs re-registering if that changes later — tiers follow what a machine reports, not a label chosen at signup.
If something looks wrong
A node can report itself healthy while being unable to do useful work. If yours shows as online but has been given nothing for a while, that is worth raising rather than waiting out.
Discord is the fastest route to someone who can look.