As AI-assisted development tools flood CI pipelines with unprecedented volumes of code changes, Kubernetes teams are hitting a breaking point. The traditional approach of spinning up ephemeral test environments for every build-already slow and expensive-can’t keep pace with the dramatic increase in parallel CI runs that AI-generated code demands.
MetalBear believes it has a solution. The company has launched mirrord for CI, introducing what it calls “real-environment CI”-a fundamentally different approach that enables multiple CI jobs to run concurrently against a single, production-like staging environment without interfering with each other. Early adopters like monday.com are reporting significant reductions in CI runtime by eliminating the time-consuming environment provisioning phase entirely.
In this VMblog Q&A, Aviram Hassan, CEO & Co-Founder of MetalBear explains how real-environment CI works, how it maintains isolation and security when connecting CI runners to shared Kubernetes clusters, and why this approach may become essential as the volume and velocity of code changes continue to accelerate.
++
VMblog: What problem in modern CI pipelines led MetalBear to build mirrord for CI, and why does this problem feel more urgent now for Kubernetes teams?
Aviram Hassan: Modern CI pipelines depend heavily on integration and end-to-end tests to validate changes before they reach production. The challenge is that these tests need a realistic environment to run against. Since in CI, where many builds run in parallel, the common solution is to spin up ephemeral environments per run to maintain isolation for each test run. In practice, this approach is slow, fragile, and expensive to operate and maintain.
This problem has become far more urgent for Kubernetes teams as AI-assisted and AI-generated code dramatically increase CI parallelism. An order-of-magnitude jump in the number of concurrent builds pushes ephemeral environments past their breaking point. Teams are increasingly forced to choose between slow, costly pipelines or reduced test coverage and lower confidence when shipping, precisely at a moment when the volume and variability of new code demand more testing, not less.
VMblog: You’re introducing the term “real-environment CI.” How is this fundamentally different from traditional CI approaches that rely on mocks, staging replicas, or ephemeral clusters?
Hassan: Most organizations already have an environment that closely mirrord production – their staging environment. Maintaining these environments with the scale, configuration, and data necessary for true production parity is operationally expensive and time-consuming, so teams usually run only one or a small number of them, shared across many engineers. This creates contention and friction: staging becomes a scarce resource, engineers delay using it for as long as possible, and one of the most valuable testing assets ends up underutilized.
mirrord for CI’s real-environment CI concept builds on mirrord’s ability to provide concurrent, isolated access to a shared cloud environment. By extending this capability from local development to CI runners, it enables many CI jobs to run simultaneously against a production-like environment without interfering with each other. The result is higher-fidelity testing, faster CI execution, and significantly lower cloud costs compared to spinning up and maintaining ephemeral clusters.
VMblog: How does mirrord for CI safely connect CI runners to a shared Kubernetes environment?
Hassan: mirrord for CI safely connects CI runners to a shared staging environment by combining multiple isolation and control mechanisms:
- Traffic Filtering ensures that only explicitly selected network traffic is intercepted by the CI runner, while all other traffic continues to flow normally within the cluster.
- Database Branching allows CI runs to operate on isolated, ephemeral branches of shared databases for the duration of a test suite, preventing any impact on shared state.
- Queue Splitting enables CI runners to selectively consume messages from shared message queues without affecting other consumers.
- mirrord Policies provide administrators with guardrails to tightly control what CI runners are allowed to access or modify, preventing accidental or unauthorized interference with the environment.
By layering these capabilities, mirrord for CI enables safe, isolated CI execution on shared environments while preserving the integrity and stability of staging workloads.
VMblog: From a developer or platform team’s perspective, what changes in day-to-day workflows when mirrord for CI is added to an existing pipeline?
Hassan: From a developer or platform team’s perspective, very little changes in the day-to-day workflow. mirrord for CI is introduced as a simple CLI wrapper, mirrord ci start, around the existing service startup command in the pipeline. Running a microservice with this command automatically connects it to the shared Kubernetes environment, with no code changes required.
Once connected, the same integration or end-to-end test suite that previously ran against an ephemeral environment can be executed against the shared environment instead. The only real difference is that the pipeline no longer needs to spin up and manage per-run environments.
VMblog: Can you walk through a concrete example of the types of integration or environment-specific issues mirrord for CI helps teams catch earlier than traditional CI setups?
Hassan: In traditional CI setups, ephemeral test environments are usually thinner, simplified versions of production. They have to be. otherwise it would be impractical to spin them up and tear them down on every CI run. As a result, they often lack the full set of production configurations, policies, integrations, and realistic data or database state that real Kubernetes environments exhibit.
A common failure mode is a service that passes CI when tested against these simplified environments, but breaks once it’s deployed to staging or production. For example, a microservice may work with mocked dependencies or a clean, empty database, but fail in a real cluster due to network policies, service mesh behavior, missing RBAC permissions, or unexpected interactions with existing database state.
By running CI tests directly against a shared, production-like Kubernetes environment, mirrord for CI helps teams surface these issues earlier. Problems that would traditionally only appear during staging validation or even in production are caught during CI, in full isolation, without causing any collateral impact on the shared environment.
VMblog: Early users like monday.com report significant CI runtime reductions. Where do those time and cost savings primarily come from?
Hassan: The runtime reductions primarily come from removing the need to provision ephemeral test environments. Spinning up these environments often takes a significant amount of time – sometimes longer than the test execution itself – and that overhead increases as systems grow larger and more complex.
By running CI tests directly against an existing shared environment, mirrord for CI eliminates this setup phase entirely. As a result, CI pipelines spend their time executing tests rather than waiting for infrastructure to be ready, leading to substantially shorter runtimes.
VMblog: Looking ahead, how do you see real-environment CI influencing the future of CI/CD practices and Kubernetes testing at scale?
Hassan: As CI workloads continue to scale, especially with AI-assisted and AI-generated code, traditional CI models will increasingly struggle to keep up. The volume of changes, the level of parallelism, and the speed expectations are all rising, while the cost and complexity of maintaining isolated test environments grow faster than teams can reasonably manage.
Real-environment CI shifts the model from duplicating environments to safely sharing them. Instead of treating realistic environments as scarce, sequential resources, it enables them to be used concurrently and safely at infinite scale. This makes higher-fidelity testing practical even as the number of CI runs increases dramatically.
Looking ahead, this approach is likely to become foundational for Kubernetes testing. As AI systems generate more code paths and more frequent changes, teams will need CI pipelines that validate behavior against real infrastructure by default-not as a late-stage gate. mirrord for CI enables that shift.
##
