Infrastructure requirements

On-premises

Minimum Kubernetes version: 1.25
Helm major version: 3
External PostgreSQL versions: 15 or 16, with pgvector available

Prepare these resources before running the Qodo Helm installation. Use the chart, onprem-base.yaml, and customer values template from the same Qodo installation bundle or release.

Red Hat OpenShift support

Qodo product version: 3.1
Supported Red Hat OpenShift Container Platform versions: 4.12 and later

Qodo 3.1 supports deployment on Red Hat OpenShift Container Platform 4.12 and later using the Qodo Helm chart. This statement covers Qodo’s application running on OpenShift. It does not claim Red Hat certification or standalone Red Hat Enterprise Linux support. For more information, see Deploy Qodo using Helm and Get support.

What you need to provision

Resource	Prepare before installing	What the Qodo chart provides
Kubernetes	A cluster, namespace, available worker capacity, and namespaced installation permissions	Application workloads, Services, configuration, and setup Jobs
Traffic entry point	An ingress controller and load balancer, or an OpenShift router	Ingress resources, or Routes when explicitly enabled
DNS and TLS	Hostnames that resolve to the entry point and a certificate covering them	Routing for the portal, API, authentication, SDK, and Git webhooks
Persistent storage	A working StorageClass or pre-provisioned volumes that satisfy the chart’s claims	Claims for the repository cache and bundled datastores
PostgreSQL	An external server and credentials by default, or explicit configuration to enable the bundled server	Database initialization and migrations; an optional PostgreSQL server
Redis and RabbitMQ	Storage and capacity for the bundled services	Bundled Redis and RabbitMQ; separate servers are not needed for the default configuration
Single sign-on	A supported identity provider, an application registration, and client credentials	Zitadel and setup Jobs that configure federation
AI models	A reachable OpenAI-compatible endpoint, credentials, and model names	A bundled LLM gateway that forwards requests to your endpoint
Git provider	A reachable provider and an administrator who can authorize the integration and webhooks	Services that connect Qodo to your provider
Monitoring	Your Prometheus and Grafana deployment, plus Prometheus Operator and its CRDs if using ServiceMonitors	Optional component monitoring resources; the chart does not install Prometheus or Grafana
Autoscaling, if enabled	A compatible KEDA operator, metrics API server, admission webhooks, and CRDs; Kubernetes Metrics Server for CPU scaling	Per-workload ScaledObjects through component values; the chart does not install KEDA
External secret synchronization, if used	ESO controllers/webhook and CRDs, a cloud identity with source access, and a ready SecretStore or ClusterSecretStore	Fixed-name Kubernetes Secret references; your external controller supplies the credential data

The bundled LLM gateway does not host a model. Your upstream AI service must already be available. You can also configure an existing compatible gateway instead of using the bundled gateway. For more information, see Deploy Qodo using Helm. For provider-specific ingress values and backend health configuration, see Configure ingress. For the operator and workload values layers and their installation order, see Configure Kubernetes add-ons with values files.

Cluster access and capacity

Install kubectl and Helm on your deployment machine. Confirm the intended cluster context and namespace:

kubectl config current-context
kubectl get namespace qodo

Replace qodo with your namespace. Have your cluster administrator create it before installation. Keep the Helm release name qodo, because the chart uses fixed resource names. The ordinary Qodo installation uses namespaced permissions. Cluster-wide administration is needed to prepare resources such as the ingress controller, StorageClass, Prometheus Operator, KEDA, or External Secrets Operator. The bundle’s READINESS.md includes an installer Role, including permission to observe Pods, rollouts, and setup Jobs. Enabling ServiceMonitors also requires permission to manage monitoring.coreos.com ServiceMonitor resources in the Qodo namespace. Enable optional integrations only after their operators and APIs are ready. KEDA requires namespaced permissions for ScaledObjects and TriggerAuthentications. External secret synchronization requires permissions for ExternalSecrets and any new namespaced SecretStore, plus the controller’s target-Secret and cloud access. For more information, see Autoscale Qodo with KEDA and Manage Qodo secrets with External Secrets Operator. Size the cluster from the exact chart and values you will deploy. Account for:

