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 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
Effective Kubernetes management in 2026 demands a shift from manual cluster building to intent-based fleet orchestration. By implementing agentic automation on standard EKS, GKE, or AKS clusters, enterprises eliminate operational weight, prevent configuration drift, and proactively control cloud spend without vendor lock-in, enabling effective scaling across massive fleets.
A Kubernetes single pane of glass is a centralized management layer that unifies visibility, access control, cost allocation, and policy enforcement across § cluster in an enterprise fleet for all cloud providers. It replaces the fragmented practice of switching between AWS, GCP, and Azure consoles to govern infrastructure, giving platform teams a single source of truth for multi-cloud Kubernetes operations.
Deploying a Docker container on Kubernetes requires building an image, authenticating with a registry, writing YAML deployment manifests, configuring services, and executing kubectl commands. While necessary to understand, executing this manual workflow across thousands of clusters causes severe configuration drift. Enterprise platform teams use agentic platforms to automate the entire deployment lifecycle.
At enterprise scale, managing provider-specific Kubernetes YAML across multiple clouds creates crippling configuration drift and operational toil. By adopting an agentic Kubernetes management platform, infrastructure teams abstract cloud-specific configurations (like ingress controllers and storage classes) into a single, declarative intent that automatically reconciles across 1,000+ clusters.
To stop GPU costs from destroying SaaS margins, teams must transition from static to consumption-based infrastructure by utilizing Karpenter for dynamic provisioning, maximizing hardware density with NVIDIA MIG, and leveraging Qovery to tie scaling directly to business metrics.
AI is helping developers write more code, faster than ever. But writing code is only half the story. What happens after? Building, deploying, debugging, scaling. That's where teams still lose hours.We're building Qovery for this era. Not just to deploy your code, but to make everything that comes after writing it just as fast.
.webp)