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
Scaling your deployments to zero is only half the battle. If your cluster autoscaler does not aggressively bin-pack and terminate the underlying worker nodes, you are still paying for idle metal. True environment sleeping requires tight integration between your ingress layer and your node provisioner to actually realize FinOps savings.
The biggest mistake enterprises make when evaluating Kubernetes management platforms is confusing infrastructure provisioning with Day-2 operations. Tools like Terraform or kOps are excellent for spinning up the underlying EC2 instances and networking, but they do absolutely nothing to prevent configuration drift, automate certificate rotation, or right-size your idle workloads once the cluster is actually running.
For years, Red Hat OpenShift has been the safe choice for heavily regulated, on-premise environments. It operates as a secure fortress. But in the public cloud, that fortress acts as an expensive prison. Paying proprietary per-core licensing fees on top of your standard AWS or GCP compute bill is a redundant "middleware tax." Escaping OpenShift requires decoupling your infrastructure from your developer experience by running standard, vanilla Kubernetes paired with an agentic control plane.
Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.
Kubernetes focuses on container orchestration, but the reality on the ground is far less forgiving. Provisioning a single cluster is a trivial Day-1 exercise. The true operational nightmare begins on Day 2. Teams that treat multi-cloud fleets like isolated pets inevitably face crushing YAML configuration drift, runaway AWS bills, and severe scaling bottlenecks.
Rancher solved the Day-1 problem of launching clusters across disparate bare-metal environments. But in 2026, launching clusters is no longer the bottleneck. The real failure point is Day-2: managing the operational chaos, security patching, and configuration drift on top of them. Rancher is a heavy, ops-focused fleet manager that completely ignores the application developer. If your goal is developer velocity and automated FinOps, you must graduate from basic fleet management to an intent-based Kubernetes Management Platform like Qovery.
The shift from AI copilots to autonomous agents is redefining infrastructure requirements. Discover how to build secure, stateful, and compliant Agentic AI systems using Kubernetes, sandboxing, and observability while meeting EU AI Act standards
.webp)