Platform journey — end-to-end flow

This page is the narrative spine of Loopback from a customer’s perspective. Read it once to understand how pieces connect; use the linked domain guides for depth.

1. Account registers

A person (or automation acting for a person) creates a Loopback account: identity, email, password, and optional strong authentication (2FA, WebAuthn). The platform may gate self-service registration with a system flag; if disabled, accounts are created by an operator.

You get: a login that can be invited into one or more organizations.

See Accounts.

2. Account participates in one or more organizations

An account is not the same as an organization. One human can:

• Belong to multiple organizations (e.g. consulting firm + client tenant).
• Have different roles in each.

Organizations are the billing and data boundary: projects, workspaces, and most infrastructure references roll up to an organization id.

See Organizations and Members & roles.

3. Organization creates projects

Inside each verified organization you create projects. A project is a stable grouping for:

• Workspaces (Kubernetes or bare metal).
• Project-scoped load balancers (optional pattern: shared edge in front of multiple workspaces).
• Object storage buckets (S3-compatible) for that project.
• DNS zones delegated at project level.
• Monitoring configuration (monitoring objects, alerts) attached to the project where the product exposes it.

Multiple projects per organization are first-class (e.g. Production / Staging / Internal).

See Project resources.

4. Projects hold workspaces (and other resources)

Workspaces always live under a project. Each workspace is either:

• Kubernetes — dedicated control plane (tenant cluster) via Kamaji on operator-managed infrastructure, or
• Bare metal — focus on servers, network, agents, without that Kubernetes control-plane product path.

Workspaces are not the only project children: load balancers and object stores can be created at project scope as well, depending on your architecture.

See Workspaces.

5. Base functionality: agents on servers

Loopback assumes machines you care about run a small Loopback agent (installed via a downloadable bootstrap script). The agent:

• Maintains heartbeat and version compatibility with the platform.
• Enables remote operations (maintenance, metrics collection hooks, integrations depending on deployment).
• Works with reconciliation jobs that expect agent reachability.

Before hosts are fully useful, you typically:

1. Create agent tokens in the workspace (scoped credentials).
2. Run the install script on the server with that token.
3. Let the platform indoctrinate or register the host into the workspace fleet.

See Agents & shell access.

6. Host ordering through compute providers and profiles

You do not “buy a server” as an abstract button without context. The usual pattern is:

1. Operator attaches cloud or dedicated-server credentials as compute providers (organization/workspace context depending on flow).
2. Loopback exposes compute profiles — machine types with pricing (and availability checks against the provider API where implemented).
3. You create a host in a workspace by choosing a hostname, compute profile, and optional metadata.
4. Background tasks talk to Hetzner Cloud, Hetzner Robot, IONOS DCD, etc., to provision or allocate the machine, then bootstrap it (e.g. kubeadm join for Kubernetes workers).

That is compute fleet orchestration from your perspective: declarative “I want this profile in this workspace”, imperative work happens asynchronously.

See Compute providers & ordering and Hosts & scaling.

7. Kubernetes deployment through Kamaji

When you create a Kubernetes workspace, Loopback provisions a tenant control plane using Kamaji on a management Kubernetes cluster. You receive:

• API server DNS name under the operator domain pattern.
• Admin and OIDC kubeconfig paths (permission-gated).
• Automatic installation of catalog components (Kubernetes applications) in a defined order.
• Optional integration secrets (e.g. cloud controller) when your workspace still binds provider credentials.

Worker nodes are hosts that join the cluster (after ordering via compute profiles).

See Kubernetes install flow and Kubernetes user features.

8. Automatic reconciliation

Loopback continuously reconciles entities: workspaces, hosts, agents, DNS zones, object stores, load balancers, organizations, monitoring objects, update deliveries, and more. Reconciliation means:

• Periodic health checks and state alignment.
• Reactions to triggers (config changed, heartbeat missing, alert acknowledged).
• Retries with backoff where configured.

You see this as status fields updating, stuck resources recovering, or errors surfacing when cloud APIs fail.

See Reconciliation & background behavior.

9. Security mechanisms

Defense in depth includes:

• Account authentication (password, 2FA, WebAuthn) and optional API keys for automation acting as the user.
• Organization RBAC — granular permission keys on organization, project, and workspace resources (who may order hosts, download kubeconfig, change maintenance, etc.).
• Workspace API keys and agent tokens — machine-scoped secrets separate from human login.
• Kubernetes — OIDC to API server, optional admin kubeconfig, cluster RBAC binding for IdP groups.
• Audit hooks on sensitive routes (kubeconfig access, maintenance changes, host create, etc.— deployment-dependent exposure in UI).

See Access control & permissions and Access & identity.

10. Compute fleet orchestration (summary)

Putting it together:

• Scaling groups can maintain a desired count of hosts for a workspace (auto-replace, scaling decisions — see workspace scaling guide).
• Maintenance windows control OS updates and Kubernetes patch toggles.
• Kubernetes upgrades are explicit version moves validated against a supported upgrade graph.

Visual summary

Account
  └── Memberships → Organization(s)
        ├── Billing, domains, DNS, bridges, monitoring sources, notifications
        ├── Roles & invites
        └── Project(s)
              ├── Object storage
              ├── Load balancers (project-level)
              ├── DNS zones
              ├── Monitoring / alerts (project scope)
              └── Workspace(s)
                    ├── Type: kubernetes | baremetal
                    ├── Agent tokens → Agent on each host
                    ├── Hosts (via compute profiles / providers)
                    ├── Scaling groups
                    ├── Workspace load balancers / targets / services
                    ├── Kubernetes: API, kubeconfig, catalog apps, upgrades
                    └── Shell sessions, power, host firewalls, …

Related reading

• Full documentation index
• Glossary