All enabled workloads and replicas, including sidecars.
CPU and memory requests, limits, and headroom for application traffic.
Setup and migration Jobs, plus temporary overlap during rolling updates.
Cluster services and your monitoring stack, in addition to Qodo.

Each Pod must fit on an individual eligible node. For example, the indexer and code review worker have substantial memory requests; free memory summed across several smaller nodes does not guarantee that they can be scheduled. Render your intended configuration before installation:

helm template qodo ./qodo-onprem \
  --namespace qodo \
  -f onprem-base.yaml \
  -f my-values.yaml > qodo-rendered.yaml

Inspect the rendered workloads, requests, and volume claims with your cluster administrator. Treat the rendered file as sensitive because it can contain Secrets. Confirm production sizing with Qodo based on repository sizes and concurrent review and indexing workloads.

Persistent storage

Provide dynamic provisioning or matching PersistentVolumes. The default claims use ReadWriteOnce access. For service-specific values, claim names, customer-managed Gitway storage, and retention procedures, see Configure persistent storage.

Data	Initial claim size	When needed
Repository cache	50 GiB	Git repository storage
RabbitMQ	8 GiB	Bundled message broker; size for traffic and queue retention
Redis	5 GiB	Bundled cache
PostgreSQL	20 GiB	Only when you enable the bundled database

Review the effective values for your release, volume expansion, reclaim policy, and backup and restore procedures. Initial claim sizes are not production capacity estimates. Allocate monitoring storage separately according to your retention policy. Check that your StorageClass can provision in the zones where the Pods run:

kubectl get storageclass

If a claim remains Pending after installation, inspect it with kubectl describe pvc -n qodo <claim-name> before retrying Helm.

RabbitMQ storage

The default RabbitMQ storage allocation may be insufficient for production workloads. Calculate its capacity from a comparable installation’s used disk space, monthly Pull Request (PR) traffic, and actual queue retention. Include failed messages in dead-letter queues and free-space headroom. For the calculation and verification commands, see Size RabbitMQ for traffic and retention.

Database preparation

The shipped base values use an external PostgreSQL server. Set global.externalDatabase.host and global.externalDatabase.adminUser in your customer values. Create the qodo-db-admin Secret in the same namespace, with the POSTGRES_PASSWORD key, through your approved secret-management process. Have your database administrator confirm:

Pods can reach the server on TCP port 5432, including through firewall and database access rules.
TLS connectivity matches global.externalDatabase.sslMode. The default require encrypts the connection without verifying the server’s identity.
The vector extension is available for the databases that need it.
The installation identity has LOGIN, CREATEDB, and CREATEROLE, plus the role-administration grants described in the bundle’s READINESS.md.
The Qodo Agent Runtime database identity has neither SUPERUSER nor BYPASSRLS. If the installation identity has either attribute, arrange a dedicated runtime identity with Qodo before installation.
Backups, restore ownership, capacity, and connection limits cover all enabled components and replicas.

The chart creates its application databases and runs migrations. Do not pre-create application databases or run migrations separately unless your installation procedure specifically requires it. To choose bundled PostgreSQL instead, set both postgres.enabled: true and global.externalDatabase.host: qodo-postgres. Enabling the server alone does not redirect applications to it. Prepare its storage and backup plan first. For more information, see Helm chart configuration reference.

DNS, TLS, and network access

Prepare distinct hostnames for these entry points:

Default hostname	Used by
`app.<baseDomain>`	Users opening the portal
`api.<baseDomain>`	API clients
`portal-api.<baseDomain>`	The portal calling the API
`auth.<baseDomain>`	Browsers and Pods completing single sign-on
`sdk.<baseDomain>`	SDK and CLI clients
`git.<baseDomain>`	Git provider webhooks

Use a wildcard certificate or a certificate covering all resolved names. For Ingress deployments, create the TLS Secret named by global.tlsSecretName, or configure your certificate controller to create it. ALB uses its configured ACM certificate instead. On OpenShift, arrange the router certificate and configure Routes. For more information, see Configure ingress. Verify DNS and TLS from both the user network and the cluster. Pods must reach the authentication hostname using its configured issuer URL. Your Git provider must reach the webhook hostname; cloud-hosted providers need a path into your environment.

