Concepts

DevsPortal draws a clean line between developer abstractions (what application teams work with) and platform abstractions (what platform engineers define). This separation is the heart of the product: developers express what they need; platform engineers control how it runs.

For exhaustive, field-by-field definitions, see the upstream concept reference and the API and CRDs reference. For a visual map of every resource and how it nests — with a reference page per kind — see the Resource Model.

Developer abstractions

These are what a developer ("builder") interacts with day to day.

Concept	What it is
Project	A bounded context — a logical grouping of related components that implement a business capability (mirrors a domain). Establishes ownership, team boundaries, and runtime isolation (each Project becomes a cell).
Component	A deployable unit of software (microservice, web app, worker, scheduled job). References a ComponentType that governs how it deploys, plus parameters and attached Traits.
Workload	The runtime contract of a component — its container image, the endpoints it exposes, and the dependencies it needs.
Endpoint	A network interface a component exposes (HTTP, gRPC, GraphQL, WebSocket, TCP, UDP), each with a visibility level (external / internal / project).
Dependency	A declared link from a Workload to another component's Endpoint or to a Resource. The platform resolves addresses and injects them, and wires up network policy.
Resource	A declared dependency on managed infrastructure (database, queue, cache, object store). A thin reference to a ResourceType; its outputs are injected into consuming workloads.
WorkflowRun	A single execution of a Workflow (e.g. a CI build) with specific parameters.

The developer hierarchy

Project (a team's bounded context → a runtime cell)
└── Component (a deployable unit; picks a ComponentType)
    ├── Workload (image + endpoints + dependencies)
    │   ├── Endpoint (exposed interface + visibility)
    │   └── Dependency → another Endpoint or a Resource
    ├── Trait (0..N composable capabilities)
    └── ComponentRelease (immutable snapshot)
        └── ReleaseBinding (per Environment) → RenderedRelease (on a Data plane)

See it rendered

The Resource Model shows this hierarchy as a diagram, plus the platform-side templates, delivery structure, and planes — and links to a reference page for each kind.

Platform abstractions

These are what a platform engineer defines, usually once, to create golden paths.

Concept	What it is
ComponentType	A template governing how components deploy (workload kind, parameter schema, resource templates, allowed workflows). Encodes deployment patterns and governance.
Trait	A composable capability (storage, caching, monitoring…) that augments a component. Schema-driven; can be attached multiple times.
ResourceType	A template for provisioning managed infrastructure — its parameter schema, the Kubernetes manifests it emits, its outputs, and retention policy.
Workflow / ClusterWorkflow	A template for CI builds and automation (parameter schema + an Argo Workflow spec). Component workflows build components; generic ones do provisioning, testing, GitOps.
Environment	A stage in delivery (dev, staging, prod). Maps to a Data plane and defines a deployment target.
DeploymentPipeline	Declares the promotion paths across environments — including parallel paths and gates.
DataPlane / WorkflowPlane / ObservabilityPlane	Registrations of the clusters that run workloads, builds, and observability.
AuthzRole / AuthzRoleBinding	Role-based access control — who can do what, where (also cluster-scoped variants).

Most platform abstractions have a cluster-scoped sibling (ClusterComponentType, ClusterTrait, ClusterResourceType, ClusterWorkflow, ClusterAuthzRole…) for definitions shared across all namespaces.

Schema- and template-driven

ComponentTypes, Traits, ResourceTypes, and Workflows are schema-driven (parameters validated against OpenAPI v3 JSON Schema) and template-driven (resources generated with CEL — Common Expression Language). This is how a platform engineer encodes a golden path that developers can use safely without seeing the underlying Kubernetes.

How a deployment flows

Putting it together — the lifecycle from intent to running app:

1. Developer creates a Component in a Project, choosing a ComponentType and setting parameters; defines its Workload (image, endpoints, dependencies).
2. A build (Workflow → WorkflowRun) produces the image, or a prebuilt image is used.
3. The component is snapshotted into an immutable ComponentRelease.
4. A ReleaseBinding binds that release to an Environment, applying env-specific overrides, and produces a RenderedRelease — the final Kubernetes resources — on the target Data plane.
5. The same release is promoted through the DeploymentPipeline (dev → staging → prod).
6. Logs/metrics/traces flow to the Observability plane and back to the portal.

Next: skim the Glossary, or jump into the Developer guide or Operator guide.