Configure Kubernetes addons with values files

Deployment model: On-premises
Configuration reference: Qodo Helm chart 7.22.0, product 3.0.

Use this page when your platform team already operates KEDA, External Secrets Operator (ESO), and an ingress controller. Keep your environment values and optional overlays in Git so you can review and repeat each deployment. Qodo’s chart configures workloads and routes; your platform team owns the cluster operators, cloud identities, certificates, and external services. Download and extract the values examples archive into your deployment workspace. It contains the KEDA on/off overlays, three ESO provider files, and three ingress provider files. Replace the marked placeholders before using a file. Keep only your selected overlays in your installation’s deployment command.

Choose your overlays

Integration	Enabled configuration	Disabled or externally managed configuration
KEDA	Set the selected component’s `scaledObject.enabled: true` and `autoscaling.enabled: false`	Set `scaledObject.enabled: false` and a fixed `replicaCount`; verify the KEDA HPA is removed
ESO	Use your ESO release’s `extraObjects` list to create provider resources and fixed-name Kubernetes Secrets	Reuse an approved store by omitting its creation, or retain credentials and transfer ownership before removing synchronization
Ingress	Set `global.ingress.enabled: true` and select your controller’s values	Set `global.ingress.enabled: false` only when customer-managed routing or OpenShift Routes serve every required host

There is no Qodo secretStore.enabled, eso.enabled, or keda.enabled switch. The settings above reflect the shipped chart and the separate ESO operator chart. Disabling Secret generation is an Argo CD deployment choice, not an ESO toggle.

1. Keep your environment values

Start with the customer values from your release bundle. For an external PostgreSQL server, the relevant part of my-values.yaml looks like this:

my-values.yaml

global:
  baseDomain: qodo.example.com
  externalDatabase:
    enabled: true
    host: postgres.example.internal
    adminUser: qodo_admin
    existingSecret: qodo-db-admin
    sslMode: require
  entra:
    name: Corporate SSO
    type: entra
    clientId: REPLACE_WITH_APPLICATION_CLIENT_ID
    tenantId: REPLACE_WITH_DIRECTORY_TENANT_ID
    existingSecret: qodo-entra-idp
  llm:
    openaiBaseUrl: https://llm-gateway.example.internal/v1
postgres:
  enabled: false

Replace the endpoints and identifiers with yours. Keep passwords, API keys, TLS private keys, and the IdP client secret in your approved Secret manager. Retain the other settings from your customer values. The database and all required Secrets must be available before the installation starts.

2. Enable external secrets before Qodo

Choose one complete provider values file for your existing ESO release:

AWS Secrets Manager

IRSA values, with an EKS Pod Identity alternative.

Google Cloud Secret Manager

Workload Identity values and project references.

Azure Key Vault

Workload Identity values and vault references.

Apply that file to the operator’s release through your platform team’s existing deployment process. Wait for the store and ExternalSecret to be ready before installing Qodo. Do not put bootstrap ExternalSecrets in Qodo’s extraObjectsDict: Qodo’s pre-install database Jobs run before ordinary resources in that release are created. The Qodo overlay stays the same for all three providers:

external-secrets-values.yaml

global:
  externalDatabase:
    existingSecret: qodo-db-admin
  generatedSecrets:
    render: true
postgres:
  enabled: false

ESO supplies qodo-db-admin.POSTGRES_PASSWORD. Direct Helm installations continue generating and reusing internal Qodo credentials. Argo CD requires the separate complete external-credential inventory and deployment layer. For more information, see Manage Qodo secrets with External Secrets Operator.

Stop synchronizing without losing credentials

Keep the database password and target name unchanged. First arrange for your approved replacement owner to retain and manage qodo-db-admin, and confirm the database still accepts it. Remove this integration’s ExternalSecret, SecretStore, and ServiceAccount entries from the ESO values only after no remaining consumer needs them. Preserve all unrelated extraObjects entries. If this example was the only entry set, the resulting operator overlay is:

eso-disabled-values.yaml

# ESO release values. Removes this example's objects; keeps the operator.
extraObjects: []

The examples use creationPolicy: Orphan and deletionPolicy: Retain, so removing the ExternalSecret does not garbage-collect its target Secret. Confirm your GitOps pruning policy also preserves that Secret. Disabling synchronization does not revert the database password or remove Qodo’s need for the Secret. Keep the Qodo Secret-reference overlay above.

3. Enable or disable KEDA

Download keda-enabled-values.yaml in the values archive for the Platform API and Git event review worker. Replace the broker management URL and confirm its credential Secret exists before applying it. For a CPU-only setup, include just the platform block:

keda-cpu-values.yaml

platform:
  autoscaling:
    enabled: false
  scaledObject:
    enabled: true
    spec:
      minReplicaCount: 1
      maxReplicaCount: 4
      triggers:
        - type: cpu
          metricType: Utilization
          metadata:
            value: "70"

To return to fixed replicas, apply keda-disabled-values.yaml in the values archive last. It disables both example scalers and preserves the fixed replicaCount settings in your customer values. Set those counts explicitly before disabling scaling, then confirm the ScaledObjects and KEDA-owned HPAs disappear and the Deployments converge to your selected counts. For upgrade maintenance, pause scaling instead of disabling it. For more information, see Autoscale Qodo with KEDA.

4. Choose ingress and apply Qodo values

Select one provider’s ingress values and prepare its certificate and DNS. For more information, see Configure ingress. Keep Qodo’s base layer first and your chosen overrides after the customer file. This example enables ESO consumption and KEDA with AWS ingress:

KUBE_CONTEXT="REPLACE_WITH_YOUR_CONTEXT"
NAMESPACE=qodo

helm upgrade --install qodo ./qodo-onprem \
  --kube-context "$KUBE_CONTEXT" --namespace "$NAMESPACE" \
  -f qodo-onprem/onprem-base.yaml -f my-values.yaml \
  -f external-secrets-values.yaml \
  -f keda-enabled-values.yaml -f ingress-aws-values.yaml

For Google Cloud, use ingress-google-cloud-values.yaml and append the release’s qodo-onprem/values-gke.yaml. For Azure, use ingress-azure-values.yaml. If you disable KEDA, keep the enabled file in that same order and append -f keda-disabled-values.yaml last. ESO’s eso-<provider>-values.yaml belongs only to the operator release. Helm merges maps but replaces lists. A later triggers or extraObjects list replaces the earlier list; it does not append. Render the final values before applying them. Confirm Secret readiness, completed migration Jobs, ready Deployments, a successful SSO login, and a real Git provider webhook that produces a completed code review.

Next steps

Deploy Qodo using Helm: Follow the release installation and upgrade procedure.
Configure ingress: Select and verify your provider’s network configuration.

Helm charts

Operations

Git Integration

Configure Kubernetes addons with values files

Choose your overlays

1. Keep your environment values

2. Enable external secrets before Qodo

AWS Secrets Manager

Google Cloud Secret Manager

Azure Key Vault

Stop synchronizing without losing credentials

3. Enable or disable KEDA

4. Choose ingress and apply Qodo values

Next steps

​Choose your overlays

​1. Keep your environment values

​2. Enable external secrets before Qodo

AWS Secrets Manager

Google Cloud Secret Manager

Azure Key Vault

​Stop synchronizing without losing credentials

​3. Enable or disable KEDA

​4. Choose ingress and apply Qodo values

​Next steps

Choose your overlays

1. Keep your environment values

2. Enable external secrets before Qodo

Stop synchronizing without losing credentials

3. Enable or disable KEDA

4. Choose ingress and apply Qodo values

Next steps