Skip to main content

Multi-tenancy & isolation

Loha is multi-tenant by design. One Loha installation serves many workspaces, and a workspace is the unit of isolation. Builds, secrets, logs, and network traffic in one workspace cannot reach another.

This page describes the guarantees, not the implementation.

What "isolated" means​

Each workspace is its own sealed environment:

  • Compute. A build pod for workspace A runs on the same cluster as a build pod for workspace B, but each runs in its own boundary with its own quota and its own filesystem. Neither pod can see the other.
  • Secrets. Secrets are scoped to the workspace (and optionally further scoped to a single repository inside it). A pipeline in workspace A cannot read a secret from workspace B. Reads are denied at the secret store, not just at the application layer.
  • Logs and artifacts. Build logs, uploaded artifacts, and built container images live in per-workspace storage. The dashboard, the API, and the build pods themselves cannot cross the boundary.
  • Network. Each workspace has a default-deny ingress policy. Cross-workspace network calls are blocked by default.

Roles inside a workspace​

Within a single workspace, Loha enforces role-based access. Four roles, scoped to the workspace:

RoleCapabilities
OWNERFull control. Manage members, plan, repos, secrets. Delete the workspace.
ADMINManage repos, secrets, members. Cannot change the plan or delete the workspace.
MEMBERTrigger builds, view logs, manage own API keys.
GUESTRead-only access to builds and dashboards.

Role changes are audit-logged. Removing a member revokes their sessions and API keys immediately. See Workspace settings & lifecycle.

For the operational guide (invitation flow, role-change rules, what happens when a member is removed), see Workspaces → Members & roles.

Resource quotas​

Each workspace has a quota envelope tied to its plan:

  • CPU and memory caps for concurrent builds
  • Maximum concurrent builds
  • Storage caps for ephemeral build volumes and artifacts
  • Per-job default and maximum CPU/memory

If a build would exceed the quota, the request is rejected before the build starts and the dashboard surfaces a clear error. There is no way to silently exceed your plan.

For the exact resource sizes, the timeout ceiling, and .loha.yml configuration caps, see Limits.

What's not yet hardened (honest)​

  • Default-deny egress. Build pods can currently reach the public internet for dependency fetches. Per-workspace egress allowlists are on the v1.1.0 roadmap.
  • Production secret-store hardening. The secret store currently runs in a dev configuration in some environments; production-mode hardening is tracked on the roadmap.