Ephemeral Environments for GitLab Merge Requests with Flux Operator

Overture

ControlPlane’s Stefan Prodan, a CNCF Flux core maintainer, recently shared a great technical guide on a new feature of the Flux Operator to automate ephemeral preview environments for GitLab Merge Requests. This blog distils Stefan’s work to offer a high-level overview, focusing on how this feature can improve dev workflows and the value it brings to the business. Software development must move fast, and developers need environments that keep up. Traditionally, validating application changes before merging meant relying on shared staging environments or setting up local Kubernetes clusters—both time-consuming and prone to conflicts. Now, with the Flux Operator ResourceSet APIs, developers can get ephemeral preview environments automatically provisioned for each GitLab Merge Request (MR), providing secure, dedicated, production-like environments without requiring developers to touch Kubernetes, Helm, or YAML. This new capability in the Flux Operator ensures that every MR gets its own isolated preview instance, making code change validation and feature iteration faster and less wasteful, thus reducing actual deployment failures and streamlining GitLab-based workflows.

Current Challenges in Pre-Merge Testing

We see that organisations may struggle with inefficient pre-merge testing workflows:

• Difficulty Testing External Services: Many applications rely on databases, APIs, or third-party integrations (e.g., RDS, message queues). Local setups fail here. Moreover, developers cannot safely modify or isolate dependencies in a shared staging setup without affecting others
• Risk of failed deployments: Code that “works on my machine” often breaks in staging due to undetected issues
• Configuration complexity: Setting up local Kubernetes environments can be complex, and modifying shared clusters creates friction
• Churn & Failed Deployments in Staging: Without pre-merge testing, developers only catch issues after merging. If a bug or misconfiguration causes failures in staging, rolling back or fixing it wastes valuable time.
• Manual Coordination & Bottlenecks: Developers often need approval from DevOps or platform engineers to deploy to staging. If infrastructure issues arise, developers may be blocked until platform teams investigate
• Wasted infrastructure resources: Persistent environments consume compute and storage, even when not in use These challenges slow development and increase operational burden, making delivering software quickly and reliably harder.

A Unified, Scalable Approach with GitLab and Flux

For the very few readers who do not know what GitLab is, it’s an all-in-one DevSecOps platform that enables modern organisations to transform the way software is built and delivered, providing teams with seamless collaboration, automation, and security. By integrating with Flux and the Flux Operator, GitLab supercharges its continuous delivery (CD) capabilities, enabling GitOps-driven deployments that are automated, scalable, and Kubernetes-native. This means that application changes are continuously validated, deployed and managed within Kubernetes clusters using declarative configurations—reducing manual intervention and ensuring consistency across environments.

Why “supercharge”? With ephemeral preview environments managed through the Flux Operator, DevOps teams can implement workflows that are:

• Production-like: Applications run in an environment close to Production, allowing to iterate over a feature, without deploying each time to Staging.
• Fully automated: Developers push code and tag their MR, Flux handles the rest
• Isolated per MR: Each MR gets a dedicated Kubernetes namespace and Helm release
• Self-cleaning: Resources are automatically removed when an MR is merged or closed.

Let’s look at an example of how the Flux Operator ResourceSet API can automate the entire preview deployment process:

1. A developer submits a Merge Request with changes to the application code and Helm chart
2. GitLab CI builds and pushes the application container image, tagging it with the Git commit SHA
3. Another developer labels the MR with deploy/flux-preview
4. The Flux Operator detects the MR and provisions a Helm release using the MR number and commit SHA
5. The application is deployed in a dedicated preview namespace, accessible via a unique URL
6. Each new commit to the MR triggers an automatic Helm upgrade, ensuring the preview stays up to date
7. When the MR is merged or closed, the preview instance is deleted, freeing up resources

This workflow enables teams to iterate on features in isolation, test real-world interactions, and avoid costly deployment failures.

Strategic Benefits for Teams

For Developers: A Frictionless Testing Experience

• No need to configure Kubernetes or write YAML—just tag an MR and get a preview URL
• Test against real external services without setting up local environments
• Iterate on features independently without breaking shared environments

For Operations: Streamlined Infrastructure Management

• No persistent staging environments eating up resources.
• Automatic clean-up prevents infrastructure bloat.
• Consistent, GitOps-driven deployments with Flux ensure reliability.

For Security Teams: Reduced Risk and Better Governance

• Developers don’t need direct Kubernetes access—permissions are centrally managed.
• Policies can be enforced consistently across all preview environments.
• Standardised deployment patterns minimise misconfigurations.

The Business Value: Speed, Security, and Cost Efficiency

Ephemeral preview environments powered by Flux Operator and GitLab offer significant benefits that positively impact both development teams and the overall business. By automating the creation and teardown of isolated environments for every GitLab Merge Request, teams eliminate the need for manual approvals or coordination with platform teams. This leads to faster development cycles, with teams able to validate code quickly and confidently in environments that mirror production. As a result, developers catch issues earlier in the process, reducing the risk of failed deployments and the associated costs of debugging or rolling back changes.

In addition, the automatic clean-up of environments when MRs are merged or closed helps eliminate waste, ensuring resources are used efficiently. With persistent environments no longer needed, businesses reduce the operational burden of managing complex infrastructure. This leads to lower costs in compute and storage, as resources are only allocated when necessary, and eliminates the need for costly over-provisioning of environments.

Security is strengthened with centralised access control and consistent enforcement of policies across all preview environments. Developers do not need direct access to Kubernetes clusters, minimising the risk of misconfigurations or security breaches. With a standardised deployment process, security teams can enforce best practices and ensure governance without slowing down development. Additionally, each preview environment is isolated and temporary, limiting exposure to potential security vulnerabilities that might arise in a shared environment.

From an efficiency standpoint, businesses see a reduction in manual intervention and operational bottlenecks. With a fully automated process in place, platform teams can focus on strategic initiatives rather than being bogged down by routine environment management. The self-service nature of the system gives developers more autonomy, while operations can rest assured that the infrastructure is optimised and clean. This combination of automation, isolation, and seamless integration with GitLab ensures that teams can move faster, deploy with confidence, and maintain control.

Finally, the cost savings associated with ephemeral environments are substantial. By using infrastructure only when it’s needed and automatically removing resources after the MR process is completed, businesses reduce wasteful spending on idle environments. This approach aligns resource usage directly with demand, leading to a more cost-effective infrastructure strategy. Additionally, the streamlined workflow reduces the overhead associated with maintaining multiple environments and eliminates the complexities of managing staging infrastructure.

Call to Action

If you’re ready to transform your development process, reduce deployment risks, cut infrastructure costs, and empower teams to iterate faster and more securely, please reach out to [email protected] to discover how we can support you, your teams, and your organisation on this journey.