Service Advanced Settings

To further fine-tune your Qovery infrastructure, you can set advanced settings through the Advanced Settings section of your service.

To access the Advanced Settings section:

  1. Select the service where you want to modify the advanced settings

    Settings

  2. Open the advanced settings section from the left menu

    Advanced Settings

The screen shows you the list of available advanced settings and for each of them:

  • The default value
  • The value configured right now

You can show only the modified values by activating the "Show only overridden settings" feature toggle.

All services have access to advanced settings, you can find where they are available in the documentation below with those badges:

Application Deployment

build.timeout_max_sec

TypeDescriptionDefault Value
integerAllows you to specify an interval, in seconds, after which the application build times out.1800

deployment.custom_domain_check_enabled

TypeDescriptionUse CaseDefault Value
booleanQovery allows you to set custom domains for your applications through the addition of a CNAME record to your domain's DNS settings. By default, when an application is deployed, Qovery checks that the CNAME record is set up correctly. This advanced setting allows you to disable this check.If you are using a Content Delivery Network (CDN), checking the CNAME setup for any custom domains you may have set up is likely to stall the deployment of your application.

Therefore, if you are using a CDN behind your application, we recommend disabling this feature to save time during your application deployments.
true

deployment.termination_grace_period_seconds

TypeDescriptionUse CaseDefault Value
integerDecide how many times in seconds the application is supposed to stop at maximum. After this time, the application will be forced to stop (killed)An application requiring several tasks to be stopped properly should have a higher grace period. If the application finishes early, then it will not wait until the end of the grace period60

Deployment strategy

deployment.update_strategy.type

TypeDescriptionUse CaseDefault Value
stringSet deployment strategy type (RollingUpdate or Recreate)Rolling update strategy will gracefully rollout new versions, while Recreate will stop all current versions and create new ones once all old ones have been shutdown (more info)RollingUpdate

deployment.update_strategy.rolling_update.max_unavailable_percent

TypeDescriptionDefault Value
integerDefine the percentage of a maximum number of pods that can be unavailable during the update process (more info).25

deployment.update_strategy.rolling_update.max_surge_percent

TypeDescriptionDefault Value
integerDefine the percentage of the maximum number of pods that can be created over the desired number of pods (more info)25

Kubernetes Probes

With Kubernetes probes, you can perform health checks to ensure that your applications are running smoothly. You can configure:

  • Liveness probes: to check if the application container is alive (passing) or dead (failing). If the check fails, the dead container is restarted to attempt to heal the application.
  • Readiness probes: to check if the application container is ready to receive requests (as even alive containers can enter phases where they cannot handle incoming traffic). Kubernetes only routes traffic to the application if the check succeeds.

Kubernetes Probes Workflow

liveness_probe.type

TypeDescription/Use CasePossible Values
stringAllows you to specify the type of liveness probe you want to launch.

HTTP probes are the most common probe type. You can use them if your application is a HTTP server, or if you create a lightweight HTTP server inside your application specifically to respond to such probes. When using a HTTP liveness probe, Kubernetes pings a path (for example: /healthz ) at a given port. If it gets a response in the 200 or 300 range, the application is considered healthy. Otherwise, it is considered dead and its container is restarted.

TCP probes are most often used when HTTP or command probes aren't an option. When using a TCP probe, Kubernetes tries to establish a connection on the specified port. If the connection is successful, the application is considered healthy. Otherwise, it is considered dead and the container is restarted.
"TCP" (default)
"HTTP"
"NONE"

Warning "NONE" disables the liveness probe, which we strongly advise against, as Kubernetes is then unable to check the state of your application.

liveness_probe.http_get.path

TypeDescriptionDefault Value
string(Optional/For HTTP liveness probes) When configuring an HTTP liveness probe, this advanced setting allows you to set the path to access on the HTTP/HTTPS server to perform the health check."/"

liveness_probe.initial_delay_seconds

TypeDescriptionUse CaseDefault Value
integerAllows you to specify an interval, in seconds, between the application container start and the first liveness check.Allowing additional time for the application to start can be useful when boot time usually takes too long (due to long boot operations), or when the application opens the port before being ready to receive traffic on it (due to a still ongoing boot operation).30

liveness_probe.period_seconds

TypeDescriptionDefault Value
integerAllows you to specify an interval, in seconds, between each liveness probe.10

liveness_probe.timeout_seconds

TypeDescriptionDefault Value
integerAllows you to specify the interval, in seconds, after which the liveness probe times out.5

liveness_probe.success_threshold

