Q2 2022 product retrospective - Last quarter's top features

#Qovery V3

You are not mistaken; the Qovery Console V3 is in Alpha testing! After a full quarter of work, our teams can finally show you what they have been working on for the past three months, and even if this V3 is in Alpha and many things are missing, we can’t. Wait for you to try it out! From a better developer experience to more transparency, a lot has been improved from the V2 to the V3 but don’t take my words for granted; watch this demo that will tell you everything you need to know about it or read this article to know it all.

#Qovery EC2

Until today, Qovery was relying on an AWS EKS (Managed Kubernetes by AWS) to deploy your apps. This service costs you $220/month. Regardless that you deploy 1 or 10 applications. Our team has been working for 2 months now on a $20/month offer to host your apps on AWS - Qovery AWS EC2. The difference? Qovery no longer spawns an AWS EC2 instance instead of an AWS EKS Kubernetes cluster. It's the perfect solution for your hobby project and testing environments. The main difference between AWS EC2 and AWS EKS is the number of Availability Zones (AZ). If a network or power disruption happens on the AZ where the EC2 instance runs, your applications will no longer be available until it's solved. It's an acceptable outage for most of the development and hobby projects. That's why we only recommend running development and hobby projects on an EC2 instance!

#Slack

If you'd like to automatically notify your team on a Slack workspace whenever a change has occurred on your apps, this Integration will help you out. You can choose which actions should trigger messages on your Slack workspace. If you want to know how to set it up, here is the full tutorial or here is a little demo.

#[Terraform] Improve Terraform integration

If you’re following us, you probably saw the Qovery demo day that we organized last week, where Bilel (Software Engineer at Qovery) explained all the improvements added to the Terraform integration; if you want to take a look at the whole demo day, it’s here. Otherwise, I added the part about Terraform right below, but in a nutshell, the changes were:

• Add the VPC peering feature to the cluster
• Use Qovery’s API token
• Use instance type to create the cluster instead of CPU/ RAM
• Add build-in environment variables to the application, environment and project
• Add secrets to the application, environment and project
• Various bugs and fixes and stability improvement
• Functional tests

#[API] Advanced settings

Qovery already allows you to customize quite a lot of parameters in your application (RAM, storage, Networks…); for most of our clients, it’s more than enough to have their applications up and running the way they want, but we are aware that some specific industry or more prominent companies might require more, that’s why we created the advanced settings: a section that you can find in the API only for now.

Nb: the section will grow within the next sprints.

#[API] Handle application deployment delay time (via Advanced settings)

The first functionality of this brand new advanced settings panel, if you want to define a "delay time" (in seconds) for your application to start receiving traffic only after that specified amount of time, it’s now possible. Now, you might ask: why would I want that? This is necessary to handle applications taking a long time to boot (using JVM etc..). Until now, we were waiting for the app to be deployed without checking if the application could receive traffic, and this could cause an impact on the first rollout and application updates. Still, this time is now over cause this new feature got you covered.

As part of the advanced settings, this is only available in the API for now.

#Others

• New pricing slider for sign up
• Add Preview Environment URL in comment into Pull Request page
• Filter logs by pod name
• Allow using an URL to connect via the Qovery shell command
• Github - Handle permission per repository
• “Delete organization” API call does not work when there are no clusters
• Can’t switch database from private to public and vice versa (container side)
• Accept instance type selection in cluster setup + provide an endpoint to list available instance types
• Display in logs if the Docker cache is used correctly
• Desired nodes should be higher or equal to min node
• Refresh application metrics when switching between apps and during deployment
• Refactoring Open-API: removing Response

Do you want to know what’s next? You can find our progression in the Changelog section of our website where we post every two weeks.