Time-based application scaling

Questions and Answers
1

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
2

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, ...}' \
  "https://api.qovery.com/application/:appId"
  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"}' \
  "https://api.qovery.com/application/:appId/deploy"

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.