Project-level resources

A project groups environments and shared infrastructure under one organization. Besides workspaces, Loopback exposes several project-scoped services you should know about — they are not children of a single workspace by default.

Load balancers (project scope)

Project load balancers are managed front ends (IPv4/IPv6, algorithms such as round-robin or least connections) that can absorb traffic for services in the project.

Typical use cases:

One stable IP/DNS entry for multiple backends in different workspaces.
Shared ingress pattern before traffic reaches workspace-specific services.

You manage:

Load balancer create/update/delete (permission: project load balancer).
Targets — backend servers or addresses (project or workspace-scoped target routes exist).
Services — higher-level groupings or ports (terminology matches product routes).

Contrast: Workspace load balancers attach explicitly to one workspace (see Workspace load balancers).

Object storage (S3-compatible)

Object stores are buckets with credentials and usage tracking, billed and owned at organization but created under a project in the v2/v3 API split.

You can:

List buckets for a project.
Create buckets (name + kind / provider flavor — validated before creation).
Manage credentials (access keys) with dedicated permission.
Manage bucket policy documents where exposed.

The product may ship both v2 and v3 object-storage route families over time; capabilities converge on the same bucket + credentials + policy model.

Background reconciliation syncs usage and policies (see Reconciliation).

DNS zones (project scope)

Project DNS zones delegate DNS authority for a subdomain or pattern to the project team, separate from organization-wide record zones.

Use when:

Each project owns its own API hostname namespace.
You want blast-radius isolation for who may create records.

Workspace-scoped DNS zones also exist for finer delegation.

Monitoring (project scope)

Projects may host:

Monitoring objects — things you probe (HTTP, SSL, Kubernetes signals, host metrics, …).
Conditions — thresholds and operators on those probes.
Alert state — firing/cleared lifecycle.
Monitoring alerts — incident records for your team.

Permissions are split so you can grant read-only monitoring vs acknowledge alerts vs configure conditions.

Organization-level monitoring sources and notification channels feed into how alerts become tickets or chat messages.

See Monitoring & alerts.

Bundles (cross-cut)

Bundle repositories and bundle definitions are organization-scoped, but some bundle environment or revision routes also appear under project paths for UX convenience. The canonical ownership is still the organization.

See Bundles.

What still lives only under workspaces

Even though the project is the parent container, these are workspace-attached:

Hosts and scaling groups
Agent tokens and shell sessions
Kubernetes cluster features (unless purely project-level version listing helpers)
Workspace load balancers