Platform hierarchy and onboarding
The current data model differs from the retired four-level “organization → team → cluster → project” diagram. In current APIs, Team is the top-level tenant and is presented as an organization in parts of the console.
Current hierarchy
Organization / Team (tenant, membership, tier, and limits)
├── Project (pipeline intent, stage, selectors, and revision history)
│ └── Environment binding(s) (registered Kubernetes cluster identity)
└── Members and project access
Environment
└── Allowed namespace targets
└── NexoProxy and generated namespaced workloads
| Object | Purpose |
|---|---|
| Organization / Team | Top-level tenant, membership boundary, tier, and optional contractual overrides |
| Project | Logical pipeline configuration and deployment intent |
| Environment | Managed Kubernetes cluster binding with its own identity, status, labels, version pin, and runtime inventory |
| Namespace target | Administrator-approved Kubernetes namespace eligible for project deployment |
| Deployment | A revision applied to an eligible environment and namespace |
An environment record is project-associated in the persisted model, while current selector migration can permit controlled reuse across eligible projects. Do not assume that a cluster must contain only one project or that a project can target every environment in the tenant.
Roles and access
| Role | Intended scope |
|---|---|
| Admin | Tenant-wide membership, billing/configuration, and administrative access |
| Manager | Project-level membership and management for assigned projects |
| Editor | Modify pipeline configuration and perform permitted deployments |
| Viewer | Read-only configuration, metrics, logs, and status |
Server-side authorization and project assignments are authoritative. UI visibility alone is not an authorization decision.
Example structure
Acme (organization/team)
├── payments-api (project)
│ ├── payments-dev (environment; labels env=dev, team=payments)
│ │ └── namespace target payments-dev
│ └── payments-prod-eu (environment; labels env=production, region=eu)
│ └── namespace target payments-prod
└── analytics (project)
└── analytics-prod (environment)
└── namespace target analytics
Names are illustrative. An environment is a registered cluster binding, not a MongoDB database target record.
Projects and deployment targeting
A project owns pipeline intent and stage-specific selectors. Environment labels decide which registered environments are eligible. Namespace selectors separately constrain deployment inside those environments. This separation prevents a project editor from turning an environment match into arbitrary namespace access.
Pipeline reuse should use supported revision, export, or configuration workflows. Legacy “import from team project,” YAML import/export, and type-the-project-name confirmation behavior are not documented as stable contracts.
Onboarding flow
- Create or join the tenant. Establish the top-level organization/team and membership.
- Create a project. Define purpose, stage, and initial pipeline intent.
- Create an environment. Register the Kubernetes target and assign controlled labels.
- Install Nexo Edge. Use the authenticated, version-pinned console command and the environment-bound token.
- Wait for heartbeat. Verify environment identity, runtime inventory, and release compatibility.
- Configure namespace targets. Administrators define allowed namespaces and selectors.
- Preview and deploy. Validate desired state, publish a revision, and verify the active graph.
The retired “sandbox first, cluster later” journey may still inform UX, but it does not prove that every account receives an offline sandbox or that a trial is commercially available.
The retired Manager Helm example using app.nexo.io and an inline connect token is not
an installation contract. Use the authenticated console command and supported Secret
handling instead.
Entitlement limits
Canonical product limits are documented in Pricing and entitlements. In particular, environment caps are finite for every tier, including Enterprise. The retired table that listed unlimited Business and Enterprise clusters, unlimited projects, and separate team counts is not authoritative.