TypeDescriptionDefault Value
integerAllows you to specify how many consecutive successes are needed, as a minimum, for the probe to be considered successful after having failed previously.1

liveness_probe.failure_threshold

TypeDescriptionDefault Value
integerAllows you to specify how many consecutive failures are needed, as a minimum, for the probe to be considered failed after having succeeded previously.3

readiness_probe.type

TypeDescription/Use CasePossible Values
stringAllows you to specify the type of readiness probe you want to launch.

HTTP probes are the most common probe type. You can use them if your application is an HTTP server, or if you create a lightweight HTTP server inside your application specifically to respond to such probes. When using an HTTP readiness probe, Kubernetes pings a path (for example: /healthz ) at a given port. If it gets a response in the 200 or 300 range, the application is considered ready to receive traffic. Otherwise, incoming traffic is suspended.

TCP probes are most often used when HTTP or command probes aren't an option. When using a TCP probe, Kubernetes tries to establish a connection on the specified port. If the connection is successful, the application is considered ready to receive traffic. Otherwise, incoming traffic is suspended.
"TCP" (default)
"HTTP"
"NONE" (disables the readiness probe).

readiness_probe.http_get.path

TypeDescriptionDefault Value
string(Optional/For HTTP readiness probes) This advanced setting allows you to set the path to access the HTTP/HTTPS server to perform the health check."/"

readiness_probe.initial_delay_seconds

TypeDescriptionUse CaseDefault Value
integerAllows you to specify an interval, in seconds, between the application container start and the first readiness check.Allowing additional time for the application to start can be useful when boot time usually takes too long (due to long boot operations), or when the application opens the port before being ready to receive traffic on it (due to a still ongoing boot operation).30

readiness_probe.period_seconds

TypeDescriptionDefault Value
integerAllows you to specify an interval, in seconds, between each readiness probe.10

readiness_probe.timeout_seconds

TypeDescriptionDefault Value
integerAllows you to specify an interval, in seconds, after which the readiness probe times out.1

readiness_probe.success_threshold

TypeDescriptionDefault Value
integerAllows you to specify how many consecutive successes are needed, as a minimum, for the probe to be considered successful after having failed previously.1

readiness_probe.failure_threshold

TypeDescriptionDefault Value
integerAllows you to specify how many consecutive failures are needed, as a minimum, for the probe to be considered failed after having succeeded previously.3

Network Settings

network.ingress.cors_allow_headers

TypeDescriptionUse CaseDefault Value
string(For CORS users) Allows you to specify which set of headers can be present in the client request.For security purposes, you can indicate which HTTP headers can be used during a CORS preflight request which includes the Access-Control-Request-Headers request header. For more information, see CORS HTTP Response Headers."DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization"

network.ingress.cors_allow_methods

TypeDescriptionUse CaseDefault Value
string(For CORS users) Allows you to specify which set of methods can be used for the client request.For security purposes, you can indicate which HTTP methods are permitted while accessing a resource in response to cross-origin requests. For more information, see CORS HTTP Response Headers."GET, PUT, POST, DELETE, PATCH, OPTIONS"

network.ingress.cors_allow_origin

TypeDescriptionUse CaseDefault Value
string(For CORS users) Allows you to specify which origin(s) (domain, scheme, port) can access a resource.For security purposes, you can allow only one or a short list of origins to access your resources. For more information, see CORS HTTP Response Headers."*"

network.ingress.enable_cors

TypeDescriptionUse CaseDefault Value
booleanAllows you to enable Cross-Origin Resource Sharing (CORS).The CORS mechanism supports secure cross-origin requests and data transfers between browsers and servers. For more information on CORS and when to enable it, see Cross-Origin Resources Sharing.false

network.ingress.enable_sticky_session

TypeDescriptionUse CaseDefault Value
booleanAllows you to enable Sticky session.Enable the load balancer to bind a user's session to a specific target. This ensures that all requests from the user during the session are sent to the same targetfalse

network.ingress.keepalive_time_seconds

TypeDescriptionUse CaseDefault Value
integerLimits the maximum time (in seconds) during which requests can be processed through one keepalive connection. After this time is reached, the connection is closed following the subsequent request processing.Useful to tune your gRPC application3600

network.ingress.keepalive_timeout_seconds

TypeDescriptionUse CaseDefault Value
integerSets a timeout (in seconds) during which an idle keepalive connection to an upstream server will stay open.Useful to tune your gRPC application60

network.ingress.proxy_body_size_mb

