Compute provider model

Compute providers are Loopback’s abstraction for where servers come from. They hold credentials, optional organization and workspace binding, and provider-specific metadata (regions, projects, API endpoints). Hosts are the machines you see in a workspace; they are created by pairing a compute profile (a productized SKU) with a provider that can fulfill it.

This page is written for buyers, solutions architects, and compliance teams who need to understand what is fixed today versus what the architecture allows tomorrow.

What defines a compute provider in the product

A compute provider profile includes at minimum:

A provider family key (for example Hetzner Cloud, Hetzner Robot, IONOS DCD on deployments that ship those integrations today).
Secrets by reference - API tokens and passwords live in the secret subsystem, not as plain text in customer-visible payloads.
Optional organization binding - when set, the provider is docked to that tenant. When unset, the profile can participate in operator pools depending on process.
Optional workspace binding - some flows pin a provider to a workspace after claiming (for example autoscale and host-create resolution).
An internal vs customer-visible distinction on administrative surfaces - distinguishes operator-managed inventory from tenant onboarding flows.

Additional provider families may exist in broader builds; the safe statement for procurement is: only families your operator has published as supported are contractually meaningful for you.

Docked on, docked off, and shared pools (how customers experience it)

Docked to your organization
When an organization binding is present, the provider’s credentials are yours. Host and scaling operations resolve providers scoped to your tenant (and sometimes workspace), so usage and access align with RBAC and billing.

Operator pool (“docked off” from any tenant initially)
Deployments can maintain shared pools that are handed to a customer when a workspace is created or when hosts need capacity, without publishing raw credentials to tenants. The exact commercial meaning (included hours, trial, bring-your-own-cloud) is contract and operations, not something the repository alone proves.

Self-onboarded credentials
Administrative APIs can register providers with your API keys and your cloud projects. Conceptually this is bring-your-own-cloud: Loopback executes automation as those credentials. OpenStack or another private cloud would require a new provider integration registered in the compute factory, matching API operations, and allow lists on the relevant routes - the architecture uses a registry pattern for that reason.

Execution architecture (why expansion is incremental)

The reconciliation scheduler and execution worker both use a factory that maps provider family strings to implementation classes (Hetzner Cloud, Hetzner Robot, IONOS DCD in the shipped code today). Adding self-hosted OpenStack or another hyperscaler means:

Implementing a class that speaks that cloud’s API (create server, delete server, attach networks, and so on).
Registering it in the factory under a new family name.
Extending administrative and customer-facing validation so the new family is allowed where appropriate.
Shipping compute profiles that encode the right SKU parameters for that backend.

Until those steps ship in your deployment, the safe statement is: Loopback’s architecture is multi-provider; your deployment’s supported list is what the operator publishes.

What ships in this repository today

Registered engines in the task stack include:

hetzner_cloud
hetzner_robot
ionos_dcd

Administrative provider creation accepts the same three families on standard deployments.

Host action helpers (power, rescue, and similar) register provider-specific classes for those same families.

Compute profiles and pricing

Compute profiles are catalog rows that describe a machine class, price display, and provider parameters (server type, location, and so on). They are global objects marked active. When you order a host, you choose a profile; Loopback resolves the compute provider profile that can satisfy it for your organization and workspace.

Billing agreement overrides can adjust displayed pricing; the exact mapping is deployment configuration.

Operational implications for due diligence

Credential isolation: Provider secrets are referenced, not inlined, in the provider profile.
Blast radius: A compromised provider token affects every host that provider provisions until rotated.
Exit: You can detach from Loopback automation while keeping servers at the hyperscaler by using the cloud’s native console - subject to network and identity dependencies documented in networking and workspace guides.

Compute providers and ordering hosts (operational walkthrough)
Tenancy and scope
Hosts and scaling
Technical verification