Support canary deployments

Allow to manage a canary pool during the deployment phase, increasing traffic gradually on the new version It will help to easily validate that all works on a new version and release gradually the change

Alessandro Carrano 28 days ago

Better support front-end application deployment

SPA usually store assets on a cdn or S3 bucket. today we let this deploy via a contenerized application but instead we should support the deployment of front-end apps directly on a S3 or CDN

Alessandro Carrano About 1 month ago

Sep 30

Allow to kill a specific pod

Today, when a pod misbehaves, there’s no easy way to kill the pod and let a new one spawn. We will let you kill one of the pods of your applications without having to re-deploy or restart to clean up the misbehaving pod

Alessandro Carrano About 1 month ago

Refactor built_in system and use metadata instead

we will refactor our built_in environment variable system by not injecting by default every built_in variable. instead, you will be able to define which metadata you want to use in your service/environment

Alessandro Carrano About 2 months ago

Force delete environment or services

Allow to force delete an environment or a service. There are a few cases where there remote resources do not exist anymore, and you want to force delete the configuration on Qovery, since otherwise the delete operation will fail. Example: - The resources managed by a lifecycle job has already been deleted manually and thus the lifecycle job is failing during the delete operation

Alessandro Carrano About 2 months ago

Jun 30

Add your own custom icon for services

today you can already change the icon of your service by selecting one among a pre-selected set. we will give you the possibility to upload your own custom icon

Alessandro Carrano 2 months ago

Upgrade to Kubernetes 1.32

We will upgrade your managed clusters to version 1.32

Alessandro Carrano 2 months ago

Jun 30

Preview environment - customize environment name

We will let you customize the preview environment name. Today it is fixed with “[PR] - ” but we will let you compose the naming via a set of macros (example “{{PR_ID}}-preview”)

Alessandro Carrano 3 months ago

Terraform provider - Separate resource to manage cluster routing

If we had a dedicated routing table resource in the Qovery terraform provider, we could then chain 1, 2 and 3 directly: We create the cluster, and so we can get the VPC ID created by Qovery, We can then create the peering connection (using the VPC ID), that will create a connection ID, We can create the routing table using the connection ID. Today, it is in the cluster. So it requires at least two deployments: Deploy the cluster and the peering connection, Update the code to add the routing table, Re-deploy to update the cluster with the routing table.

Alessandro Carrano 3 months ago

Jun 30

Terraform exporter for the entire cluster

Allow to export the overall cluster and each environment within it as a terraform manifest

Alessandro Carrano 3 months ago

Add custom nodepool for Karpenter

For Karpenter setup, we will add the possibility of creating new node pools on top of the two default ones (stable and default)

Alessandro Carrano 3 months ago

Access environment namespace information from a service/API/Terraform provider

We will pull the information of the namespace used to deploy your environments and make it available on the UI but also on our terraform provider

Alessandro Carrano 3 months ago

Jun 30

Access VPC information from a service/API/Terraform provider

We will pull the VPC (or similar) information from your cloud account and make them available on our control plane. These can be useful for: - deploy a terraform module that needs to know the VPC information dynamically - automate the configuration of VPC peering if you deploy your cluster via our terraform provider

Alessandro Carrano 3 months ago

1

Jun 30

Provide additional Cloud provider cluster information (name, id, oidc, arn)

When qovery creates a cluster on the user cloud account, it assigns a name (usually qovery-z) and it is not visible in the UI and cannot be retrieved from the API/Terraform provider. Moreover, the cloud provider might assign its own ID and it is not retrievable through Qovery. we will provide you with those information on both the UI and the terraform provider we will also provide the oidc url and the cluster ARN

Alessandro Carrano 3 months ago

1

Jun 30

Region - Support for Mexico (Central) mx-central-1

Recently the new region was launched and we would like to use that region. https://aws.amazon.com/blogs/aws/now-open-aws-mexico-central-region/

moises 4 months ago

4

Jun 30

Allow export of all users with Qovery access

We perform quarterly access reviews of our service. The users have to be manually extracted from the “Members” page today. It would be helpful to be able to export our users, their role, and their last login as a CSV.

Kyle Flavin 4 months ago

2

Access to repositories via a GitHub application

We will revamp the existing Qovery GitHub application that has been decommissioned a few months ago.

Alessandro Carrano 4 months ago

Helm diff command

we will create a new action helm diff capable to run a helm diff on the helm charts you deploy with Qovery. This will allows you to verify what will happen on a configuration change (values file modified for example) before deploying the chart

Alessandro Carrano 4 months ago

disable modifications when resources are managed via TF provider

allow to disable modifications via the UI/CLI on any resource that it is managed via the Qovery TF provider. a safety mechanism has to be planned to ensure that editing is still allowed in case of issues

Alessandro Carrano 5 months ago

More fine-grained permission management

we would like to have a more fine-grained permission management so that we could create roles with a fully customized composition of roles.

Alessandro Carrano 5 months ago