Compute providers and ordering hosts
Compute providers answer the question where a server is born: which cloud account, which API, which region. Compute profiles answer what shape of server you want (vCPU, memory, disk class, and provider-specific type ids). Hosts are the durable records Loopback tracks after ordering: lifecycle, networking overlay membership, and Kubernetes join metadata when applicable.
For architecture and roadmap language (docking, pools, adding OpenStack-class providers), read Compute provider model first. For on-prem / OpenStack / Proxmox style conversations, read Provider extensibility and on-prem. For agent + fleet framing, start at Agent and fleet management.
This page stays close to operational behavior in typical deployments.
What you configure versus what operators configure
Customer-facing flows center on choosing profiles and creating hosts inside a workspace. Credential-bearing compute provider rows are often created through administrator APIs or operator runbooks, then linked to your organization or workspace. The code also supports claiming providers that start with no organization (shared pool rows) when a workspace is created or when hosts are first ordered - your contract defines whether that represents included capacity, trial, or BYOC onboarding.
Shipped provider engines
The reconciliation scheduler and execution worker compute stacks ship integrations for these families today:
| Provider family | Role |
|---|---|
| Hetzner Cloud | Virtual instances via Hetzner Cloud API |
| Hetzner Robot | Dedicated servers via Robot API |
| IONOS DCD | IONOS Compute Engine (DCD) with region metadata on the provider profile |
Administrative provider onboarding in standard builds is limited to those three families. Additional vendors may exist in preview or custom builds; treat them as not active until your operator confirms they are registered in your deployment.
Compute profile catalog
Profiles are global catalog entries. When you list profiles for a workspace, Loopback may:
- Filter to profiles compatible with the resolved provider for that workspace.
- Annotate pricing using billing agreement overrides where configured.
- Call live provider APIs for datacenter availability (Hetzner Cloud paths in the codebase).
Choosing a profile is how you stay declarative (“two large workers in nbg1”) while Loopback handles imperative cloud calls.
End-to-end: ordering a host
- Workspace exists and your role includes host create (see Access control).
- List compute profiles exposed for the workspace.
- Create host with hostname, compute_profile id, optional metadata.
- Loopback selects or claims a compute provider profile for your organization/workspace (per provider family) and enqueues provider-specific automation: provision, OS bootstrap, agent installation hooks, and overlay network enrollment when managed networking is enabled.
- For Kubernetes workspaces, worker nodes eventually join the tenant cluster (for example via kubeadm-style flows in automation).
Failure modes
- Capacity errors from the cloud → host may land in error with provider message.
- Mismatched profile and credentials → validation failure before money is spent.
- Quota or commercial limits → surfaced as API errors.
Security and compliance notes
- Secrets (API tokens, passwords) are stored as
Secretdocuments referenced from the provider row, not as cleartext fields in API responses. - Rotate cloud tokens on the same cadence you would for any automation account with server creation rights.
- Data residency follows the regions you select on providers and profiles (IONOS region metadata, Hetzner location ids, and so on).
Kubernetes control planes versus worker hosts
Workspace metadata can distinguish where Kubernetes control planes run (management pool selection by provider type) from where worker nodes run (host ordering). They may share a provider family or not, depending on operator architecture. Always map this during cost modeling and blast-radius reviews.