How a team of 15 developers deploys 4200 times per Month using the Preview Environments
Long story short, less than 30 days later, they have deployed more than 4200 times with dozens of preview environments. In this article, you will learn how this company multiplied by 43 their number of deployments and increased drastically their release cycles. Let’s go!
Before: 20 deployments per week
Before, the 15 developers were using a shared development environment. They struggled to release fixes and new features at the same time. The product managers in charge of the QA were also not able to validate every change with confidence. Worst, in the last months they faced multiple production outages since the staging and development environments were running on the same Kubernetes cluster. The CTO discovered our Preview Environment feature on Reddit and decided to contact us to see how it could improve their development workflow. After a demo call and a quick POC, they decided to move forward and promote it with their whole technical stack and more team members.
Their technical stack:
- 1 Rails application
- 1 Rails worker application with Sidekiq
- 1 Redis
- 1 RabbitMQ
- 1 MongoDB
- 1 MariaDB
- 1 Elasticsearch DB
- 1 Kibana
After: 850 deployments per week
Before getting started, I need to explain what is the concept of Preview Environment. Basically, Qovery provides a feature called “Preview Environment”. When turned on, you get a full replica of your production environment for every pull request. Meaning, every pull request can be tested in an isolated and ephemeral environment. When the pull request is merged, the Preview Environment is destroyed and the consumed resources are released. Now, you understand how it was possible to deploy 43 times more than before.
Here is a screenshot of the number of deployments per day. With a maximum of 650 deployments in a day. The average is around 220 deployments per day. During the weekend there is no deployment.
In less than 30 days, they crossed the 4200 deployments. Which results in an average of 9 deployments per day per developer. Which is much higher than Airbnb for a ratio - number of deployments per developer per month (Airbnb claims 125 000 deployments in a year).
Better production, staging, and development isolation
Improving the performance of the development team was the primary goal of using the Preview Environment, but since Qovery makes using multiple Kubernetes clusters seamlessly, they decided to use multiple AWS accounts and isolated Kubernetes clusters for the production, staging, and preview environments.
It’s 100% transparent for the developers and they have not to worried about where the applications are running.
Conclusion
Using Preview Environments helped this customer improve their release cycles by 43 times in less than a month. They also isolated their production and staging from the development environments to avoid causing production outages while running tests. With Qovery, they better structured their work with no loss in productivity.
Check out the Preview Environment feature presented by John Gramila 👇.
Special thanks to Alex for closely working with us.
---
.svg)
.svg)
.svg)
Suggested articles
The cluster coming up is the easy part. What catches teams off guard is what happens six months later: certificates expire without a single alert, node pools run at 40% over-provisioned because nobody revisited the initial resource requests, and a manual kubectl patch applied during a 2am incident is now permanent state. Agentic control planes enforce declared state continuously. Monitoring tools just report the problem.
The instinct when setting up Kubernetes observability is to instrument everything and send it all to your APM vendor. That works fine at ten nodes. At a hundred, the bill becomes a board-level conversation. The less obvious problem is the fix most teams reach for: aggressive sampling. That is how intermittent failures affecting 1% of requests disappear from your monitoring entirely.
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 structure, table, tool list, and code blocks are all worth keeping. The main work is fixing AI-isms in the prose, updating the case study to real metrics, correcting the FAQ format, and replacing the CTAs with the proper HTML blocks. The tool descriptions need the "Core strengths / Potential weaknesses" headers made less template-y, and the intro needs a sharper human voice.
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.
.webp)