Skip to main content
This guide helps you migrate from: to the combined Enterprise chart:

What Changed

  • chainloop-ee combines both distributions in one chart.
  • Some configuration is no longer required as it’s handled by the chart itself
  • Most Platform keys under frontend, backend, global, and nats remain in the same sections.
  • Most OSS keys under controlplane and cas remain in the same sections.
  • Database configuration is centralized in top-level chainloopDatabase and platformDatabase.
  • Development dependencies (vault, dex, postgresql) are now wired for the combined install path.

Top-Level Ingress Defaults

chainloop-ee introduces a top-level ingress block that works as a global fallback for component ingress settings.
  • Supported keys: ingress.enabled, ingress.hostname, ingress.ingressClassName, ingress.annotations, ingress.tls.
  • Precedence: component-specific values (frontend.ingress.*, backend.ingress.*, controlplane.ingress.*, cas.ingress.*, and *.ingressAPI.*) override top-level values when both are set.
  • Rendering behavior: ingress resources render when either the component ingress is enabled or top-level ingress.enabled is true.
  • Hostname derivation from top-level ingress.hostname:
    • frontend: app.<hostname>
    • backend: app-api.<hostname>
    • controlplane: cp.<hostname>
    • controlplane API: cp-api.<hostname>
    • cas: cas.<hostname>
    • cas API: cas-api.<hostname>
  • ingress.annotations and ingress.tls are reused as shared defaults (for example, cert-manager annotations and HTTPS defaults).

Migration Checklist

Make sure to get familiar with Removed Keys section before you start copying your values.
  1. Start from Enterprise edition chart values.yaml. Refer to README.md for more details about configuration options.
  2. Copy your Platform customizations (frontend, backend, nats) into the same sections.
  3. Copy your OSS customizations (controlplane, cas, secretsBackend, casJWT*) into the same sections.
  4. Apply the key remaps from the tables below.
  5. Run helm template / helm upgrade --dry-run and validate rendered secrets, DB endpoints, and ingress hosts.

Platform -> chainloop-ee Mapping

Mostly Unchanged Paths

These sections are largely drop-in:
  • global.*
  • frontend.*
  • backend.*
  • nats.*

Required Remaps

Notable Default/Model Changes

  • frontend.service / backend.service / backend.mcpService now include additional service fields (clusterIP, nodePorts, externalTrafficPolicy, etc.).
  • frontend and backend include explicit pod/container security context defaults in chainloop-ee.
  • ingress.* at top-level acts as a shared default for all component ingresses.

OSS -> chainloop-ee Mapping

Mostly Unchanged Paths

These are generally reusable as-is:
  • controlplane.*
  • cas.*
  • secretsBackend.*
  • casJWTPrivateKey
  • casJWTPublicKey

Required Remaps

Removed Keys

Use this section as a quick reference for keys that existed in Platform or OSS values but are not present in chainloop-ee as the same path.

Vault in chainloop-ee

chainloop-ee vendors the Vault subchart (chainloop-ee/charts/vault/values.yaml) and only overrides a small subset at top-level vault.*:
  • vault.server.command
  • vault.server.args
  • vault.server.config
  • vault.server.extraVolumes
  • vault.server.extraVolumeMounts
  • vault.extraDeploy
If you previously customized standard Vault chart keys, keep using the same key paths under vault.* in chainloop-ee.

Minimal Migrated Values Example

Validation Steps

  • Render manifests:
    • helm template chainloop-ee ./deployment/chainloop-ee -f <your-values>.yaml
  • Dry-run upgrade:
    • helm upgrade --install chainloop-ee ./deployment/chainloop-ee -f <your-values>.yaml --dry-run
  • Verify:
    • ingress hosts/TLS per component
    • secretsBackend configuration
    • machineIdentityIssuers and chainloopAuthPassphrase configuration
    • All custom configuration about autoOnboarding, restrictOrgCreation, keylessSigning, etc.
    • casJWTPrivateKey and casJWTPublicKey configuration

References