> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qodo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure Kubernetes addons with values files

> Compose customer-owned Helm values for KEDA, external secrets, and ingress, with explicit enable and disable behavior.

* **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](https://docs.qodo.ai/examples/on-prem/values-examples.zip)
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:

```yaml my-values.yaml theme={null}
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](https://docs.qodo.ai/on-prem/external-secrets/aws.md)**
>
> IRSA values, with an EKS Pod Identity alternative.

> **[Google Cloud Secret Manager](https://docs.qodo.ai/on-prem/external-secrets/google-cloud.md)**
>
> Workload Identity values and project references.

> **[Azure Key Vault](https://docs.qodo.ai/on-prem/external-secrets/azure.md)**
>
> 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:

```yaml external-secrets-values.yaml theme={null}
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](https://docs.qodo.ai/on-prem/external-secrets.md).

### 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:

```yaml eso-disabled-values.yaml theme={null}
# 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](https://docs.qodo.ai/examples/on-prem/values-examples.zip)
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:

```yaml keda-cpu-values.yaml theme={null}
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](https://docs.qodo.ai/examples/on-prem/values-examples.zip)
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](https://docs.qodo.ai/on-prem/keda-autoscaling.md).

## 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](https://docs.qodo.ai/on-prem/ingress.md).

Keep Qodo's base layer first and your chosen overrides after the customer
file. This example enables ESO consumption and KEDA with AWS ingress:

```bash theme={null}
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](https://docs.qodo.ai/on-prem/qodo-on-prem-helm-chart-overview.md): Follow the release installation and upgrade procedure.
* [Configure ingress](https://docs.qodo.ai/on-prem/ingress.md): Select and verify your provider's network configuration.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.