Platform Engineer Overview
The platform engineer sits in the middle of the three DevsPortal personas. The platform admin builds and runs the infrastructure — the planes, TLS, identity, registry, observability. The developer consumes the platform — they build, deploy, promote, and operate apps. You, the platform engineer, are the bridge: you take a freshly-installed platform and turn it into something a hundred developers can use safely without a ticket.
You do two distinct kinds of work:
- Set up the tenancy. Carve the platform into organizations, projects, and teams; decide who can do what, where; and record who owns what. This is the multi-tenant structure every app lands in.
- Author the golden paths. Publish the menu developers pick from — the ComponentTypes, Traits, ResourceTypes, and Workflows that encode your organization's approved patterns, plus the Environments and DeploymentPipelines they promote through. This is where "the objects and services for developers" actually get made.
DevsPortal is built on the Control Plane Operator engine. Identifiers like
openchoreo.dev/v1alpha1, the occ CLI, and resource kinds such as ComponentType,
Trait, ResourceType, Workflow, Environment, and DeploymentPipeline are unchanged
engine internals. Examples throughout this section target the Fedshi instance
(https://console.idp.fedshi.com).
Where you sit between the other two personas
| Persona | Owns | Works with |
|---|---|---|
| Platform admin | The infrastructure — control/data/workflow/observability planes, TLS, identity, registry | Helm, cluster config, the platform's plumbing |
| Platform engineer (you) | The tenancy and the golden paths — orgs, projects, access, ComponentTypes, Traits, ResourceTypes, Workflows, Environments, Pipelines | occ, openchoreo.dev/v1alpha1 CRDs, the Access Control UI |
| Developer | One app — Components, Workloads, Endpoints, Resources, releases | The console, occ, the golden paths you published |
The dividing line is intent: the admin makes the platform exist, you make it usable for many teams, and developers use it. A clean handoff in both directions — admin to you, you to developers — is what keeps the platform fast and safe at the same time.
What you author: the two halves
Everything in this section falls into one of two buckets.
Tenancy & access
The multi-tenant structure developers work inside. You typically set this up once per organization and once per team, then it runs itself.
| Page | What you do |
|---|---|
| Orgs, projects, and tenancy | Set up the control-plane namespaces, organizations, and projects that isolate teams into bounded contexts |
| Onboard a team | The step-by-step runbook to bring a whole team onto the platform |
| Roles and access | The RBAC model — roles, bindings, scopes, and CEL conditions |
| Ownership model | Catalog ownership and the backstage.io/owner annotation |
| Governance and guardrails | The guardrails that keep teams on golden paths |
Authoring golden paths
The templates and delivery structure developers pick from. These are the schema- and template-driven abstractions — parameters validated against OpenAPI v3 JSON Schema, resources rendered with CEL — that let a developer self-serve without ever seeing raw Kubernetes.
| Page | What you author |
|---|---|
| Environments and pipelines | The Environments (dev/staging/prod) and DeploymentPipelines developers promote releases through |
| Component types | ComponentTypes — the golden-path workload templates developers build components from |
| Traits | Traits — composable capabilities (storage, caching, monitoring) developers attach to components |
| Resource types | ResourceTypes — templates for managed infrastructure (databases, queues, caches) developers declare as Resources |
| Workflows | Workflows — CI/build and automation templates developers run |
And one page ties it all together:
| Page | What it shows |
|---|---|
| First team app | A worked end-to-end example — a team using the tenancy and golden paths you set up to ship a real service |
How the two halves fit together
A developer's whole experience is the product of both halves of your work. When they create a component, they:
- Land in a project you carved out (tenancy) — an isolated cell, scoped by the roles you bound to their team.
- Pick a ComponentType you authored (golden path) — which constrains the workload shape and the Workflows they may build with.
- Attach Traits and declare Resources from the ResourceTypes you published.
- Promote the release through the DeploymentPipeline across the Environments you defined — gated by the conditions and governance you set.
Done well, the developer never files a ticket and never produces something non-conforming, because the easy path is the compliant path. That is the contract this section exists to help you build.
Where to start
- New to the platform's structure? Begin with Orgs, projects, and tenancy.
- Bringing a team on right now? Jump to Onboard a team.
- Building the menu developers pick from? Start with Component types, then Traits, Resource types, and Workflows.
- Want to see the whole arc first? Read First team app.