> ## Documentation Index > Fetch the complete documentation index at: https://www.qovery.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Cluster Advanced Settings > Fine-tune your Kubernetes cluster infrastructure with advanced configuration options ## Overview Cluster Advanced Settings allow you to fine-tune infrastructure-level parameters for your Qovery-managed Kubernetes clusters. These settings provide granular control over networking, logging, security, resource allocation, and cloud provider-specific features. ## Cloud Provider Availability Settings are tagged with their supported cloud providers: Amazon Web Services Google Cloud Platform Microsoft Azure Scaleway *** ## Configuring Cluster Advanced Settings ### Via Qovery Console (Recommended) The easiest way to configure cluster advanced settings is directly from the Qovery Console: Go to your cluster page and click on **Settings** In the settings menu, select **Advanced Settings** Browse and configure the advanced settings you need. Settings are organized by category for easy navigation. Click **Save** and redeploy your cluster for changes to take effect Cluster Advanced Settings in Console

Cluster Advanced Settings in Console

Use the **"Show only overridden settings"** toggle to filter and view only the settings you've customized from their default values. After updating cluster advanced settings, you must **redeploy the cluster** for changes to take effect. ### Via Qovery API You can also configure advanced settings using the Qovery API: ```bash theme={null} curl -X PATCH "https://api.qovery.com/cluster/{cluster_id}/advancedSettings" \ -H "Authorization: Token YOUR_API_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "loki.log_retention_in_week": 24, "nginx.hpa.min_number_instances": 3, "database.postgresql.deny_any_access": false, "database.postgresql.allowed_cidrs": ["10.0.0.0/16"] }' ``` ### Via Terraform Use the Qovery Terraform Provider to manage cluster advanced settings as code: ```hcl theme={null} resource "qovery_cluster" "my_cluster" { name = "production-cluster" organization_id = var.organization_id cloud_provider = "AWS" region = "us-east-1" advanced_settings_json = jsonencode({ "loki.log_retention_in_week" = 24 "nginx.hpa.min_number_instances" = 3 "nginx.controller.enable_client_ip" = true "database.postgresql.deny_any_access" = false "database.postgresql.allowed_cidrs" = ["10.0.0.0/16"] }) } ``` *** ## Cluster sizing ### cluster.profile **Cloud Provider:**

**Type:** `string` **Description:** Defines the cluster sizing profile, which determines the default resource allocation and performance characteristics of the cluster. Choosing a larger profile may incur higher costs but provides better performance and capacity for workloads. Here are detailed insights to help you choose the right profile: * `Small`: Suitable for development, testing, or small-scale applications with low resource demands. * 3-5 nodes | 12-20 vCPUs | 24-40 GB RAM | \~50-100 pods * Node size: 2-4 vCPUs, 4-8 GB RAM per node * Use cases: Development, staging, small internal tools * `Medium`: A balanced option for moderate workloads, suitable for most production applications. * 6-10 nodes | 48-80 vCPUs | 96-160 GB RAM | \~200-400 pods * Node size: 4-8 vCPUs, 8-16 GB RAM per node * Use cases: Small to medium production apps, multi-tenant dev environments * `Large`: Designed for high-traffic applications or workloads requiring significant resources. * 11-20 nodes | 176-320 vCPUs | 352-640 GB RAM | \~500-1000 pods * Node size: 8-16 vCPUs, 16-32 GB RAM per node * Use cases: Enterprise production applications, microservices architectures * `ExtraLarge`: Ideal for enterprise-level applications with intensive resource needs and high availability requirements. * 20+ nodes | 400+ vCPUs | 800+ GB RAM | 1000+ pods * Node size: 16-32+ vCPUs, 32-64+ GB RAM per node * Use cases: Large-scale production, ML/AI workloads, intensive data processing **Valid values:** `Small`, `Medium`, `Large`, `ExtraLarge` **Default Value:** `Medium` ## Logs ### aws.cloudwatch.eks\_logs\_retention\_days **Cloud Provider:**

**Type:** `integer` **Description:** Maximum retention days in CloudWatch for EKS logs. **Valid values:** 0, 1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1827, 2192, 2557, 2922, 3288, 3653 **Default Value:** `90` ### aws.vpc.enable\_s3\_flow\_logs **Cloud Provider:**

**Type:** `boolean` **Description:** Enable flow logs on the cluster VPC and store them in an S3 bucket. VPC flow logs capture information about IP traffic going to and from network interfaces in your VPC. **Use Case:** Required for compliance frameworks (SOC 2, PCI-DSS, HIPAA) that mandate network traffic logging. Also useful for security investigations and troubleshooting connectivity issues. **Default Value:** `false` ### aws.vpc.flow\_logs\_retention\_days **Cloud Provider:**

**Type:** `integer` **Description:** Set the number of retention days for flow logs. Set to `0` for unlimited retention. **Default Value:** `365` ### aws.vpc.enable\_nat\_gateway\_secondary\_eip **Cloud Provider:**

**Type:** `boolean` **Description:** Enable a secondary Elastic IP (EIP) per NAT Gateway. When enabled, each of the 3 NAT Gateways in your VPC receives an additional EIP, doubling the number of outbound public IP addresses from 3 to 6. This is useful when your workloads interact with external services that have IP-based rate limits — more IPs means higher aggregate limits. **Default Value:** `false` Enabling this setting creates 3 additional Elastic IPs in your AWS account. Each EIP incurs standard AWS charges. This setting only takes effect when the cluster uses NAT Gateways. Before enabling, verify that your AWS account has sufficient EIP quota (default is 5 per region). You can check and request an increase in the AWS Service Quotas console. ### loki.log\_retention\_in\_week **Cloud Provider:**

**Type:** `integer` **Description:** Maximum retention period (in weeks) for application logs collected by Loki and displayed in the Qovery console log viewer. Retention is enforced both at the Loki compactor level and via object storage lifecycle policies. **Use Case:** Increase for compliance requirements or debugging long-running issues. Decrease to save storage costs on the underlying object storage bucket. **Default Value:** `12` (84 days) ### loki.deployment\_mode **Cloud Provider:**

**Type:** `enum (single_binary, simple_scalable)` **Description:** Loki deployment topology. `single_binary` runs Loki as a single pod; `simple_scalable` splits it into separate write, read, and backend components for larger clusters. **Use Case:** Switch to `simple_scalable` when the cluster ingests more logs than a single Loki pod can handle. Keep the default for small to medium clusters. **Default Value:** `single_binary` ### loki.single\_binary.cpu\_request\_m **Cloud Provider:**

**Type:** `integer` **Description:** CPU request (in milli-CPU) for the Loki pod when running in `single_binary` mode. **Default Value:** `300` ### loki.single\_binary.cpu\_limit\_m **Cloud Provider:**

**Type:** `integer` **Description:** CPU limit (in milli-CPU) for the Loki pod when running in `single_binary` mode. **Default Value:** `8000` ### loki.single\_binary.memory\_request\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory request (in MiB) for the Loki pod when running in `single_binary` mode. **Default Value:** `1024` ### loki.single\_binary.memory\_limit\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory limit (in MiB) for the Loki pod when running in `single_binary` mode. **Default Value:** `2048` ### loki.write.cpu\_request\_m **Cloud Provider:**

**Type:** `integer` **Description:** CPU request (in milli-CPU) for the Loki write component when running in `simple_scalable` mode. **Default Value:** `300` ### loki.write.cpu\_limit\_m **Cloud Provider:**

**Type:** `integer` **Description:** CPU limit (in milli-CPU) for the Loki write component when running in `simple_scalable` mode. **Default Value:** `8000` ### loki.write.memory\_request\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory request (in MiB) for the Loki write component when running in `simple_scalable` mode. **Default Value:** `1024` ### loki.write.memory\_limit\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory limit (in MiB) for the Loki write component when running in `simple_scalable` mode. **Default Value:** `2048` ### loki.read.cpu\_request\_m **Cloud Provider:**

**Type:** `integer` **Description:** CPU request (in milli-CPU) for the Loki read component when running in `simple_scalable` mode. **Default Value:** `300` ### loki.read.cpu\_limit\_m **Cloud Provider:**

**Type:** `integer` **Description:** CPU limit (in milli-CPU) for the Loki read component when running in `simple_scalable` mode. **Default Value:** `8000` ### loki.read.memory\_request\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory request (in MiB) for the Loki read component when running in `simple_scalable` mode. **Default Value:** `1024` ### loki.read.memory\_limit\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory limit (in MiB) for the Loki read component when running in `simple_scalable` mode. **Default Value:** `2048` ### loki.backend.cpu\_request\_m **Cloud Provider:**

**Type:** `integer` **Description:** CPU request (in milli-CPU) for the Loki backend component when running in `simple_scalable` mode. **Default Value:** `300` ### loki.backend.cpu\_limit\_m **Cloud Provider:**

**Type:** `integer` **Description:** CPU limit (in milli-CPU) for the Loki backend component when running in `simple_scalable` mode. **Default Value:** `8000` ### loki.backend.memory\_request\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory request (in MiB) for the Loki backend component when running in `simple_scalable` mode. **Default Value:** `1024` ### loki.backend.memory\_limit\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory limit (in MiB) for the Loki backend component when running in `simple_scalable` mode. **Default Value:** `2048` ### gcp.vpc.enable\_flow\_logs **Cloud Provider:**

**Type:** `boolean` **Description:** Enable VPC flow logs on the cluster VPC (on each VPC subnetwork). See [GCP VPC logs flow documentation](https://cloud.google.com/vpc/docs/flow-logs). **Default Value:** `false` ### gcp.vpc.flow\_logs\_sampling **Cloud Provider:**

**Type:** `float` **Description:** Set VPC logs flow sampling percentage. Value should be within `0.0` (no sampling) to `1.0` (all logs) range. **Default Value:** `0.0` ### object\_storage.enable\_logging **Cloud Provider:**

**Type:** `boolean` **Description:** Activate cluster buckets logging into a `-log` bucket. See documentation for [AWS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html) and [GCP](https://cloud.google.com/logging/docs/buckets). **Default Value:** `false` *** ## DNS ### dns.coredns.extra\_config **Cloud Provider:**

**Type:** `string` **Description:** Additional configuration to add to CoreDNS. This can be used to customize DNS resolution rules on the cluster. The value is appended to the default CoreDNS Corefile. **Use Case:** Forward specific domains to internal DNS servers (split-horizon DNS), resolve private hosted zones, or add custom caching rules. **Default Value:** `null` **Examples:** Route queries for your internal domain to a private DNS server: ```corefile theme={null} corp.internal:53 { errors cache 30 forward . 10.0.0.2 } ``` Use Google Public DNS for a specific domain: ```corefile theme={null} example.com:53 { errors cache 30 forward . 8.8.8.8 8.8.4.4 } ``` *** ## Image Registry ### registry.image\_retention\_time **Cloud Provider:**

**Type:** `integer` **Description:** Allows you to specify an amount in seconds after which images in the default registry are deleted. Changing this setting will only affect new ECR repositories created after the change. Existing repositories will not be affected. **Default Value:** `31536000` (1 year) ### registry.mirroring\_mode **Cloud Provider:**

**Type:** `string` **Description:** Allows you to specify the [image mirroring mode](/configuration/deployment/image-mirroring) to be used for each image deployed on this cluster. **Valid values:** * `Service` — each service gets its own mirror repository (`qovery-mirror-{service_id}`). Provides better isolation but creates more repositories. Works on **all** cluster types. * `Cluster` — all services in the cluster share a single mirror repository (`qovery-mirror-cluster-{cluster_id}`). Fewer repositories, but requires registry lifecycle policy support for automated image cleanup. `Cluster` mode is only available on cluster types that support registry lifecycle policies: **EKS**, **GKE**, **AKS** (and their self-managed variants). It is not supported on DOKS, Scaleway Kapsule, or full self-managed clusters. **Default Value:** `Service` ### cloud\_provider.container\_registry.tags **Cloud Provider:**

**Type:** `Map` **Description:** Add additional tags on the cluster dedicated registry. **Default Value:** `{}` **Example:** ```json theme={null} { "cloud_provider.container_registry.tags": { "Environment": "Production", "Team": "Platform" } } ``` *** ## Network - Load Balancer ### aws.eks.enable\_alb\_controller **Cloud Provider:**

**Type:** `boolean` **Description:** Enable the AWS ALB controller to manage the load balancer for the cluster. Enabling this feature will create a 10 min max downtime on your application's public access (time to delete, replace and propagate DNS of the new load balancer). **Use Case:** For custom VPCs (Qovery Managed VPC does not require these), you need to add labels to subnets: `kubernetes.io/role/elb=1` on public subnets, `kubernetes.io/role/internal-elb=1` on private subnets, and `kubernetes.io/cluster/=shared` on all subnets. **Default Value:** `true` ### aws.eks.alb\_controller.replicas **Cloud Provider:**

**Type:** `integer` **Description:** Sets AWS ALB controller number of replicas. For production clusters, it's recommended to have at least 2 replicas for high availability. **Default Value:** `2` ### aws.eks.alb\_controller.vpa.vcpu.min\_in\_milli\_cpu **Cloud Provider:**

**Type:** `integer` **Description:** Sets AWS ALB controller VPA (vertical pod autoscaling) vCPU minimum value in milli CPU. **Default Value:** `250` ### aws.eks.alb\_controller.vpa.vcpu.max\_in\_milli\_cpu **Cloud Provider:**

**Type:** `integer` **Description:** Sets AWS ALB controller VPA (vertical pod autoscaling) vCPU maximum value in milli CPU. **Default Value:** `250` ### aws.eks.alb\_controller.vpa.memory.min\_in\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Sets AWS ALB controller VPA (vertical pod autoscaling) memory minimum value in mebibyte. **Default Value:** `128` ### aws.eks.alb\_controller.vpa.memory.max\_in\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Sets AWS ALB controller VPA (vertical pod autoscaling) memory maximum value in mebibyte. **Default Value:** `128` ### aws.eks.alb\_controller.load-balancer-source-ranges **Cloud Provider:**

**Type:** `list of cidr string` **Description:** Specifies the CIDRs that are allowed to access the NLB. [https://kubernetes-sigs.github.io/aws-load-balancer-controller/v3.2/guide/service/annotations/#lb-source-ranges](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v3.2/guide/service/annotations/#lb-source-ranges) **Default Value:** `[]` **Example:** `["10.0.0.0/8", "192.168.0.0/16"]` ### aws.eks.alb\_controller.load-balancer-scheme **Cloud Provider:**

**Type:** `string` **Description:** Specify if the load balancer is `internet-facing` and reachable from internet. Or if the load balancer is `internal` and reachable only from the cluster VPC. Changing this value is going to replace your current load balancer and there will be up to a few minutes of downtime **Default Value:** `internet-facing` ### load\_balancer.size **Cloud Provider:**

**Type:** `string` **Description:** Allows you to specify the load balancer size in front of your cluster. **Valid values:** `lb-s` (200 Mbps), `lb-gp-m` (500 Mbps), `lb-gp-l` (1 Gbps), `lb-gp-xl` (4 Gbps) **Default Value:** `lb-s` *** ## Network - NGINX Ingress ### nginx.vcpu.request\_in\_milli\_cpu **Cloud Provider:**

**Type:** `integer` **Description:** vCPU request value in millicores assigned to NGINX pods. **Default Value:** `200` ### nginx.vcpu.limit\_in\_milli\_cpu **Cloud Provider:**

**Type:** `integer` **Description:** vCPU limit value in millicores assigned to NGINX pods. **Default Value:** `700` ### nginx.memory.request\_in\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory request value in MiB assigned to NGINX pods. **Default Value:** `768` ### nginx.memory.limit\_in\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory limit value in MiB assigned to NGINX pods. **Default Value:** `768` ### nginx.hpa.cpu\_utilization\_percentage\_threshold **Cloud Provider:**

**Type:** `integer` **Description:** HPA CPU threshold in percentage assigned to NGINX deployment. **Default Value:** `50` ### nginx.hpa.min\_number\_instances **Cloud Provider:**

**Type:** `integer` **Description:** Minimum number of NGINX replicas for horizontal pod autoscaling. **Default Value:** `2` ### nginx.hpa.max\_number\_instances **Cloud Provider:**

**Type:** `integer` **Description:** Maximum number of NGINX replicas for horizontal pod autoscaling. **Default Value:** `25` ### nginx.controller.enable\_client\_ip **Cloud Provider:**

**Type:** `boolean` **Description:** Enables [ngx\_http\_realip\_module](https://nginx.org/en/docs/http/ngx_http_realip_module.html) module to get the real client IP address. **Default Value:** `false` ### nginx.controller.enable\_compression **Cloud Provider:**

**Type:** `boolean` **Description:** Enables compression (Brotli) for HTTP responses. When disabled, content will not be compressed, which may increase bandwidth usage but reduce CPU load. **Default Value:** `true` ### nginx.controller.use\_forwarded\_headers **Cloud Provider:**

**Type:** `boolean` **Description:** Passes incoming `X-Forwarded-For` header upstream. See [documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#use-forwarded-headers). **Default Value:** `false` ### nginx.controller.compute\_full\_forwarded\_for **Cloud Provider:**

**Type:** `boolean` **Description:** Append the remote address to the X-Forwarded-For header instead of replacing it. See [documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#compute-full-forwarded-for). **Default Value:** `false` ### nginx.controller.log\_format\_upstream **Cloud Provider:**

**Type:** `string` **Description:** Allows to customize NGINX [log-format](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#log-format-upstream). **Default Value:** `null` ### nginx.controller.log\_format\_escaping **Cloud Provider:**

**Type:** `string` **Description:** Allows to customize NGINX log-format-escaping setting. **Valid values:** `Default`, `JSON`, `None` **Default Value:** `Default` ### nginx.controller.http\_snippet **Cloud Provider:**

**Type:** `string` **Description:** Allows to customize NGINX [http-snippet](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#http-snippet) configuration. Used for cluster-level NGINX configuration that applies to all services. **Use Case:** See [Rate Limiting Guide](/getting-started/guides/advanced-tutorials/rate-limiting) for practical examples. **Default Value:** `null` ### nginx.controller.server\_snippet **Cloud Provider:**

**Type:** `string` **Description:** Allows to customize NGINX [server-snippet](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#server-snippet) configuration. Used for server-level NGINX configuration. **Use Case:** See [Rate Limiting Guide](/getting-started/guides/advanced-tutorials/rate-limiting) for practical examples. **Default Value:** `null` ### nginx.controller.limit\_request\_status\_code **Cloud Provider:**

**Type:** `integer` **Description:** Allows to customize NGINX [limit-req-status-code](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#limit-req-status-code). Commonly set to `429` (Too Many Requests) for rate limiting. **Default Value:** `null` (defaults to 503) ### nginx.controller.custom\_http\_errors **Cloud Provider:**

**Type:** `string` **Description:** Allows to customize NGINX [custom-http-errors](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#custom-http-errors). **Default Value:** `null` **Example:** `"404,503"` ### nginx.default\_backend.enabled **Cloud Provider:**

**Type:** `boolean` **Description:** Allows enabling the default\_backend for NGINX. If you don't specify custom image repository and tag, ensure your cluster includes nodes with amd64 architecture. **Default Value:** `false` ### nginx.default\_backend.image\_repository **Cloud Provider:**

**Type:** `string` **Description:** Specifies the Docker image repository used for the default\_backend. **Default Value:** `null` ### nginx.default\_backend.image\_tag **Cloud Provider:**

**Type:** `string` **Description:** Defines the image tag used by default\_backend. **Default Value:** `null` *** ## Network - Gateway API ### k8s.deploy\_api\_gateway **Cloud Provider:**

**Type:** `boolean` **Description:** Deploys Gateway API resources on the cluster if true. * Gateway API will be deployed on the cluster alongside Ingress NGINX controller, and both will be active. - It will allow you to access your service using a dedicated service URL pointing to the Gateway API controller instead of Ingress NGINX controller. **Default Value:** `false` ### k8s.use\_api\_gateway **Cloud Provider:**

**Type:** `boolean` **Description:** Makes Gateway API the default routing component. * This might cause a 30 seconds - 3 minutes downtime on your custom DNS due to DNS propagation. * When enabled, all new services will be exposed through Gateway API instead of Ingress NGINX controller. - NGINX controller will still be deployed in the cluster an will remain until we've fully migrated to Gateway API, but it will not be used for routing. **Default Value:** `false` ### k8s.gateway.load\_balancer\_ip\_allocation\_ids **Cloud Provider:**

**Type:** `list(string)` **Description:** Sets static public IP allocations for the Gateway API `LoadBalancer` Service. Qovery maps this setting to provider-specific Kubernetes Service annotations. This setting is mainly a safety mechanism for re-creation scenarios: while a `LoadBalancer` Service usually keeps the same public IPs during its lifetime, those IPs are not guaranteed after Service or cloud Load Balancer re-creation unless explicit static allocations are configured. Changing this setting may require Service and cloud Load Balancer re-creation before new IPs are effectively used. Plan a maintenance window: this operation can cause downtime, typically from tens of seconds to a few minutes (commonly around 1-3 minutes, sometimes longer depending on cloud LB provisioning and health checks). **Default Value:** `null` (no explicit static LB IP allocation guarantee across Service/LB re-creation) **Provider constraints and examples** #### AWS (EKS) * Annotation used by Qovery: `service.beta.kubernetes.io/aws-load-balancer-eip-allocations` * Expected values: EIP allocation IDs (for example `eipalloc-0123456789abcdef0`) * Constraint: number of EIPs must match the number of subnets/AZs used by the NLB (1 EIP per subnet/AZ). Valid (3 subnets/AZs): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - eipalloc-0123456789abcdef0 - eipalloc-abcdef01234567890 - eipalloc-11111111222222222 ``` Invalid (count mismatch for 3 subnets/AZs): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - eipalloc-0123456789abcdef0 - eipalloc-abcdef01234567890 ``` #### GCP (GKE) * Annotation used by Qovery: `networking.gke.io/load-balancer-ip-addresses` * Expected values: static address resource names * Constraint: maximum 2 values (single-stack: 1, dual-stack: 2). Valid (single-stack): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - projects/my-project/regions/europe-west1/addresses/my-ipv4 ``` Valid (dual-stack): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - projects/my-project/regions/europe-west1/addresses/my-ipv4 - projects/my-project/regions/europe-west1/addresses/my-ipv6-range ``` Invalid (>2 values): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - projects/my-project/regions/europe-west1/addresses/ip-1 - projects/my-project/regions/europe-west1/addresses/ip-2 - projects/my-project/regions/europe-west1/addresses/ip-3 ``` #### Azure (AKS) * Annotations used by Qovery: * `service.beta.kubernetes.io/azure-load-balancer-ipv4` * `service.beta.kubernetes.io/azure-load-balancer-ipv6` * Expected values: IP addresses * Constraint: at most one IPv4 and one IPv6. Valid (IPv4 only): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - 20.1.2.3 ``` Valid (IPv4 + IPv6): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - 20.1.2.3 - 2001:db8::1 ``` Invalid (two IPv4 values): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - 20.1.2.3 - 20.1.2.4 ``` #### Scaleway (Kapsule) * Annotation used by Qovery: `service.beta.kubernetes.io/scw-loadbalancer-ip-ids` * Expected values: Scaleway IP IDs in UUID format (without region prefix) * Constraint: maximum 2 values. Valid (1 value): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - 11111111-2222-3333-4444-555555555555 ``` Valid (2 values): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - 11111111-2222-3333-4444-555555555555 - aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee ``` Invalid (>2 values): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - 11111111-2222-3333-4444-555555555555 - aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee - cccccccc-dddd-eeee-ffff-000000000000 ``` Invalid (region-prefixed format): ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - fr-par-1/11111111-2222-3333-4444-555555555555 ``` How to create and retrieve Scaleway Load Balancer IP IDs: 1. Create a Load Balancer flexible IP in the same project and zone as your Kapsule cluster: ```bash theme={null} scw lb ip create zone=pl-waw-1 ``` If the Scaleway Console UI is inconsistent for LB IP creation/listing, prefer the CLI command above. 2\. List Load Balancer IP resources and retrieve their IDs: ```bash theme={null} scw lb ip list zone=pl-waw-1 ``` 3. Use the `id` value (UUID), not the `ip_address`, in cluster advanced settings: ```text theme={null} ID: 5f7a22ac-461e-4eea-867d-af671d9bcf86 IP: 151.115.35.84 ``` ```yaml theme={null} k8s.gateway.load_balancer_ip_allocation_ids: - 5f7a22ac-461e-4eea-867d-af671d9bcf86 ``` Notes: * Do not use a Public Gateway flexible IP ID for this setting. * Do not prefix IDs with the zone/region (for example `pl-waw-1/`). * If you cannot find an ID for an IP, verify that IP was created as a Load Balancer IP resource (`scw lb ip`), not another IP product. * The credentials used by your cluster/cloud-controller-manager must have Scaleway IAM permission set `LoadBalancersFullAccess` on the target project; otherwise reconciliation fails with `403 Permission denied with this ip_id` or `insufficient permissions: write loadbalancer`. **Troubleshooting** * If IP changes are not applied after updating this setting, recreate the Gateway `LoadBalancer` Service (or trigger a rollout path that recreates it). * For AWS, verify EIP count exactly matches NLB subnet/AZ count. * For Azure, verify values are valid IP addresses and that you provide at most one IPv4 and one IPv6. * For GCP and Scaleway, verify you do not exceed the maximum number of values. ### envoy.hpa.cpu\_average\_utilization\_percentage\_threshold **Cloud Provider:**

