> ## 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 AWS ALB ingress

> Use the AWS Load Balancer Controller with Qodo's ClusterIP Services, an ACM certificate, and per-backend health checks.

* **Deployment model**: On-premises
* **Configuration reference**: Qodo Helm chart `7.22.0`.

Use this pattern with an existing AWS Load Balancer Controller and ALB
IngressClass. This profile uses IP targets for Qodo's ClusterIP Services.
EKS Auto Mode has a different controller contract; verify its supported
settings before adapting this example. For more information, see
[AWS Load Balancer Controller annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/).

## Before you begin

Prepare an operational controller, its IAM permissions, eligible subnets,
and security-group rules from the load balancer to Qodo Pods. Obtain an ACM
certificate in the load balancer's Region that covers all resolved Qodo
hosts. Configure internal DNS and caller connectivity for the private ALB
shown here. For more information, see [Configure ingress](https://docs.qodo.ai/on-prem/ingress.md).

## Configure values

Download [`ingress-aws-values.yaml` in the values archive](https://docs.qodo.ai/examples/on-prem/values-examples.zip).
Replace the ACM ARN and apply the file after your customer values:

```yaml ingress-aws-values.yaml theme={null}
# Qodo chart values for the AWS Load Balancer Controller (ALB).
# Replace the certificate ARN. Configure subnet discovery, IAM and network access first.
global:
  tlsSecretName: qodo-tls
  ingress:
    enabled: true
    className: alb
    annotations:
      alb.ingress.kubernetes.io/scheme: internal
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
      alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:REGION:ACCOUNT_ID:certificate/REPLACE_WITH_CERTIFICATE_ID
      alb.ingress.kubernetes.io/backend-protocol: HTTP
      alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=3600
platform:
  service:
    annotations:
      alb.ingress.kubernetes.io/healthcheck-path: /readyz
portal:
  service:
    annotations:
      alb.ingress.kubernetes.io/healthcheck-path: /health
qar:
  service:
    annotations:
      alb.ingress.kubernetes.io/healthcheck-path: /v1/health/ready
litegit:
  service:
    annotations:
      alb.ingress.kubernetes.io/healthcheck-path: /health/ready
zitadel:
  service:
    annotations:
      alb.ingress.kubernetes.io/healthcheck-path: /debug/healthz
      alb.ingress.kubernetes.io/backend-protocol-version: HTTP1

```

The controller terminates TLS using ACM. The chart's `spec.tls` Secret
reference is not how this profile supplies the ALB certificate.
Each Service supplies its own health-check path, instead of applying one
path to every backend. The Zitadel target group uses HTTP/1.1 for browser
login, OIDC discovery, and JWKS requests, including clients such as Python
`requests`. An ALB HTTP/2 target group rejects HTTP/1.1 client requests;
forcing that setting on the shared auth backend can break sign-on. For more
information, see [ALB protocol versions](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#target-group-protocol-version).

This profile does not expose native Zitadel gRPC. If your integration needs
that API, configure a separate reviewed gRPC route or a proxy that accepts
HTTP/1.1 clients and forwards HTTP/2 to Zitadel. Verify both OIDC and gRPC
clients through the selected path before rollout. For more information, see
[HTTP/2 support in Zitadel](https://zitadel.com/docs/self-hosting/manage/http2).

The HTTPS-only listener does not create an HTTP-to-HTTPS redirect listener.
For public access, review subnet selection, security groups, DNS, and all
callers before changing `scheme` to `internet-facing`. The scheme applies
to every host on this Ingress, not just the Git webhook host.

## Deploy and verify

```bash theme={null}
helm upgrade --install qodo ./qodo-onprem \
  --kube-context "$KUBE_CONTEXT" --namespace "$NAMESPACE" \
  -f qodo-onprem/onprem-base.yaml -f my-values.yaml \
  -f ingress-aws-values.yaml
```

Define `KUBE_CONTEXT` and `NAMESPACE` as in the shared ingress page. Confirm
all target groups are healthy, the ALB serves the intended ACM certificate,
and the auth issuer uses HTTPS. Complete SSO, a portal API request, SDK
access, and a real webhook-driven code review. For more information, see
[Configure ingress](https://docs.qodo.ai/on-prem/ingress.md).

| Symptom | Check and recovery |
| - | - |
| No ALB | Inspect controller IAM, subnet discovery, and the `alb` IngressClass |
| Targets are not registered | Confirm IP targeting, Pod endpoints, and the controller's VPC networking prerequisites |
| One target group is unhealthy | Compare that Service's health path and traffic port with the release's readiness probe |
| Webhooks time out | Confirm the provider can reach the internal ALB through your approved network path |


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