May 2020, What's new? Custom domain, dotenv file, CLI improvements, Hasura Con 2020
Hello 👋,
In this Newsletter, we're happy to introduce some updates: Custom domain, dotenv file, CLI improvements, and new resources.
Product updates
Custom domain
It is now possible to use your domain name with Qovery. You can put one or more domain names per application and environment. Read more...
Dotenv file
Qovery supports environment variables in dotenv (.env) file. It's as simple as adding a ".env" file at the root of your project with your environment variables. Read more...
CLI improvements
Tons of improvements have been made on the Qovery CLI. First, upgrade it now! Here are the improvements:
- New feature: "qovery template <template_name>" command allows you to quickly bootstrap a project with the most popular frameworks</template_name>
- New feature: "qovery redeploy" command lets you redeploy your application
- New feature: "qovery domain" command allows you to manage your custom domains
- Improvement: More descriptive error messages
- Improvement: Better .qovery.yml and Dockerfile configuration checker
- Improvement: Better Windows 10 support
- Improvement: "qovery init" command has a better onboarding flow
New documentation
We are happy to announce that our new documentation website is out!
What's new inside?
- A rewritten documentation from scratch
- A Getting Started guide to handle Qovery in 15 minutes.
- A tutorial section to share development best practices.
Feedback / Roadmap
Your feedback is welcome, they help to improve our product, and we'll do our best to do them. Also, do not hesitate to vote for wanted features or submit your ideas.
Community
Thanks, Alexis
Big thanks to Alexis Viscogliosi. We appreciate your contributions.
Alexis' contributions:
- Qovery extension for Visual Studio Code (available in the marketplace)
- Qovery extension for Intellij (available in the plugins)
- Your detailed feedback on Qovery
Alexis, you are officially part of our Qovery contributors! 🎉
Do you want to contribute and receive our contributor gifts? Join us on Discord
Are you a passionate technical writer?
Do you like to share your knowledge and your passion for the code? We are looking for two technical writers for an ambitious new project. Interested? Contact us
Resource highlights
Interesting reading from the last month
- Article: Differences between Heroku and Qovery
- Tutorial: Creating a blazing fast REST API in Rust (Part 1/2)
- Tutorial: How to deploy a Docker container
- Tutorial: How to deploy Hasura with PostgreSQL (GraphQL framework)
- Tutorial: How to deploy Gin (Golang HTTP framework) with PostgreSQL
- Tutorial: How to deploy Django with PostgreSQL (Python framework)
What's next?
Here is what we are working on this month
- Web interface: The first release of the Qovery web interface is expected for next month (June).
- Talk: We speak at the Hasura Con' 2020.
- Gitlab: We plan to support Gitlab repositories before the end of this month (May).
- Tool: We are preparing to launch a tool to help the developers to choose the right database. (Do you want to know more? Contact us)
- DX: We work to improve the speed of deployment
As always, we would love to get your feedback on these updates.
That's all folks
The Qovery Team.
.svg)
.svg)
.svg)
Suggested articles
Kubernetes success is determined by Day 2 execution, not Day 1 deployment. While migration is a bounded project, maintenance is an infinite loop that often consumes 40% of senior engineering capacity. To protect margins and velocity, enterprises must transition from manual toil to agentic automation that handles scaling, security, and cost.
Day-0 is planning, Day-1 is deployment, and Day-2 is the infinite lifecycle of maintenance. While Day-0/1 are foundational, Day-2 is where enterprise operational debt accumulates. At fleet scale (1,000+ clusters), managing these differences manually is impossible, requiring agentic automation to maintain stability and eliminate toil.
A multi-cluster Kubernetes architecture distributes application workloads across geographically separated clusters rather than a single environment. This strategy strictly isolates failure domains, ensures regional data compliance, and guarantees global high availability, but demands centralized Day-2 control to prevent exponential cloud costs and operational sprawl.
Stop overpaying for Kubernetes observability. Learn how in-cluster monitoring and AI-driven troubleshooting with Qovery Observe can eliminate APM ingestion fees, reduce SRE bottlenecks, and make your cloud costs predictable.
Kubernetes multi-cluster management is the Day-2 operational practice of orchestrating applications, security, and configurations across geographically distributed clusters. Because native Kubernetes was designed for single-cluster orchestration, enterprise platform teams must implement a centralized control plane to prevent configuration drift and manage a global fleet without scaling manual toil.
Achieving zero-downtime deployments on Kubernetes requires more than running multiple pods. It demands a standardized architecture utilizing Pod Disruption Budgets (PDBs), precise liveness and readiness probes, pod anti-affinity, and graceful termination handling. At an enterprise scale, these configurations must be enforced via a centralized control plane to prevent catastrophic configuration drift.
.webp)