Tenancy model

OrbitalReg is single organization per deployment. One running instance — one Postgres database, one set of admin settings, one license — serves exactly one organization. There is no concept of "Org A" and "Org B" sharing the same instance with isolated data.

If you need to isolate multiple organizations from each other, run one OrbitalReg deployment per organization. This is a deliberate architectural boundary, not a missing feature — see Why this boundary exists below.

What the boundary actually is

Inside a single organization, isolation happens at the Project level, one layer down from the deployment itself:

Deployment (= one organization)
  └── Projects (isolated governance boundary)
        └── Repositories (local | remote-proxy | virtual)
              └── Artifacts

A project is the top-level unit teams actually interact with day to day — see Core concepts for the full data model. Projects have their own retention policy, license policy, quarantine policy, and membership list, and a non-admin user only sees the projects they have an explicit role binding for. That gets you team-level and product-level isolation within one deployment.

What it does not get you is instance-level tenant isolation: every project in a deployment shares the same Postgres database, the same S3 bucket (distinct key prefixes, not distinct buckets), the same license, and the same admin surface (Admin → * pages, SCIM provisioning, SAML/OIDC configuration). An org_admin role sees and can act on every project in the deployment; there is no "org boundary" role above that.

Role bindings recap

Role bindings (reader / developer / admin) are either project-scoped or org-wide (project_id IS NULL in role_bindings) — "org-wide" here means "every project in this deployment," which is consistent with the single-org model: there is only one org for a binding to be wide across.

Why this boundary exists

Multi-org SaaS — one shared instance serving many unrelated customers with hard data isolation between them — is explicitly out of scope. Supporting it would require, at minimum: per-org database/schema isolation (or row-level security across every table), per-org S3 bucket or KMS-key isolation, per-org licensing, and a tenant-admin role that sits above org_admin without being able to see other tenants. None of that exists today, and retrofitting it onto a single-org data model is a substantial architectural change, not a config flag.

For a self-hosted registry — the deployment model OrbitalReg targets — this is the right tradeoff: one instance per organization mirrors how self-hosted infrastructure is normally provisioned (one cluster, one namespace, one set of secrets, one org), and keeps the blast radius of a misconfigured policy or a compromised admin credential contained to that one organization.

If your use case is "one platform team hosting isolated registries for many downstream customers," the supported pattern today is one OrbitalReg deployment per customer (same Helm chart, same operator, separate values/namespace/database per instance) — not one shared deployment with per-customer projects.