👀 Reviewing

🔙 In Product Backlog

✏️ In Development

✅ Done

Main Roadmap

See and create backups for your databases

Manage database Backups

albane tonnellier

Extend Qovery with Sentry, e.g. for release tracking

Add ons - Sentry integration

Guillaume Gelin

Make Qovery supporting managed RabbitMQ. As a user I don't want to think about restarts, health checks, or ensuring the service is running. I don't want to mess with the config to make it fast.

Managed RabbitMQ

Make Qovery supporting managed Kafka. As a user I don't want to think about restarts, health checks, or ensuring the service is running. I don't want to mess with the config to make it fast.

Managed Kafka

In heroku it's very easy to capture a database backup and download it. It would be helpful to be able to do something similar here straight from the qovery shell.

Add ability to dump database from Qovery Shell

Kevin

On top of the TTL feature, it would be nice to be able to leave a comment on the Pull Request to destroy the Preview Environment (as when merged or declined).In our case we have Preview Environments created manually with the /qovery preview xxx-xxxx command. But in many cases a bug is discovered in the Preview Environment and there is no need to have the environment running because it may take hours/days to solve. Being able to have a command like /qovery preview destroy xxx-xxxx would be very helpful instead of having to close the pull request.

Manually Stop Preview Environment in Pull Request Comment

Moises Alejandro

I have an environment that has Start &amp; Stop enabled, and a cron job build failed, but the whole environment deployment was cancelled. A cron job build error should not cancel the whole environment.<img src="https://fb-usercontent.fra1.cdn.digitaloceanspaces.com/1713336664867..png">

Cron Job build error should not cancel environment deployment

Amazon has also been making Aurora a first class citizen within AWS for a while now especially with Amazon Aurora 2 coming out soon. I'd expect AWS will continue to push people to use Aurora over normal RDS PostgreSQL/MySQL DBs.So it would be amazing if Qovery could suppot Amazon Aurora. This "serverless" DB would greatly decrease costs for some users if they don't have constant load and be great for users with spikey and unexpected loads.

Support for Amazon Aurora

Aaron Hammer

Allow to disable pulling files that are included in git lfs.Sometimes we have many files in lfs, but don't need them during build, and our build times are currently slowing down

Allow to disable git LFS

Tim S.

Right now Preview Environments can only be triggered when the PR is to the branch of the service on the Blueprint environment.Example: app1 -&gt; development, app2 -&gt; master, app3 -&gt; development.<ul><li>If I create a PR in app1 from feature -&gt; development it will let me create a Preview Environment.</li><li>If I create a PR in app1 from feature -&gt; master it will not let me create a Preview Environment.</li></ul>Both cases it will have app1 with the branch feature for the Preview Environment and the rest as they are configured. It does not really matter where the PR is pointing to, the branch from where the PR was created is what it needs to be tested.

Create Preview Environment pointing to any branch

Sometimes I may need to store files on S3. Eg: I have a service that received images from users, I need to save the images and expose them publicly.

S3 storage

Support Docker Compose file to configure a Qovery environment and deploy complete apps.

Support Docker Compose file

Dark mode

It would be helpful if there was spot instance support for EKS clusters. We use spot instances in our non-critical clusters (dev and testing). We use eksctl to create spot node groups as follows: managedNodeGroups: name: my-new-asg instanceTypes: [“c5.2xlarge”, “c5d.2xlarge”, “c5n.2xlarge”, …] spot: true This is nice because it's all managed within our AWS account, and we don't have to signup for external services.

Support spot instances (GCP + AWS)

Kyle Flavin

Support Hetzner (Cloud Provider)

Utkarsh Kanwat

We should review the name and provide the important info somewhere else. Important info list:PR titlePR numberCreation timestampBranch name

Improve the information available on preview environment (title, branch, pr etc..)

We will deliver a new cluster view allowing you to better understand the current cluster consumption and what is consuming the most

Cluster usage view

Alessandro Carrano

We will let you define a TTL for your environment after which the environment will be automatically stopped and deleted. It will make sure that your environments won't run for nothing and you keep control on your cloud cost

Add environment TTL

We will provide more information on the deployment of your applications by providing you with the time that was necessary to: - Pull the source code - Build the app - Deploy the app The information will be available on both the deployment tab and the deployment log screens

