Organizations — tenant, verification, and structure

An organization is Loopback’s tenant: the legal and operational container for projects, billing, DNS, integrations, and member access. This guide is for customer admins who own or administer an organization.

Why organizations matter

Billing rolls up here (invoices, payment methods, spending limits).
Data isolation — other organizations cannot see your projects or infrastructure metadata.
Policy — verification status, blocked/waitlist states, and capability limits apply at org scope.
Integrations — Git OAuth (GitHub/GitLab) for bundles, monitoring sources, notification channels, and more attach here.

Multiple organizations per person

A single account can be a member of many organizations with different roles in each. That supports:

Agencies managing client tenants.
Separate legal entities under one login.

Switching organization in the product changes every list view: projects, workspaces, billing.

Organization status (what blocks you)

Verification / business status

Common values:

In setup — onboarding incomplete; many write actions disabled.
Verified — normal operations (create projects, Kubernetes workspaces, etc.).
Pending / blocked / waitlist — manual review; expect creation APIs to refuse with “entity status” errors.

Resource state

Organizations also have active / inactive / deleted lifecycle. Deleted orgs should be invisible in normal use.

What belongs to an organization (inventory)

Use this as a checklist of features your admins may manage:

People & access

Memberships — which accounts belong to the org.
Invites — pending invitations.
Roles — named permission bundles assigned to members.
Authentication providers — optional IdP configuration for Loopback login (distinct from Kubernetes OIDC).

Money & contracts

Payment methods (e.g. card, SEPA).
Invoices and cost summaries (where exposed).

Naming & trust

Domains — domain registration records Loopback tracks for DNS workflows.
DNS records and DNS record zones at organization scope (patterns delegated to projects/workspaces).
Network bridges — connectivity constructs between network segments (operator-dependent use).

Delivery & Git

Bundles — repositories, bundle definitions, environments, revisions, deployments, build/deploy operations.
GitHub / GitLab OAuth app wiring for bundle repositories.

Observability

Monitoring sources — catalog of probe/agent sources for monitoring.
Notification channels — where org-level alerts may be delivered.

Projects

Projects — required parent for workspaces and many resources.

Not every deployment turns on every integration; if a menu is missing, the feature may be off or enterprise-only.

Capabilities and limits

Organizations carry soft limits (e.g. maximum hosts) and limitations flags (e.g. whether SEPA payment is allowed). Hitting a limit surfaces as limit-reached style errors — resolve with your operator or plan upgrade.

Creating the first project

Once verified, an admin creates a project (name + metadata). Projects are mandatory parents for workspaces and anchor project-scoped load balancers, object storage, and DNS zones.

See Project resources.