TypeDescriptionUse CaseDefault Value
integerAllows you to set, in megabytes, a maximum size for resources that can be downloaded from your server.By default, users can download resources (files, images, videos...) of up to 100 MB. You can use this advanced setting to lower or increase this limitation.100

network.ingress.proxy_buffer_size_kb

TypeDescriptionUse CaseDefault Value
integerAllows you to set, in kilobytes, a header buffer size used while reading the response header from upstream.E.g. You are using Auth0 with NextJS, you will need to set a bigger header size4

network.ingress.proxy_connect_timeout_seconds

TypeDescriptionUse CaseDefault Value
integerDefines a timeout (in seconds) for establishing a connection with a proxied server. It should be noted that this timeout cannot usually exceed 75 seconds.E.g. You can use it to define the maximum time to wait for your application to establish the connexion.60

network.ingress.proxy_read_timeout_seconds

TypeDescriptionUse CaseDefault Value
integerDefines a timeout for reading a response from the proxied server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the proxied server does not transmit anything within this time, the connection is closed.E.g. You can use it to fine-tune your WebSocket application.60

network.ingress.proxy_send_timeout_seconds

TypeDescriptionUse CaseDefault Value
integerSets a timeout (in seconds) for transmitting a request to the proxied server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the proxied server does not receive anything within this time, the connection is closed.E.g. You can use it to fine-tune your WebSocket application.60

network.ingress.send_timeout_seconds

TypeDescriptionUse CaseDefault Value
integerSets a timeout (in seconds) for transmitting a response to the client. The timeout is set only between two successive write operations, not for the transmission of the whole response. If the client does not receive anything within this time, the connection is closed.Useful to define the maximum timeout to wait for client connection.60

network.ingress.whitelist_source_range

TypeDescriptionUse CaseDefault Value
stringAllows you to specify which IP ranges are allowed to access your application. The value is a comma-separated list of CIDRs, e.g. 10.0.0.0/24,172.10.0.1By default, any IP can access your application if it's exposed publicly and the users know the URL. You can limit its access by specifying the IPs you want to reach the app (e.g. the IP of your office)0.0.0.0/0 (any IP)

network.ingress.denylist_source_range

TypeDescriptionDefault Value
stringAllows you to specify which IP ranges are not allowed to access your application. The value is a comma-separated list of CIDRs, e.g. 10.0.0.0/24,172.10.0.1``

network.ingress.basic_auth_env_var

TypeDescriptionDefault Value
stringSet the name of an environment variable to use as a basic authentication (login:crypted_password) from htpasswd command.``

Here is an example where you can create a secret environment variable on Qovery and set a name like BASIC_AUTH_CREDENTIALS. The content should be the result of the htpasswd command:

$ htpasswd -n <username>
New password:
Re-type new password:
username:$apr1$jpwW4vG9$fwbzWBgRqARzNX93plDq20

The content of the BASIC_AUTH_CREDENTIALS environment variable should be: username:$apr1$jpwW4vG9$fwbzWBgRqARzNX93plDq20. To finish, set the network.ingress.basic_auth_env_var advanced settings to BASIC_AUTH_CREDENTIALS.

You can pass set credentials by separating them with a comma. For example: username1:$apr1$jpwW4vG9$fwbzWBgRqARzNX93plDq20,username2:$apr1$jpwW4vG9$fwbzWBgRqARzNX93plDq20. However, the total length of the environment variable should not exceed 1MB.

Auto-scaling

hpa.cpu.average_utilization_percent

TypeDescriptionDefault Value
integerAuto-scaling is triggered when a specific CPU utilization metric is reached (for instance, 40%). This advanced setting allows you to set this metric.60

Job Settings

job.delete_ttl_seconds_after_finished

TypeDescriptionDefault Value
integerBy default terminated jobs in a completed or failure state are not deleted. if this parameter is set, Kubernetes will automatically cleanup completed jobs after the ttlnull

cronjob.concurrency_policy

TypeDescriptionDefault Value
stringIt defines if it is allowed to start another instance of the same job if the previous execution didn't finish yet: Allow/Forbid/Replace)Forbidden

cronjob.failed_job_history_limit

TypeDescriptionDefault Value
stringAllows you to define the maximum number of failed job executions that should be returned in the job execution history1

cronjob.success_job_history_limit

TypeDescriptionDefault Value
stringAllows you to define the maximum number of succeeded job executions that should be returned in the job execution history1

Security

security.service_account_name

TypeDescriptionUse CaseDefault Value
stringAllows you to set an existing Kubernetes service account nameE.g. On AWS, you can assume a role on an application to give it specific AWS permissions without having to specify AWS credentials``