To further fine-tune your Qovery infrastructure, you can set advanced settings through the Qovery API endpoint.
Cluster advanced settings are not available in the Qovery console yet.
All clusters have access to advanced settings, you can find where they are available in the documentation below with those badges mentioning for which Cloud provider they are available:
You will also find badges mentioning for which components it will be applied:
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).
Type
Description
Default Value
boolean
Enable the AWS ALB controller to manage the load balancer for the cluster.
true
Requirements for customers using custom VPCs (Qovery Managed VPC does not require these steps):
On public subnets: add a label kubernetes.io/role/elb with the value 1 to the subnet where the ALB will be created.
On private subnets: add a label kubernetes.io/role/internal-elb with the value 1 to the subnet where the ALB will be created.
On all subnets: add a label kubernetes.io/cluster/<cluster-name> with the value shared to the subnet where the ALB will be created.
Allows you to specify the load balancer size in front of your cluster. Possible values are: - lb-s: 200 Mbps - lb-gp-m: 500 Mbps - lb-gp-l: 1 Gbps - lb-gp-xl: 4 Gbps
Enables compression (Brotli) for HTTP responses. When disabled, content will not be compressed, which may increase bandwidth usage but reduce CPU load.
Specifies the Docker image repository used for the default_backend. The image registry must be publicly accessible without requiring authentication. example: registry/image.
Deny any access to all PostgreSQL databases. When false, configure the CIDR range you want to allow within the associated allowed_cidrs parameter (default is "any IP"). ⚠️ Any access to managed databases will instantly be removed ⚠️ Any access to container databases will be removed only after a database redeployment
Deny any access to all MySQL databases. When false, configure the CIDR range you want to allow within the associated allowed_cidrs parameter (default is "any IP"). ⚠️ Any access to managed databases will instantly be removed ⚠️ Any access to container databases will be removed only after a database redeployment
Deny any access to all MongoDB databases. When false, configure the CIDR range you want to allow within the associated allowed_cidrs parameter (default is "any IP"). ⚠️ Any access to managed databases will instantly be removed ⚠️ Any access to container databases will be removed only after a database redeployment
Deny any access to all Redis databases. When false, configure the CIDR range you want to allow within the associated allowed_cidrs parameter (default is "anyone"). ⚠️ Any access to managed databases will instantly be removed ⚠️ Any access to container databases will be removed only after a database redeployment
Allows you to specify the IAM group name associated with the Qovery user in the AWS console during the IAM permissions setup to be able to connect to the Kubernetes cluster. Its value can be changed after the cluster installation via a re-deploy without any downtime.
Enable the static ip mode for the qovery control plane and automatically 1) activate the private endpoint on the Kubernetes API 2) add the Qovery IP to the CIDR whitelist.
false
If you need to connect to the Kubernetes cluster from your network, make sure to add your CIDR to the advanced setting k8s.api.allowed_public_access_cidrs.
Dockerhub credentials are necessary to activate this feature.
Before setting this advanced settings to true, go through the Organization settings > Container registry and make sure that your Dockerhub registry has some credentials set.
Why? Dockerhub has a rate limit system by IP when pulling from their registry. Since the Qovery control plane will be seen as a single IP, we will quickly reach the limit. This limit can be increased if you are a logged-in user and thus, if you put your credentials in the Dockerhub registry configuration of your organization, you should not encounter any rate limit issue during the deployment.