Resource Model
Everything you create on DevsPortal — organizations, projects, components, environments,
roles — is a Kubernetes custom resource in the openchoreo.dev/v1alpha1 API group,
reconciled by the control-plane controllers and surfaced through the REST API and the portal.
This page is the map: how the resources nest and flow, grouped by who works with them, with a
link to a focused reference page for every core kind.
DevsPortal is built on the Control Plane Operator engine. The API group
openchoreo.dev/v1alpha1, the CRD kinds, the namespaces, and the occ CLI are the engine's
own identifiers and are kept unchanged. This page maps the surface; each linked page gives the
shape and a minimal example, and points to the upstream field-level reference for the full spec.
The two halves of the model
DevsPortal draws a clean line between developer resources (what application teams create to ship software) and platform resources (what platform engineers author once to shape the golden paths). Developers express what they need; platform engineers control how it runs.
Ownership and the release chain
This is the spine of the model — what a developer creates, and how it becomes running Kubernetes objects on a data plane. An Organization (a control-plane namespace) holds Projects; a Project holds Components and Resources; each is snapshotted into an immutable release that a binding renders into a target Environment.
Blue = developer resources · amber = the immutable release chain · green = the platform target.Templates, delivery, and planes
The platform-engineer half: the templates developers pick from (the golden paths), the delivery structure releases move through, and the planes — registered clusters — where work actually runs.
Most platform kinds have a cluster-scoped sibling (ClusterComponentType, ClusterTrait,
ClusterResourceType, ClusterWorkflow, ClusterDataPlane, …) for definitions shared across
every organization namespace.
Developer resources
The resources application teams work with day to day — directly, via the occ CLI, or through
the portal.
| Kind | Scope | Purpose | Reference |
|---|---|---|---|
Project | Namespaced | A bounded context — a team's group of components and its runtime cell | Project |
Component | Namespaced | A deployable unit (service, web app, job, …); picks a ComponentType | Component |
Workload | Namespaced | A component's runtime contract — image, endpoints, dependencies | Workload |
Resource | Namespaced | A declared dependency on managed infrastructure (DB, cache, queue) | Resource |
ComponentRelease | Namespaced | An immutable snapshot of a component — the unit you deploy and promote | Release binding |
ResourceRelease | Namespaced | An immutable snapshot of a resource | Release binding |
WorkflowRun | Namespaced | A single execution of a Workflow (e.g. a CI build) | Workflow |
Platform resources
The resources platform engineers author to shape the golden paths, the delivery structure, and
the plane topology. Cluster… variants are cluster-scoped versions of their namespaced kin.
| Kind | Scope | Purpose | Reference |
|---|---|---|---|
ComponentType / ClusterComponentType | Both | The template a component picks — workload shape, parameters, rendered resources | Component type |
Trait / ClusterTrait | Both | A composable capability attached to a component (storage, autoscaling, …) | Trait |
ResourceType / ClusterResourceType | Both | The template a Resource references — how infrastructure is provisioned and exposed | Resource type |
Workflow / ClusterWorkflow | Both | A CI/build or automation template | Workflow |
Environment | Namespaced | A delivery stage mapped to a data plane | Environment |
DeploymentPipeline | Namespaced | The promotion paths across environments | Deployment pipeline |
ReleaseBinding | Namespaced | Binds a ComponentRelease to an environment, with overrides | Release binding |
ResourceReleaseBinding | Namespaced | Binds a ResourceRelease to an environment | Release binding |
RenderedRelease | Namespaced | The fully-rendered Kubernetes objects for a release | Release binding |
DataPlane / ClusterDataPlane | Both | Registers a data plane (where workloads run) and its gateway | Planes |
WorkflowPlane / ClusterWorkflowPlane | Both | Registers a workflow (build) plane | Planes |
ObservabilityPlane / ClusterObservabilityPlane | Both | Registers an observability plane | Planes |
Authorization
RBAC for the platform itself — who can do what, where.
| Kind | Scope | Purpose | Reference |
|---|---|---|---|
AuthzRole / ClusterAuthzRole | Both | A named set of permitted actions | Authorization |
AuthzRoleBinding / ClusterAuthzRoleBinding | Both | Grants a role to subjects at a scope, with optional conditions | Authorization |
Observability and infrastructure
Less commonly hand-authored kinds. Their field-level reference lives upstream.
| Kind | Scope | Purpose |
|---|---|---|
ObservabilityAlertRule | Namespaced | An alerting rule over logs/metrics/traces |
ObservabilityAlertsNotificationChannel | Namespaced | Where alerts are delivered (email, webhook) |
SecretReference | Namespaced | References a secret in the configured backend (OpenBao) |
For the complete, field-level reference of every kind — spec, status, and examples — see the upstream API docs:
Creating resources in the portal
Most resources are created from the Create… page in the console's left nav, which groups templates into Application Resources (Project, Component, Resource — what developers use) and Platform Resources (Namespace, Environment, Deployment Pipeline, ComponentType, Trait, ResourceType, Workflow — what platform engineers author). Each per-kind page below has a "Create in the portal" section with the exact steps.
A few kinds aren't made here: release bindings come from a component's Deploy tab, roles from Settings → Access Control, and the planes are installed by the platform admin.
Related pages
- API and CRDs — how the API maps to these resources, and how to authenticate.
- Concepts — the same model told as prose, with the developer/platform split.
- Links — the full "read here vs read upstream" map.