Skip to main content
HetznerDigitalOceanLinodeVultr
Node provisioning explains how cloud provisioning works: the join-token flow it drives, the cloud-init script, status polling and the known gaps per provider. This page is the short version: which providers are supported, what credential each needs, and the fastest path to a running node.

​
Providers at a glance

GCP has no federation mode. The reason, and the three AWS credential modes, are in node provisioning.
Servers are not deleted for youEvery provider bills by the hour while the server exists. levelrail-cli nodes delete removes the node record, not the VM, so delete the server at the provider too. See Node provisioning for cost and known gaps.

​
Add a node

1

Store the provider credential

Once per provider. Paste or pipe the credential when prompted, so it stays out of shell history.
2

Pick a region and size

List what your account offers rather than guessing. The ids in the next step (fsn1, cx22) are Hetzner examples only.
The dashboard’s Add node wizard lists both live.
3

Provision and wait for ready

Repeat show until the status is ready. Status moves through creating, booting and enrolling. Add --role build to make it a build node.
The same shape works for DigitalOcean, AWS, Azure and GCP: store the credential with --provider <name>, then provision. AWS, Azure and GCP fold account detail (key and secret or role ARN, resource group, service account) into the credential itself. See required token scopes.

​
Next steps

Node provisioning

How it works, auth modes, cost and known gaps.

Multi-node

Placement, drain, certificates and the mesh once the node is online.
Last modified on October 12, 2026