Skip to main content

Release Binding

The release chain is how DevsPortal separates what you deploy from where and how it runs — and it's what gives you safe promotion and reliable rollback. A Component is snapshotted into an immutable ComponentRelease; a ReleaseBinding binds that release to one Environment (applying per-environment overrides) and produces a RenderedRelease — the final Kubernetes objects on the target data plane. Resources follow the same shape with ResourceRelease and ResourceReleaseBinding.

Component  →  ComponentRelease  →  ReleaseBinding  →  RenderedRelease
Resource   →  ResourceRelease   →  ResourceReleaseBinding  →  RenderedRelease

The key idea: the same release is bound to each environment. Promotion doesn't rebuild — it points the next environment at the release you already verified.

ReleaseBinding​

Binds a ComponentRelease to one environment and carries that environment's overrides.

KindReleaseBinding
ScopeNamespaced · Audience Platform engineer / developer
FieldDescription
spec.owner.projectName / componentNameThe component this binding belongs to
spec.environmentThe target environment name
spec.releaseNameThe ComponentRelease being bound
spec.stateActive (deployed) or undeployed
spec.componentTypeEnvironmentConfigsOverrides for ComponentType environment-config parameters (replicas, resources)
spec.traitEnvironmentConfigsPer-trait-instance overrides, keyed by instanceName
spec.workloadOverridesWorkload-level overrides (env vars, file mounts)
apiVersion: openchoreo.dev/v1alpha1
kind: ReleaseBinding
metadata:
  name: cart-api-production
  namespace: fedshi
spec:
  owner:
    projectName: checkout
    componentName: cart-api
  environment: production
  releaseName: cart-api-5d7f658d9c
  state: Active
  componentTypeEnvironmentConfigs:
    replicas: 3
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"

ComponentRelease​

An immutable snapshot of everything about a component — its type, parameters, traits, workload, and image. A new one is created only when something actually changes; it's the unit you deploy and promote. Rollback is just binding an earlier ComponentRelease.

KindComponentRelease · Scope Namespaced · created automatically

ResourceRelease​

The resource-side equivalent: an immutable snapshot of a Resource plus its ResourceType, created automatically when the resource changes.

KindResourceRelease · Scope Namespaced · created automatically

ResourceReleaseBinding​

Binds a ResourceRelease to an environment — the resource-side analog of a ReleaseBinding. Unlike component releases, these are created explicitly (by a platform engineer or GitOps).

FieldDescription
spec.resourceReleaseRefThe ResourceRelease being bound
spec.environmentNameThe target environment
spec.resourceTypeEnvironmentConfigsPer-environment overrides (size, memory)
spec.retainPolicyPer-environment override of the ResourceType's default (Delete/Retain)

RenderedRelease​

The fully-rendered Kubernetes objects for a binding — the Deployments, Services, HTTPRoutes, StatefulSets, Secrets, and NetworkPolicies that get applied to the target data plane. Created by the ReleaseBinding (or ResourceReleaseBinding) controller; you rarely touch it directly.

KindRenderedRelease · Scope Namespaced · controller-managed

Create in the portal​

Release bindings aren't made from the Create… page — they're produced by deploying and promoting on a component's Deploy tab:

  1. Open the component (e.g. shortener-web in the url-shortener system) and go to the Deploy tab — it shows a card per environment in pipeline order.
  2. Click Deploy on the first environment to bind the latest ComponentRelease there; click Promote to advance the same release to the next stage.
  3. Use the gear icon on a card to set per-environment overrides.

ComponentRelease, ResourceRelease, and RenderedRelease are created automatically — you don't author them. Full guide: Deploy and promote.

See also​