Service providers and ecosystems

Loopback separates tenant-facing resources (projects, workspaces, buckets) from operator-managed integration profiles that hold cloud accounts, Git applications, and DNS credentials. Two product concepts tie that together: service providers and ecosystems.

Service providers

A service provider describes how Loopback talks to an external system:

• A provider family key (examples you may see in pickers: Hetzner Cloud, IONOS DCD, GitHub, GitLab, partner stacks).
• A capability discriminator such as object storage, compute, load balancer, git.
• Secret references for usernames, passwords, tokens - not raw credentials in API payloads.
• Optional URL overrides when the deployment routes microservices non-default.

Administrative HTTP surfaces list and create providers; ordinary tenant users consume them indirectly when buckets or clusters bind to a provider profile.

Ecosystems

Ecosystems group vendor choices (the same families as above, plus others your operator may enable) with links to the service provider profiles used for compute and object storage. They express “this deployment’s Hetzner stack” (or another vendor bundle) as one named configuration for pool selection and catalog pricing.

How customers should think about it

You rarely edit ecosystems yourself. Instead, you observe effects:

• Object storage regions available in pickers.
• Compute pool matching for workspace creation.
• Bundle Git connectivity after OAuth.

Ask your operator which ecosystem your organization runs on if you need data residency or isolated cloud accounts.

Related reading

• Compute provider model
• Object storage
• Git OAuth and webhooks
• Technical verification