Time-based application scaling

We are thinking about adding some time based scaling policies that during certain times of the week the minimum instances of an app running is changed.

How can we achieve that? I didn’t see an endpoint in your API adjusting application ressources.

If I adjust application ressources via UI it always requires a redeplyoment - why that? We aren’t changing anything to the code just some corner stones of the application. If everytime we would do time based scaling via API triggers/requires a redeployment of that process, this might interfere with actual deployments from CI/CD.

1 Like

To adjust your app resources, you need to call two main API endpoints:

  1. Update the application min and max number of instances. (API documentation)
curl -X PUT -H "Authorization: Token <your_API_token>" \
  -d '{"min_running_instances": 4, "max_running_instances": 8, ...}' \
  1. Redeploy your application to apply the changes (there is no downtime, Qovery will just update your app configuration) (API documentation)
curl -X POST -H "Authorization: Token <your_API_token>" \
  -d '{"git_commit_id": "xxxyyyzzz"}' \

We have decided to make the redeployment and application configuration changes explicit by running a redeployment. It’s probably in the future we’ll make it more fluent. But behind the scene, it will be similar since Qovery is a remote system. You can check my live conference here explaining how Qovery works under the hood.

It will not interfere with your CI/CD if you do not change the commit_id while redeploying. (BTW you can also use the /application/:appId/restart API endpoint).

However, if you use the Qovery Terraform Provider it might interfere if you don’t centralize your TF state.