Provide stats on deployment times

The feature to deploy Managed Database via Qovery is really really useful and nice.However it is not possible:<ul><li>to select the instance type. For the moment it is limited to "t3" kind.</li><li>to configure multi-az</li><li>to configure encryption at REST for data storage.</li><li>(in container mode) to change the number of replica (only 1 possible)</li></ul>This is not possible event for "Production" (Qovery tag) environment. Usually, a Production requires to be deployed in multi-AZ, using instances with CPU available all the time (not t3 like) and with encryption for data.Doing such configuration for managed DB (and maybe other managed services) would be really appreciated.

Enhance Managed Database configuration options

Jean-Philippe Fourès (IG1)

We will provide a simple way to deploy a prometheus stack and fetch metrics directly in the Qovery interface. You will still be able to deploy an additional grafana board for more complex use cases or deploy your own monitoring solution (Datadog, newrelic etc..)

Application and Cluster monitoring

Pranas

Today you can trigger only one deployment at a time within one environment. If a deployment is ongoing on the environment and you try to trigger a second deployment, you will get an error message telling you that the operation is not allowed (since another deployment is ongoing) The objective will be to allow you to trigger other deployments if there's one already ongoing. At the minimum we will provide the possibility to queue the deployments without having you wait for the deployment to end, improvements could be done in the future to parallelize the operations (if the deployment is not on the same service)

Allow to trigger a deployment if another one is already ongoing on the same environment (queue deployments)

We will review the way “Managed clusters” are updated, adding a strict process between non-production and production clusters, maintenance windows etc..

Improve the way Managed Clusters are updated

Today, after a change on the service configuration, we add a banner telling you need to redeploy to apply the change. This is true for all the settings of the service except for changes on the environment variables. The objective of this task is to cover them as well so that when a change on an environment variable is done, a banner will be added on your service asking you to redeploy

Ensure that the environment variable change has an impact on the service deployment status

You will have the possibility to natively deploy Terraform scripts via Qovery. Today you can already deploy them via the lifecycle job, see https://github.com/Qovery/terraform-examples/

Natively Support Terraform Deployment

We will review the entire deployment log view to simplify it and ensure that you can be autonomous in solving most of the deployment errors you might face.

Improve deployment error troubleshoot

We will support MySQL 8.4 for both container and managed database (only AWS RDS)

Support MySQL 8.4

We will upgrade your managed clusters to version 1.31

Kubernetes upgrade 1.31

We will introduce a new status for the cluster to give you a view of its healtiness. Today only the last deployment status is available

Add Cluster status

For your Qovery managed cluster on AWS, we will work on creating a version for Karpenter (the new node autoscaler) capable to support production workloads

Karpenter for production workloads (AWS Managed)

Support Google Cloud Platform (GCP)

Romaric Philogène

Support Azure

Create a deploy cronjob with Qovery - a cronjob is a one-time or recurrent process. It can be used to do the batch processing and background compute.

Linked to: PRDT-588

Support cronjob

Speed up the deployment of your environment by building and deploying in parallel the services belonging to a same deployment stage (instead of a sequential deployment). 

We will also deliver a new version of the deployment logs allowing you to properly follow the deployment

Parallelize builds and deployments

Support Github Actions CI integration within Qovery

Github Actions

Add the possibility to add custom tags / labels on the resource managed by Qovery that should be replicated on the cloud provider entities (clusters, pods, managed databases etc..). This will make it more simple to monitor those resources via the standard monitoring tools (datadog etc..)

Customize labels/tags on resources

Extend Qovery with slack integration add on

Please refer to [this thread](https://discuss.qovery.com/t/qovery-slack-integration-what-do-you-need-and-expect/1052/2) on our forum to share your feedback.

Linked to: PRDT-755

Add ons - Slack integration

The ability to use a wildcard subdomain as the domain for an application.
Currently can only use a fixed domain:

`myapp.com`

but we need to be able to use:

`*.myapp.com`

Wildcard subdomains

Ryan Marshall

Allows team members to login from a Google account.

Today we can only login via GitHub, and most developers have their personal email there.

Allowing to connect via Google would let us connect via our work email address.