Deploying with the auto-deploy feature

Once you have configured your services and deployed them for the first time, you can decide to automatically update the applications to the latest version of your git branch thanks to the auto-deploy feauture.

Each time a commit is pushed on your git repository, Qovery receives a webhook call containing the commit information (who did it, what changed, which branch etc..). Thanks to this information, Qovery is able to determine which application should be automatically re-deployed with the new version.

How to activate it

The auto-deploy feature can be activated from the application settings, by switching on the auto-deploy flag.

Auto-deploy settings

It can also be activated on the first step of the service creation flow

Auto-deploy creation flow

Once this flag is activated, every new commit pushed on the branch of the application will trigger an automatic deployment of the new version.

Filtering commits triggering the auto-deploy

By default every new commit pushed on the branch will trigger a deployment of the application. You can use the Deployment restrictions feature to include or exclude certain files or folders from the feature and avoid un-necessary deployments (like a change on the README file).

To add a new restriction, go into the Deployment restrictions section of your application settings.

Deployment restrictions

When adding a new restriction, two modes can be selected:

  • EXCLUDE: commits on the file or folder defined in the "Value" field will be ignored
  • MATCH: only commits on the file or folder defined in the "Value" field will trigger a deployment

Note:

  • "Value" should contain the full file path and can't start with /
  • Wildcards are not supported in the "Value" field (you can specify "my-prefix*" to exclude commits on files starting with "my-prefix")

Auto-deploy and container images

The auto-deploy feature can be activated as well if you directly deploy your container images but it requires some additional integration via your CI/CD. Your CI/CD has to inform Qovery that a new version of the image (a new tag) is available for a specific container image. Thanks to this information, Qovery can find any application that uses this container image and automatically trigger a deployment of the new image tag.

To inform Qovery of the new version, your CI/CD needs to call the following endpoints, depending on the service type:

FAQ

Can I exclude some commits from the auto-deploy feature

Yes, take a look at this section.

Are my stopped services restarted

If you have the auto-deploy feature activated on your service and you stop it, the next commit on the service's branch won't start the service. You have to manually start it.

How does it work with mono-repositories

The auto-deploy feature works on mono-repositories as well, triggering a deployment of any service linked to the mono-repository. If you want to trigger a deployment only if a commit is done on the sub-folder of the app, add a Deployment Restriction to include only that repository. (Have a look at this section)

Does Qovery check if a new image is available for my service

No, there's no automatic hook on your container registry verifying that a new image is available to trigger a deployment. You have to inform Qovery about the new version and trigger a deployment:

  • manually: updating the version on the console and triggering a deployment
  • CLI: deploying the new version with the qovery <service> deploy --tag command. See this section
  • via the API: you have two options -- call the deployment endpoint with the new tag for that service -- use a auto-deploy containers endpoint that will trigger the deployment of any service using the same image within the organization and having the auto-deploy feature activated
Contents
Resources