**Type:** `float` **Description:** HPA CPU average utilization threshold for the Envoy data plane managed by Envoy Gateway, expressed as a value between 0.0 and 1.0 (e.g., 0.8 for 80%). When CPU usage exceeds this threshold, Kubernetes scales the Envoy proxy replicas serving traffic. This setting applies to `EnvoyProxy.spec.provider.kubernetes.envoyHpa`. Learn more in the [EnvoyProxy HPA documentation](https://gateway.envoyproxy.io/latest/tasks/operations/customize-envoyproxy/). **Valid values:** `0.0` to `1.0` **Default Value:** `null` (uses Kubernetes default behavior) ### envoy.hpa.memory\_average\_utilization\_percentage\_threshold **Cloud Provider:**

**Type:** `float` **Description:** HPA memory average utilization threshold for the Envoy data plane managed by Envoy Gateway, expressed as a value between 0.0 and 1.0 (e.g., 0.8 for 80%). When memory usage exceeds this threshold, Kubernetes scales the Envoy proxy replicas serving traffic. This setting applies to `EnvoyProxy.spec.provider.kubernetes.envoyHpa`. Learn more in the [EnvoyProxy HPA documentation](https://gateway.envoyproxy.io/latest/tasks/operations/customize-envoyproxy/). **Valid values:** `0.0` to `1.0` **Default Value:** `null` (uses Kubernetes default behavior) ### envoy.hpa.min\_number\_instances **Cloud Provider:**

**Type:** `integer` **Description:** Minimum number of Envoy data-plane replicas managed by Envoy Gateway for horizontal pod autoscaling. This ensures a baseline level of availability and traffic-serving capacity. Must be less than or equal to `envoy.hpa.max_number_instances`. **Default Value:** `2` for production clusters, `1` for non-production clusters ### envoy.hpa.max\_number\_instances **Cloud Provider:**

**Type:** `integer` **Description:** Maximum number of Envoy data-plane replicas managed by Envoy Gateway for horizontal pod autoscaling. This sets an upper limit on traffic-serving scale and resource consumption. Must be greater than or equal to `envoy.hpa.min_number_instances`. **Default Value:** `25` *** ### envoy.gateway.hpa.cpu\_average\_utilization\_percentage\_threshold **Cloud Provider:**

**Type:** `float` **Description:** HPA CPU average utilization threshold for the Envoy Gateway control-plane deployment, expressed as a value between 0.0 and 1.0 (e.g., 0.8 for 80%). When CPU usage exceeds this threshold, Kubernetes scales the `envoy-gateway` controller deployment. This setting applies to the Gateway Helm chart HPA for the control plane. **Valid values:** `0.0` to `1.0` **Default Value:** `null` (uses Kubernetes default behavior) ### envoy.gateway.hpa.memory\_average\_utilization\_percentage\_threshold **Cloud Provider:**

**Type:** `float` **Description:** HPA memory average utilization threshold for the Envoy Gateway control-plane deployment, expressed as a value between 0.0 and 1.0 (e.g., 0.8 for 80%). When memory usage exceeds this threshold, Kubernetes scales the `envoy-gateway` controller deployment. This setting applies to the Gateway Helm chart HPA for the control plane. **Valid values:** `0.0` to `1.0` **Default Value:** `null` (uses Kubernetes default behavior) ### envoy.gateway.hpa.min\_number\_instances **Cloud Provider:**

**Type:** `integer` **Description:** Minimum number of Envoy Gateway control-plane replicas for horizontal pod autoscaling. This ensures baseline controller availability for reconciliation and configuration updates. Must be less than or equal to `envoy.gateway.hpa.max_number_instances`. **Default Value:** `2` for production clusters, `1` for non-production clusters ### envoy.gateway.hpa.max\_number\_instances **Cloud Provider:**

**Type:** `integer` **Description:** Maximum number of Envoy Gateway control-plane replicas for horizontal pod autoscaling. This sets an upper limit on controller scaling and resource consumption. Must be greater than or equal to `envoy.gateway.hpa.min_number_instances`. **Default Value:** `5` *** ### envoy.vcpu.request\_in\_milli\_cpu **Cloud Provider:**

**Type:** `integer` **Description:** vCPU request value in millicores assigned to Envoy Gateway pods. This defines the minimum CPU resources guaranteed for each pod. Must be less than or equal to `envoy.vcpu.limit_in_milli_cpu`. **Default Value:** `250` ### envoy.vcpu.limit\_in\_milli\_cpu **Cloud Provider:**

**Type:** `integer` **Description:** vCPU limit value in millicores assigned to Envoy Gateway pods. This defines the maximum CPU resources that each pod can consume. Must be greater than or equal to `envoy.vcpu.request_in_milli_cpu`. **Default Value:** `250` ### envoy.memory.request\_in\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory request value in MiB assigned to Envoy Gateway pods. This defines the minimum memory resources guaranteed for each pod. Must be less than or equal to `envoy.memory.limit_in_mib`. **Default Value:** `768` ### envoy.memory.limit\_in\_mib **Cloud Provider:**

**Type:** `integer` **Description:** Memory limit value in MiB assigned to Envoy Gateway pods. This defines the maximum memory resources that each pod can consume. Must be greater than or equal to `envoy.memory.request_in_mib`. **Default Value:** `768` ### envoy.gateway\_api.http\_request\_timeout\_seconds **Cloud Provider:**

**Type:** `integer` (unsigned) **Description:** Sets the default request timeout in seconds for Envoy Gateway BackendTrafficPolicy. This value is used when services do not define `network.gateway_api.http_request_timeout_seconds`. **Use Case:** Configure a cluster-wide timeout baseline for Gateway API routes while still allowing service-level overrides when needed. After changing this setting, redeploy your applications and services in this cluster to apply the new timeout on generated Gateway API resources. **Default Value:** `null` (uses Envoy Gateway default) **Example:** ```json theme={null} 90 ``` ### envoy.gateway\_api.http\_connection\_idle\_timeout\_seconds **Cloud Provider:**

**Type:** `integer` (unsigned) **Description:** Sets the default idle connection timeout in seconds for Envoy Gateway BackendTrafficPolicy. This value is used when services do not define `network.gateway_api.http_connection_idle_timeout_seconds`. **Use Case:** Apply a cluster-wide default for idle HTTP backend connections while keeping service-level tuning available. After changing this setting, redeploy your applications and services in this cluster to apply the new timeout on generated Gateway API resources. **Default Value:** `null` (uses Envoy Gateway default) **Example:** ```json theme={null} 120 ``` ### envoy.gateway\_api.http\_stream\_idle\_timeout\_seconds **Cloud Provider:**

**Type:** `integer` (unsigned) **Description:** Sets the stream idle timeout in seconds for Envoy Gateway `ClientTrafficPolicy` at gateway level. A stream is considered idle when no upstream or downstream data is exchanged during the configured period. This maps to Envoy `stream_idle_timeout` behavior. Learn more in the [Envoy timeout documentation](https://www.envoyproxy.io/docs/envoy/latest/faq/configuration/timeouts.html#stream-timeouts). **Use Case:** Keep long-running streaming responses alive while still terminating genuinely stalled streams. After changing this setting, redeploy your applications and services in this cluster to apply the new timeout on generated Gateway API resources. **Default Value:** `null` (uses Envoy Gateway default) **Example:** ```json theme={null} 300 ``` ### envoy.gateway\_api.http\_max\_stream\_duration\_seconds **Cloud Provider:**

**Type:** `integer` (unsigned) **Description:** Sets the default maximum stream duration in seconds for Envoy Gateway `BackendTrafficPolicy`. This value is used when services do not define `network.gateway_api.http_max_stream_duration_seconds`. This maps to Envoy `max_stream_duration` behavior. Learn more in the [Envoy timeout documentation](https://www.envoyproxy.io/docs/envoy/latest/faq/configuration/timeouts.html#stream-timeouts). **Use Case:** Put a hard upper bound on stream lifetime while still allowing long-running active streams below that limit. After changing this setting, redeploy your applications and services in this cluster to apply the new timeout on generated Gateway API resources. **Default Value:** `null` (uses Envoy Gateway default) **Example:** ```json theme={null} 600 ``` ### envoy.gateway\_api.retry.num\_retries **Cloud Provider:**

**Type:** `integer` (unsigned) **Description:** Sets the default retry attempt count for Gateway API traffic at cluster level. This value is used when services do not define `network.gateway_api.retry.num_retries`. **Use Case:** Define a consistent retry baseline for all services in the cluster while still allowing per-service overrides. After changing this setting, redeploy your applications and services in this cluster to apply the new retry configuration on generated Gateway API resources. **Default Value:** `2` **Example:** ```json theme={null} 2 ``` ### envoy.gateway\_api.retry.retry\_on **Cloud Provider:**

**Type:** `string` (CSV) **Description:** Defines default retry conditions at cluster level (for example `connect-failure`, `reset`, `refused-stream`, `retriable-status-codes`). Used when services do not define `network.gateway_api.retry.retry_on`. **Use Case:** Apply consistent retry triggers across services while allowing local service overrides when needed. After changing this setting, redeploy your applications and services in this cluster to apply the new retry configuration on generated Gateway API resources. **Default Value:** `"connect-failure,reset,refused-stream"` **Example:** ```json theme={null} "connect-failure,reset,refused-stream" ``` **Learn More (retry\_on values):** See [Envoy Gateway TriggerEnum reference](https://gateway.envoyproxy.io/v1.6/api/extension_types/#triggerenum). ### envoy.gateway\_api.retry.http\_status\_codes **Cloud Provider:**

**Type:** `string` (CSV of HTTP codes) **Description:** Defines default HTTP status codes to retry at cluster level. Codes must be integers in range `100..599`. Used when services do not define `network.gateway_api.retry.http_status_codes`. **Use Case:** Limit retries to specific response codes across services (for example `503,504`) without configuring each service separately. After changing this setting, redeploy your applications and services in this cluster to apply the new retry configuration on generated Gateway API resources. **Default Value:** `null` (unset) **Example:** ```json theme={null} "503,504" ``` ### envoy.gateway\_api.retry.per\_try\_timeout\_seconds **Cloud Provider:**

**Type:** `integer` (unsigned, `> 0`) **Description:** Sets the default timeout in seconds for each retry attempt. Used when services do not define `network.gateway_api.retry.per_try_timeout_seconds`. **Use Case:** Cap each retry attempt cluster-wide to reduce tail latency and avoid long blocked attempts. After changing this setting, redeploy your applications and services in this cluster to apply the new retry configuration on generated Gateway API resources. **Default Value:** `null` (unset) **Example:** ```json theme={null} 3 ``` **Learn More:** See [Envoy Gateway Retry Documentation](https://gateway.envoyproxy.io/latest/tasks/traffic/retry/). ### envoy.client\_ip\_detection.x\_forwarded\_for.number\_trusted\_hops **Cloud Provider:**

**Type:** `integer` **Description:** Number of trusted hops in the `X-Forwarded-For` header for client IP detection. This setting determines how many proxy hops to trust when extracting the real client IP address. See [Envoy Gateway documentation](https://gateway.envoyproxy.io/latest/tasks/traffic/client-traffic-policy/#configure-client-ip-detection) for more details. **For customers migrating from NGINX:** This replaces the NGINX `use_forwarded_headers` and `compute_full_forwarded_for` settings. Envoy uses a hop count model, but `null` (unset) and `0` are **not equivalent** in Qovery. **How to configure:** * Leave as `null` (unset) to keep direct connection IP detection (`useRemoteAddress = true`). This is the safest migration option when existing RBAC / IP whitelist logic depends on source IP from the TCP peer. * Set to `0` to enable XFF-based detection with `useRemoteAddress = false` and `xffNumTrustedHops = 0`. * Set to `1` if your traffic passes through 1 trusted proxy (e.g., AWS ALB only) * Set to `2` if your traffic passes through 2 trusted proxies (e.g., CloudFront → ALB) **Behavior summary in Qovery:** | `number_trusted_hops` value | `xffNumTrustedHops` | `useRemoteAddress` | | --------------------------- | ------------------- | ------------------ | | absent (`null`) | — | `true` | | `0` | `0` | `false` | | `1` | `0` | `false` | | `2` | `1` | `false` | | `3` | `2` | `false` | `0` and `1` therefore behave the same from an XFF trust perspective (`xffNumTrustedHops = 0`). **NGINX mapping note:** `nginx.controller.use_forwarded_headers = false` maps closest to leaving `envoy.client_ip_detection.x_forwarded_for.number_trusted_hops` unset (`null`), not to setting it to `0`. **Example:** If a request arrives with `X-Forwarded-For: client-ip, proxy1-ip, proxy2-ip`: * with `number_trusted_hops: 2` (mapped to `xffNumTrustedHops: 1`), detected client IP is `proxy1-ip` * with `number_trusted_hops: 3` (mapped to `xffNumTrustedHops: 2`), detected client IP is `client-ip` **Default Value:** `null` (uses Envoy default behavior) `envoy.client_ip_detection.x_forwarded_for.number_trusted_hops` and `envoy.client_ip_detection.x_forwarded_for.trusted_cidrs` are **mutually exclusive**. Set **only one** of them. Qovery API validates this and returns a clear error if both are set. At engine rendering level, CIDR strategy has precedence when both values are present. ### envoy.client\_ip\_detection.x\_forwarded\_for.trusted\_cidrs **Cloud Provider:**

**Type:** `array[string]` **Description:** List of trusted CIDR ranges used to evaluate `X-Forwarded-For` and determine the original client IP address. This is the CIDR-based strategy for Envoy client IP detection. See [Envoy Gateway documentation](https://gateway.envoyproxy.io/latest/tasks/traffic/client-traffic-policy/#configure-client-ip-detection). **How to configure:** * Add your trusted proxy CIDRs (for example the CIDRs used by your edge/load balancers) * Keep the list empty to disable this strategy * Use this strategy when proxy hop count is variable but source proxy networks are known **Example:** ```json theme={null} [ "10.0.0.0/8", "192.168.0.0/16" ] ``` **Default Value:** `[]` ### envoy.log\_format **Cloud Provider:**

**Type:** `string` (JSON format) **Description:** Custom log format for Envoy Gateway access logs. **Qovery only allows JSON format** as it enables all the Qovery capabilities for application logging and tracing. The value must be a JSON object (provided as a string) with Envoy command operators. See [Envoy Gateway access logging documentation](https://gateway.envoyproxy.io/latest/tasks/observability/proxy-accesslog/#default-access-log) for available format variables and configuration options. **For customers migrating from NGINX:** This replaces the NGINX `log_format_upstream` setting. Envoy uses its own format string with command operators like `%REQ(X-HEADER)%`, `%RESP(X-HEADER)%`, and `%DURATION%` instead of NGINX's `$variable` syntax. **Default Value:** If not specified, the following JSON format is used: ```json theme={null} { "start_time": "%START_TIME%", "method": "%REQ(:METHOD)%", "x-envoy-origin-path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%", "protocol": "%PROTOCOL%", "response_code": "%RESPONSE_CODE%", "response_flags": "%RESPONSE_FLAGS%", "response_code_details": "%RESPONSE_CODE_DETAILS%", "connection_termination_details": "%CONNECTION_TERMINATION_DETAILS%", "upstream_transport_failure_reason": "%UPSTREAM_TRANSPORT_FAILURE_REASON%", "bytes_received": "%BYTES_RECEIVED%", "bytes_sent": "%BYTES_SENT%", "duration": "%DURATION%", "x-envoy-upstream-service-time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%", "x-forwarded-for": "%REQ(X-FORWARDED-FOR)%", "user-agent": "%REQ(USER-AGENT)%", "x-request-id": "%REQ(X-REQUEST-ID)%", ":authority": "%REQ(:AUTHORITY)%", "upstream_host": "%UPSTREAM_HOST%", "upstream_cluster": "%UPSTREAM_CLUSTER%", "upstream_local_address": "%UPSTREAM_LOCAL_ADDRESS%", "downstream_local_address": "%DOWNSTREAM_LOCAL_ADDRESS%", "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%", "requested_server_name": "%REQUESTED_SERVER_NAME%", "route_name": "%ROUTE_NAME%", "qovery_com_associated_service_id": "%REQ(x-qovery-com-associated-service-id)%", "qovery_com_environment_id": "%REQ(x-qovery-com-environment-id)%" } ``` When customizing the log format, **you must include these two Qovery-specific fields** for service logging to work properly: * `"qovery_com_associated_service_id": "%DYNAMIC_METADATA(envoy.lb:qovery_com_associated_service_id)%"` * `"qovery_com_environment_id": "%DYNAMIC_METADATA(envoy.lb:qovery_com_environment_id)%"` Without these fields, Qovery will not be able to properly associate logs with your services and environments. **Example:** Custom JSON format with simplified fields (note the required Qovery fields): ```json theme={null} { "timestamp": "%START_TIME%", "method": "%REQ(:METHOD)%", "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%", "protocol": "%PROTOCOL%", "status": "%RESPONSE_CODE%", "duration_ms": "%DURATION%", "bytes_sent": "%BYTES_SENT%", "bytes_received": "%BYTES_RECEIVED%", "client_ip": "%REQ(X-FORWARDED-FOR)%", "user_agent": "%REQ(USER-AGENT)%", "request_id": "%REQ(X-REQUEST-ID)%", "qovery_com_associated_service_id": "%DYNAMIC_METADATA(envoy.lb:qovery_com_associated_service_id)%", "qovery_com_environment_id": "%DYNAMIC_METADATA(envoy.lb:qovery_com_environment_id)%" } ``` ### envoy.custom\_certificate **Cloud Provider:**

**Type:** `string` (JSON format) **Description:** Allows you to upload your own TLS certificate that is going to be used by envoy when serving https traffic. Let's encrypt is not going to be used to generate the cluster certificate. The certificate must be PEM encoded Changing this setting after the cluster has been deployed, requires manual intervention and will cause downtime. Please contact the support if you require it **Default Value:** null **Example:** Custom JSON format with certificate and key PEM encoded: ```json theme={null} {"tls_crt":"-----BEGIN CERTIFICATE-----\nMIIXXXXX\n-----END CERTIFICATE-----\n","tls_key":"-----BEGIN RSA PRIVATE KEY-----\nMIIXXXXX\n-----END RSA PRIVATE KEY-----\n"} ``` ### envoy.controller.custom\_http\_errors **Cloud Provider:**

**Type:** `list of integers` **Description:** List of HTTP status codes for which Envoy Gateway should serve custom error pages. When you specify a status code in this list, Envoy Gateway will intercept that error and serve a hardcoded HTML error page instead of passing through the upstream error response. Each HTTP error code has its own hardcoded HTML page built into Envoy Gateway. The hardcoded error pages cannot be customized at this time. If you need to customize error pages for your use case, please contact us and we can extend this feature. **Valid values:** HTTP status codes from `100` to `599` **Default Value:** `null` **Example:** `[404, 503, 502, 500]` - This will serve custom hardcoded HTML pages for Not Found, Service Unavailable, Bad Gateway, and Internal Server Error responses. ### envoy.controller.enable\_compression **Cloud Provider:**

**Type:** `boolean` **Description:** Enables HTTP response compression in Envoy Gateway. When enabled, Envoy Gateway automatically compresses HTTP responses using multiple compression algorithms to reduce bandwidth usage and improve performance. **Compression algorithms enabled:** * **Gzip** - Compression level 6 (widely supported, good compression ratio) * **Brotli** - Quality level 6 (better compression than Gzip, modern browsers) * **Zstd** - Compression level 6 (fastest compression, newest standard) Envoy Gateway automatically selects the best compression algorithm based on the client's `Accept-Encoding` header. **For customers migrating from NGINX:** This replaces NGINX's compression settings (`enable-brotli` and `use-gzip`). The main difference is that Envoy Gateway adds **Zstd** as a third compression algorithm alongside Gzip and Brotli. All compression levels match NGINX defaults (level 6). **Default Value:** `true` ### envoy.default\_backend.enabled **Cloud Provider:**

**Type:** `boolean` **Description:** Enables the default backend for Envoy Gateway. The default backend serves a generic error page for requests that don't match any route. **Default Value:** `false` ### envoy.default\_backend.image **Cloud Provider:**

**Type:** `string` **Description:** Specifies the Docker image used for the default backend. **Default Value:** `null` ### envoy.default\_backend.tag **Cloud Provider:**

**Type:** `string` **Description:** Defines the image tag used by the default backend. **Default Value:** `null` *** ## Network - Database Access Control ### database.postgresql.deny\_any\_access **Cloud Provider:**

**Type:** `boolean` **Description:** Deny any access to all PostgreSQL databases. When enabled, **no** CIDR (including `allowed_cidrs`) can reach the database — this is a hard deny that overrides everything. * Managed databases: Access is removed instantly * Container databases: Access is removed only after redeployment **Default Value:** `false` ### database.postgresql.allowed\_cidrs **Cloud Provider:**

**Type:** `string` **Description:** List of allowed CIDR ranges for PostgreSQL database access. Only traffic from these CIDRs can reach the database. Ignored if `database.postgresql.deny_any_access` is `true`. **Default Value:** `["0.0.0.0/0"]` **Example:** Restrict to your VPN and office IPs: ```json theme={null} ["10.0.0.0/8", "203.0.113.0/24"] ``` ### database.mysql.deny\_any\_access **Cloud Provider:**

**Type:** `boolean` **Description:** Deny any access to all MySQL databases. When enabled, this overrides `allowed_cidrs`. * Managed databases: Access is removed instantly * Container databases: Access is removed only after redeployment **Default Value:** `false` ### database.mysql.allowed\_cidrs **Cloud Provider:**

**Type:** `string` **Description:** List of allowed CIDR ranges for MySQL database access. Ignored if `database.mysql.deny_any_access` is `true`. **Default Value:** `["0.0.0.0/0"]` ### database.mongodb.deny\_any\_access **Cloud Provider:**

**Type:** `boolean` **Description:** Deny any access to all MongoDB databases. When enabled, this overrides `allowed_cidrs`. * Managed databases: Access is removed instantly * Container databases: Access is removed only after redeployment **Default Value:** `false` ### database.mongodb.allowed\_cidrs **Cloud Provider:**

**Type:** `string` **Description:** List of allowed CIDR ranges for MongoDB database access. Ignored if `database.mongodb.deny_any_access` is `true`. **Default Value:** `["0.0.0.0/0"]` ### database.redis.deny\_any\_access **Cloud Provider:**

**Type:** `boolean` **Description:** Deny any access to all Redis databases. When enabled, this overrides `allowed_cidrs`. * Managed databases: Access is removed instantly * Container databases: Access is removed only after redeployment **Default Value:** `false` ### database.redis.allowed\_cidrs **Cloud Provider:**

**Type:** `string` **Description:** List of allowed CIDR ranges for Redis database access. Ignored if `database.redis.deny_any_access` is `true`. **Default Value:** `["0.0.0.0/0"]` *** ## Service Resources ### allow\_service\_cpu\_overcommit **Cloud Provider:**

**Type:** `boolean` **Description:** Authorize CPU overcommit (limit > request) for services deployed within this cluster. When enabled, pods can burst above their CPU request up to the configured limit when spare capacity is available on the node. CPU overcommit can cause CPU throttling and unpredictable latency when nodes are under pressure. Use with caution in production. **Use Case:** Once enabled, you can update the service advanced setting `resources.override.limit.cpu_in_milli` to set a CPU limit higher than the request. **Default Value:** `false` ### allow\_service\_ram\_overcommit **Cloud Provider:**

**Type:** `boolean` **Description:** Authorize memory overcommit (limit > request) for services deployed within this cluster. When enabled, pods can use more memory than their request up to the configured limit. Memory overcommit is riskier than CPU overcommit. Unlike CPU (which is throttled), exceeding memory limits causes the pod to be **OOM-killed**. If multiple pods on the same node exceed their requests simultaneously, the node can become unstable. **Use Case:** Once enabled, you can update the service advanced setting `resources.override.limit.ram_in_mib` to set a memory limit higher than the request. **Default Value:** `false` *** ## IAM & Security ### aws.iam.enable\_admin\_group\_sync **Cloud Provider:**

**Type:** `boolean` **Description:** Enable IAM admin group sync. See [IAM permissions setup](/installation/aws/cluster-managed-by-qovery/quickstart#attach-aws-credentials). `aws.iam.admin_group` must be set when `enable_admin_group_sync` is true. **Default Value:** `true` ### aws.iam.admin\_group **Cloud Provider:**

**Type:** `string` **Description:** Allows you to specify the IAM group name associated with the Qovery user. Configure IAM group permissions for cluster access. **Default Value:** `Admins` ### aws.iam.enable\_sso **Cloud Provider:**

**Type:** `boolean` **Description:** Enable SSO sync allowing IAM users to connect to cluster using SSO. `aws.iam.sso_role_arn` must be set when `enable_sso` is true. **Default Value:** `false` ### aws.iam.sso\_role\_arn **Cloud Provider:**

**Type:** `string` **Description:** Allows you to specify the SSO role ARN to be used to connect to your cluster. **Default Value:** `""` ### aws.eks.encrypt\_secrets\_kms\_key\_arn **Cloud Provider:**

**Type:** `string` **Description:** Allows you to activate KMS encryption of your Kubernetes secrets. Specify the [key ARN](https://docs.aws.amazon.com/kms/latest/developerguide/find-cmk-id-arn.html) of your AWS KMS key. It won't be possible to go back once this feature is activated. **Default Value:** `null` ### k8s.api.allowed\_public\_access\_cidrs **Cloud Provider:**

**Type:** `string` **Description:** Contains additional CIDRs that should be whitelisted to access the Kubernetes API. Use this to allow your team or CI/CD pipelines to reach the K8s API when `qovery.static_ip_mode` is enabled. `qovery.static_ip_mode` should be set to `true` to make this setting effective. **Default Value:** `[]` **Example:** ```json theme={null} ["203.0.113.0/24", "198.51.100.10/32"] ``` *** ## Miscellaneous ### aws.eks.ec2.metadata\_imds **Cloud Provider:**

**Type:** `string` **Description:** Specify the [IMDS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) version you want to use. **Valid values:** * `required` — IMDSv2 only (recommended). Forces all metadata requests to use session tokens, which protects against SSRF attacks that try to steal instance credentials. * `optional` — IMDSv1 and v2. Use only if you have legacy workloads that don't support IMDSv2. **Default Value:** `required` ### aws.eks.ec2.ami **Cloud Provider:**

**Type:** `string` **Description:** Specify the AMI you want to use for EKS worker nodes (Karpenter only). **Valid values:** * `AmazonLinux2` (Deprecated, not working after Kubernetes 1.32) * `AmazonLinux2023` (Default Amazon AMI, recommended) * `Bottlerocket` (Focuses on security and maintainability) * `ami-xxx` — A custom AMI ID (e.g. `ami-0123456789abcdef0`). Assumes AL2023-based by default. * `my-custom-ami-*` — A custom AMI name pattern with optional wildcards. Assumes AL2023-based by default. * `al2:ami-xxx` or `al2:my-ami-*` — A custom AMI based on Amazon Linux 2. * `al2023:ami-xxx` or `al2023:my-ami-*` — A custom AMI based on Amazon Linux 2023 (explicit). * `bottlerocket:ami-xxx` or `bottlerocket:my-ami-*` — A custom AMI based on Bottlerocket. Custom AMIs without a family prefix are assumed to be AL2023-based. Use a prefix (`al2:`, `al2023:`, `bottlerocket:`) to specify the base OS so that Karpenter generates the correct bootstrap configuration. This setting only applies to Karpenter-managed nodes (not managed node groups). GPU nodes are not affected by this setting. **Default Value:** `AmazonLinux2023` ### aws.metrics\_server.replicas **Cloud Provider:**

**Type:** `integer` **Description:** Specify the number of replicas for the metrics-server pod. Set to 2 or more in production for high availability. **Default Value:** `1` ### qovery.static\_ip\_mode **Cloud Provider:**

**Type:** `boolean` **Description:** Enable the static IP mode for the Qovery control plane and automatically activate the private endpoint on the Kubernetes API and add the Qovery IP to the CIDR whitelist. If you need to connect to the Kubernetes cluster from your network, make sure to add your CIDR to `k8s.api.allowed_public_access_cidrs`. **DockerHub credentials are required** to activate this feature. Configure them in [Organization settings > Container registry](/configuration/organization/container-registry). Why? DockerHub has a [rate limit by IP](https://docs.docker.com/docker-hub/download-rate-limit/). Since the Qovery control plane will be seen as a single IP, you need authenticated access to increase the limit. **Default Value:** `false` *** ## Storage ### storageclass.fast\_ssd **Cloud Provider:**

**Type:** `string` **Description:** Specify the Kubernetes storageClass to be used for storage attached to your container databases and applications. Override this if you need a custom storageClass (e.g., for encryption, specific IOPS, or a different disk type). **Default Value:** `""` (empty — each cloud provider uses its own default) When left empty, Qovery uses the following storageClasses per provider: | Cloud Provider | StorageClass | Disk Type | | -------------- | ------------------------ | ---------------------------------------- | | AWS | `aws-ebs-gp3-0` | General Purpose SSD (GP3) | | GCP | `gcp-pd-balanced` | Balanced persistent disk | | Azure | `azure-standard-ssd-zrs` | Standard SSD with zone-redundant storage | | Scaleway | `scw-sbv-ssd-0` | Block Storage SSD | **AWS GP2 → GP3 migration:** If your cluster still uses `aws-ebs-gp2-0` (legacy), we recommend migrating to `aws-ebs-gp3-0`. GP3 offers better baseline performance (3,000 IOPS and 125 MB/s included) at a lower cost than GP2. Set `storageclass.fast_ssd` to `aws-ebs-gp3-0` and redeploy your cluster. GCP also supports `gcp-pd-ssd` for higher IOPS. Azure supports `azure-premium-lrs`, `azure-premium-v2-lrs`, `azure-premium-zrs`, `azure-ultra-ssd-lrs`, and `azure-standard-ssd-lrs`. ### aws.eks.enable\_efs\_addon **Cloud Provider:**

**Type:** `boolean` **Description:** Enable the [AWS EFS CSI driver](https://docs.aws.amazon.com/eks/latest/userguide/efs-csi.html) EKS add-on to provision EFS-backed persistent volumes on the cluster. When enabled, Qovery automatically provisions: * The **EFS CSI driver** as a managed EKS add-on * An **encrypted EFS file system** dedicated to the cluster * A **security group** allowing NFS (port 2049) from the VPC * **Mount targets** in each availability zone used by the cluster * The required **IAM roles and policies** (IRSA) * A **StorageClass** named `aws-efs` for dynamic provisioning via EFS access points EFS provides shared, multi-AZ, ReadWriteMany storage — ideal for workloads that need to share files across multiple pods or nodes (e.g. CMS uploads, shared config, ML datasets). **Prerequisite:** Before enabling this setting, you must add the following IAM permissions to the role used by Qovery to manage your AWS account. Without them, the cluster deployment will fail when trying to create the EFS resources. ```json theme={null} { "Effect": "Allow", "Action": "elasticfilesystem:*", "Resource": "*" } ``` Add this statement to the IAM policy attached to your Qovery AWS role (the one configured in **Organization settings > Cloud provider credentials**). Disable this add-on only if no workload still depends on EFS-backed volumes. Disabling will **destroy** the EFS file system and all data stored in it. #### Using EFS with Helm charts Once the setting is enabled and the cluster is deployed, the `aws-efs` StorageClass is available. Create a `PersistentVolumeClaim` and mount it in your workload. **Step 1 — Create a PVC in your Helm chart templates:** ```yaml theme={null} # templates/efs-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: {{ "{{ .Release.Name }}" }}-efs spec: accessModes: - ReadWriteMany storageClassName: aws-efs resources: requests: storage: 5Gi ``` **Step 2 — Mount the volume in your workload:** ```yaml theme={null} # templates/deployment.yaml (excerpt) spec: containers: - name: app volumeMounts: - name: efs-data mountPath: /data volumes: - name: efs-data persistentVolumeClaim: claimName: {{ "{{ .Release.Name }}" }}-efs ``` That's it — no need to create a StorageClass or look up the EFS file system ID. Qovery handles everything. **Default Value:** `false` ### aws.eks.efs.throughput\_mode **Cloud Provider:**

**Type:** `string` **Description:** Controls how throughput is allocated for the EFS file system provisioned by the cluster. | Mode | Throughput | Cost model | Best for | | ------------- | -------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------- | | `elastic` | Scales automatically up to 10 GiB/s read, 3 GiB/s write | Pay per GiB transferred (\~$0.03/GiB read, ~$0.06/GiB write) | Variable or unpredictable workloads | | `bursting` | Baseline 50 KiB/s per GiB stored, bursts up to 100 MiB/s | Included in storage cost (\~\$0.30/GiB-month) | Small file systems with occasional bursts | | `provisioned` | Fixed throughput you configure (1-3,072 MiB/s) | \~\$6.00/MiB/s-month on top of storage | Steady, high-throughput workloads | `provisioned` mode is not fully supported yet — it requires a fixed throughput value that is not configurable via Qovery advanced settings. Use `elastic` or `bursting` instead. **Valid values:** `elastic`, `bursting` **Default Value:** `elastic` ### aws.eks.efs.performance\_mode **Cloud Provider:**

**Type:** `string` **Description:** Controls the I/O performance characteristics of the EFS file system. | Mode | Latency | Max IOPS | Best for | | ---------------- | --------------- | -------------------------------- | ------------------------------------------------------- | | `generalPurpose` | Lowest (sub-ms) | Up to 55,000 read / 25,000 write | Web serving, CMS, home directories, most workloads | | `maxIO` | Slightly higher | No practical limit | Massively parallel big data, genomics, media processing | **This setting cannot be changed after the EFS file system is created.** Changing it requires destroying and recreating the file system, which **permanently deletes all stored data**. Choose carefully at cluster creation time. **Valid values:** `generalPurpose`, `maxIO` **Default Value:** `generalPurpose` ### aws.eks.efs.transition\_to\_ia **Cloud Provider:**

**Type:** `string` **Description:** Lifecycle policy that automatically moves files not accessed for the specified period to the **Infrequent Access (IA)** storage class. | Storage class | Storage cost | Read cost | Write cost | | ----------------- | ----------------------------------- | ------------ | ------------ | | Standard | \~\$0.30/GiB-month | Included | Included | | Infrequent Access | \~\$0.016/GiB-month (\~95% cheaper) | \~\$0.01/GiB | \~\$0.01/GiB | Set to an empty string (`""`) to disable the lifecycle policy and keep all files in Standard storage. **Valid values:** `AFTER_1_DAY`, `AFTER_7_DAYS`, `AFTER_14_DAYS`, `AFTER_30_DAYS`, `AFTER_60_DAYS`, `AFTER_90_DAYS`, `""` (disabled) **Default Value:** `AFTER_30_DAYS` *** ## Next Steps Configure service-level advanced settings Implement rate limiting with NGINX Configure IP and header-based authorization Learn about cluster operations Explore the full Qovery API Manage infrastructure as code Kubernetes cluster related updates