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
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.
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.
Optimizing Kubernetes on AWS is less about raw compute and more about surviving Day-2 operations. A standard failure mode occurs when teams scale the control plane while ignoring Amazon VPC IP exhaustion. When the cluster autoscaler triggers, nodes provision but pods fail to schedule due to IP depletion. Effective scaling requires network foresight before compute allocation.
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.
.webp)