Source	Destination	Purpose
Helm client	`artifacts-self-hosted.qodo.ai` over HTTPS	Pull the licensed chart when using registry delivery
Kubernetes nodes	`artif-reg-self-hosted.codium.ai` over HTTPS	Pull application and supporting images
Qodo Pods	Your Git provider, identity provider, and configured AI endpoint	Repository access, sign-on, and model requests
Qodo Pods	Your database and bundled or configured backing services	Persistence, cache, and queue traffic
Your Prometheus collector	The selected Qodo metrics ports	Scrape application metrics inside your environment
Your Grafana server	Your Prometheus query endpoint	Display collected metrics

Apply network policies to permit these paths. If dependencies use a private certificate authority, prepare the custom-ca-cert Secret with your CA certificates before installing. Public roots remain in the application trust stores. The bundled LLM gateway needs separate trust configuration. For more information, see Private certificate authority. For an air-gapped installation, arrange the chart bundle and a complete image mirror before deployment. Registry credentials alone do not make images available offline. For more information, see Network and security considerations.

Credentials and installation order

Prepare cluster and infrastructure

Prepare the cluster, namespace, traffic entry point, DNS, TLS, and storage.

Prepare external dependencies

Prepare the database, model endpoint, identity-provider application, and Git provider access.

Obtain the Qodo bundle

Receive the Qodo bundle or licensed registry access. Follow the image-pull Secret procedure for your delivery path: a licensed registry pull supplies image credentials through the chart; a direct bundle requires qodo-pull.

Prepare optional secret and scaling operators

If using external secret synchronization, install and verify ESO, its webhook/CRDs, cloud identity, network access, and store before reconciling the required Secrets. If enabling autoscaling, install and verify KEDA and its APIs/CRDs first; CPU scaling also needs Kubernetes Metrics Server. See Manage Qodo secrets with External Secrets Operator and Autoscale Qodo with KEDA.

Create Kubernetes Secrets

Create or reconcile the database, LLM, identity-provider, and TLS Secrets specified by the installation guide in your Qodo namespace. When using ESO, wait for the store and every required ExternalSecret to report Ready and verify the target names/keys before deploying Qodo. Keep credentials out of values files and source control.

Prepare monitoring prerequisites

If enabling ServiceMonitors during installation, prepare Prometheus Operator, its CRDs, discovery permissions, and your Prometheus and Grafana deployment first.

Run the readiness check

Fill in your customer values and run the readiness check from the directory containing the bundle’s qodo-check.sh:

bash ./qodo-check.sh -n qodo \
  -f onprem-base.yaml \
  -f my-values.yaml

Resolve every FAIL and review every SKIP. A skipped check does not establish readiness. Use the same values files in the same order for the check and Helm. After installing, run the check again, verify sign-on with an administrator and an ordinary user, and trigger a test code review. Confirm monitoring targets are being scraped before opening traffic.

Next steps

Deploy Qodo using Helm: Configure values and deploy the prepared environment.
Configure Kubernetes add-ons with values files: Select operator integration overlays and preserve their deployment order.
Configure ingress: Choose and verify your cluster’s routing and TLS pattern.
Monitor Qodo with Prometheus and Grafana: Enable scraping, query metrics, and troubleshoot missing data.

Helm charts

Operations

Git Integration

Red Hat OpenShift support

What you need to provision

Cluster access and capacity

Persistent storage

RabbitMQ storage

Database preparation

DNS, TLS, and network access

Credentials and installation order

Next steps

​Red Hat OpenShift support

​What you need to provision

​Cluster access and capacity

​Persistent storage

​RabbitMQ storage

​Database preparation

​DNS, TLS, and network access

​Credentials and installation order

​Next steps

Red Hat OpenShift support

What you need to provision

Cluster access and capacity

Persistent storage

RabbitMQ storage

Database preparation

DNS, TLS, and network access

Credentials and installation order

Next steps