Kubernetes Testing: The Complete Guide
How to use Kubernetes as your test platform: why it beats CI runners on cost, security and scale, the tools that run tests in a cluster, and how to give every change its own test environment.
Kubernetes testing means using Kubernetes as the platform your tests run on: test runners as pods, test environments as workloads in a cluster, and the services under test running right next to them. It is how teams move integration, end-to-end and performance tests off CI runners and onto infrastructure shaped like production. (The same words are sometimes used for validating a cluster itself, with conformance suites and upgrade rehearsals. That is a platform team’s job and outside this guide.)
The reason to do it is that CI runners were built to compile code and run unit tests, not to test distributed systems. A GitHub-hosted runner sits outside your network, holds one job’s worth of compute, and sees none of the services, databases and queues your change will meet in production. A Kubernetes cluster already runs all of those, schedules work elastically, and gives every pod the same DNS, network policies and service mesh as production.
Coding agents make the gap expensive. In CircleCI’s 2026 data, throughput rose 59 percent year over year while close to a third of merge attempts failed, and a 50-engineer team that used to open 100 to 150 pull requests daily may see 1,000 when agents open them. Each of those changes needs real tests on real infrastructure, many times over, and runner minutes and concurrency caps add up fast.
This guide covers why Kubernetes makes good test infrastructure, how it compares with running tests on GitHub Actions, CircleCI or Jenkins runners on cost, security and scale, the Kubernetes testing ecosystem, which tests belong on a cluster, why Kubernetes is the natural place to test microservices, how to run integration and end-to-end tests there from CI, and what coding agents change. What makes microservices hard to test in the first place, from synchronous and asynchronous flows to workflow engines, is the subject of the complete guide to microservices testing. For a vendor-by-vendor list, see the Kubernetes testing tools comparison.
What is Kubernetes testing?
Kubernetes testing is the practice of running software tests on a Kubernetes cluster instead of, or alongside, CI runners and developer machines. Three things move onto the cluster:
- The test runners. CI jobs run as pods, started for a job and removed after it, through tools such as Actions Runner Controller, the Jenkins Kubernetes plugin or the GitLab Kubernetes executor.
- The test environments. The services a change is tested against run as workloads in the cluster, either copied for each change or shared with only the changed parts isolated.
- The tests themselves. Suites run as Kubernetes jobs next to the services they exercise, started by a test orchestrator such as Testkube, a pipeline engine such as Tekton or Argo Workflows, or a plain Kubernetes Job.
What it is for:
- Reaching private services, databases and queues from tests without exposing them to the internet.
- Running integration, end-to-end and load tests in the same runtime as production: same images, manifests, DNS, mesh and policies.
- Scaling test capacity with demand instead of buying a bigger runner plan.
- Giving every pull request and every coding agent its own test environment in parallel.
What it is not for: unit tests and builds, which run fine and cheaply on any CI runner, and production monitoring, which no pre-production test replaces. People also ask how to test Kubernetes or search for k8s testing, testing in Kubernetes and Kubernetes automated testing. When they mean their applications, this is the practice they are after.
Why Kubernetes makes good test infrastructure
Kubernetes was built to run many short-lived, isolated workloads on shared machines, which is a description of a test fleet. Five properties do the work.
Elastic capacity. The scheduler packs test pods onto nodes by their resource requests, and a cluster autoscaler or Karpenter adds nodes when the queue grows and removes them when it drains. A burst of a hundred pull requests becomes a burst of a hundred pods, not a hundred jobs waiting for a runner slot.
The same runtime as production. A test pod runs the same container images, receives configuration through the same manifests, and resolves services through the same cluster DNS as production workloads. Failures that come from configuration, resource limits, sidecars or network policy show up in the test, not after the deploy.
Network locality. Tests run inside your network, next to the services they call. A private database, an internal API or a message broker is reachable without a public endpoint, a VPN or a tunnel from a hosted runner, and secrets never leave your environment.
Isolation primitives. Namespaces, RBAC, network policies, resource quotas and dedicated node pools let you fence test workloads off from each other and from anything they should not touch. A pod per job means nothing persists from one run to the next.
An ecosystem that speaks the same language. Runners, pipelines, test orchestrators, load generators and environment platforms all install as Kubernetes resources and controllers. Test infrastructure is declared in Git and deployed like everything else, instead of living in a CI vendor’s settings page.
None of this is free. A cluster has to be operated, test workloads compete with anything else on it unless they get their own nodes, and a misconfigured runner can expose more than a hosted one would. The comparison below is about where that trade pays off.
Kubernetes vs CI runners: where should tests run?
CI systems such as GitHub Actions, CircleCI and Jenkins decide when tests run. Where they run is a separate choice, and there are three common answers. The table compares them as of October 2026.
| Where tests run | What the tests can reach | Cost model | Scale | What you operate | Best fit |
|---|---|---|---|---|---|
| Hosted CI runners: GitHub-hosted runners, CircleCI cloud executors | The public internet and whatever the job starts itself, usually mocks or Docker Compose | Per runner minute, by machine size | Capped by the plan's concurrent job limit | Nothing | Builds, unit tests, linting, contract tests |
| Self-hosted runners on Kubernetes: Actions Runner Controller, the Jenkins Kubernetes plugin, the GitLab Kubernetes executor, CircleCI container runner | Your private network, as far as network policy allows | Your nodes, no per-minute fee from GitHub | As far as the cluster autoscales | The cluster and the runner controller | Any CI job that needs private access, more compute or lower cost at volume |
| Tests as Kubernetes workloads next to the services: Testkube, Tekton, Argo Workflows, the k6 Operator, plain Kubernetes Jobs | The services under test, through the same DNS, mesh and policies as production | Your nodes | As far as the cluster autoscales, many suites in parallel | The cluster, plus the orchestrator | Integration, end-to-end and load tests against real dependencies |
The second and third rows are often combined: CI still triggers the run and reports the result, a runner pod in the cluster starts it, and the suites run as jobs next to the services they test.
Cost
Hosted runners bill by the minute. GitHub’s published rates are $0.006 a minute for a 2-core Linux runner, $0.012 for 4 cores and $0.022 for 8 cores. A thousand 20-minute integration runs a day on 4-core runners is 20,000 minutes, about $240 a day or $7,200 a month, before retries.
Self-hosted runners are free to use with GitHub Actions, so the cost becomes the nodes underneath. A 32-vCPU node such as an m6a.8xlarge runs about $1.38 an hour on demand, per AWS’s price list, which works out to roughly a quarter of the hosted rate per 4-core minute if the node stays busy. Spot instances and scale-to-zero node pools push it lower. Idle nodes, oversized resource requests and the hours spent operating runners push it back up, so the saving is real at steady volume and thin for a team that runs a few hundred minutes a week.
The larger cost is usually not the runner. A test that needs its own copy of every service to run against costs far more than the minutes it runs for, which is where the environment model further down matters.
Security
A hosted runner has to reach your services somehow. Either they get a public endpoint for the test, or the job opens a tunnel into your network with credentials stored in the CI system. Running tests inside the cluster keeps traffic and secrets in your network.
Self-hosted runners bring their own risk. GitHub’s hardening guidance says they should almost never be used for public repositories, since any pull request can run code on them, and that they lack the clean-machine guarantee hosted runners have. On Kubernetes the mitigations are standard: ephemeral runners that take one job and are removed, a dedicated node pool for CI, network policies that allow test pods to reach only what they test, service accounts scoped to the namespaces a job needs, and no cluster-admin credentials in any runner.
Scale
Hosted runners are capped by plan. GitHub allows 20 concurrent jobs on standard hosted runners on the Free plan, 40 on Pro, 60 on Team and 500 on Enterprise. A burst beyond that waits in a queue. On Kubernetes, Actions Runner Controller starts a runner pod for each queued job and the autoscaler adds nodes, so the limit is the cluster’s capacity and your budget.
How realistic the test is
This is the difference that matters most and gets discussed least. A runner, hosted or self-hosted, only executes the test. What the test runs against decides whether a pass means anything. Most CI pipelines still start a few containers with Docker Compose or Testcontainers, or call mocks, because the runner has nowhere better to point. On Kubernetes the test can run against the real services, at their current versions, in the same environment they run in. The rest of this guide is mostly about making that practical for every change.
The Kubernetes testing ecosystem
The tools fall into six jobs. Most teams use one or two from each row they need.
- CI runners on Kubernetes. Actions Runner Controller is GitHub’s operator for self-hosted runners: it watches for queued jobs, starts a runner pod per job and removes it after. The Jenkins Kubernetes plugin starts an agent pod for each build, the GitLab Kubernetes executor creates a pod for each CI job, and CircleCI container runner runs CircleCI jobs on your Kubernetes cluster.
- Pipelines and workflows defined in the cluster. Tekton defines CI/CD pipelines as Kubernetes resources, and Argo Workflows orchestrates parallel jobs on Kubernetes as a graph of steps, CI and test runs among them.
- Test orchestration. Testkube runs existing Postman, k6, Playwright, pytest and other suites as workloads in the cluster, collects their results and reports on them. It runs against whatever environment you point it at and leaves creating that environment to another tool, which is where the next group comes in.
- Load generation. The k6 Operator spreads a k6 load test across many pods in the cluster from a single TestRun resource.
- Throwaway clusters. kind, k3d and minikube start a small cluster on a laptop or a CI runner, and the Testcontainers K3s module starts one from inside a test. They are the right tool for operators and controllers, and too small for a whole application.
- Environments per change. Namespaces, virtual clusters with vCluster, full-copy platforms, and selective isolation with Signadot, compared in detail below. This is the layer that decides what a test actually runs against, and the one most pipelines are missing.
The Kubernetes testing tools comparison covers the vendors in each group, with pricing and what each does and does not do.
Which tests belong on Kubernetes
Not every test should move. The rule of thumb: a test belongs on Kubernetes when it needs something only the cluster has, such as real services, private data stores, production configuration or more compute than a runner offers.
| Layer | What it checks | Where it should run | Why |
|---|---|---|---|
| Unit | Logic inside one service | CI runner, laptop, agent workspace | Needs nothing but the code, and finishes in seconds |
| Contract | That a provider still honors what its consumers expect | CI runner | Needs the contracts, not the services |
| Component and operator | One service or controller against real Kubernetes APIs | Throwaway cluster on a CI runner: kind, k3d | Needs an API server, not the rest of the system |
| Integration | The changed service against current versions of what it calls | Kubernetes, in an environment for the change | Needs the real services, data stores and network path |
| End-to-end | A user journey across many services | Kubernetes, in an environment for the change | Needs every service in the path, running and current |
| Performance and load | Latency, throughput and limits under load | Kubernetes, sized like production | Needs production-shaped capacity and the k6 Operator or similar to generate load |
The top three rows are cheap and parallel by nature, and moving them off hosted runners saves money only at large volume. The bottom three are where Kubernetes testing earns its keep. How many tests to write at each layer is a strategy question, covered by the testing pyramid for microservices.
Why Kubernetes is the natural place to test microservices
A microservices application already runs on Kubernetes in production, so the cluster is the one place where a change can meet the current versions of everything it calls. The question is how to give every change that chance without the changes getting in each other’s way.
Why one shared test cluster breaks under parallel pull requests
Most teams start with one shared pre-production cluster, usually called staging, where each change is deployed for its integration and end-to-end tests. It breaks in three ways once several teams, and now their agents, push changes at once.
Changes queue. A shared cluster holds one version of each service, so two pull requests that change the checkout service cannot both be tested there at the same time. One waits, and the wait grows with every team.
Results stop meaning anything. With several changes deployed together, a failing test could come from any of them. Engineers rerun until green and stop trusting red builds, which is how real failures reach production.
The environment drifts. Half-finished deployments, manual fixes and leftover test data pile up until the shared cluster matches neither production nor anything else.
Deploy calendars, a lock in a chat channel, feature flags and a second or third staging cluster each help for a while, and none scales with the number of parallel changes. The complete guide to staging environments covers why those fixes fail. The answer is to keep one pre-production cluster and stop deploying every change into it directly.
Kubernetes test environments compared
There are six common ways to give a change somewhere on Kubernetes to run its tests. They differ in what each test run gets, how fast it starts and what a hundred of them at once cost. The table compares them by approach, as of October 2026.
| Approach | What each test run gets | Dependencies | Start time | Cost with many parallel runs | Best fit |
|---|---|---|---|---|---|
| Local cluster: kind, minikube, k3d | A small cluster on a laptop or CI runner | Only what the test deploys, usually fakes for the rest | Minutes, growing with each service deployed | Free compute, but someone maintains every manifest and fake | Operators, controllers, single-service component tests |
| One shared staging cluster | A turn on one environment | Real and current, when nobody has broken them | Already running, but changes queue | Flat, paid for in waiting and reruns | A few teams, release rehearsal |
| Namespace per pull request | A copy of every service in its own namespace | Copies, seeded with test data | As long as the slowest service takes to start | Grows with services times open pull requests | A handful of services, low change volume |
| Virtual cluster per pull request: vCluster | Its own control plane, with workloads on the host's nodes | Copies, as with a namespace | Namespace start plus a control plane | Grows like a namespace copy | Changes to CRDs, operators or cluster configuration |
| Full copy per pull request: a cluster per change, or platforms such as Release and Bunnyshell | A complete, isolated copy of the application | Copies, often from snapshots | Longest of all | Highest, and paid even for services nobody is testing | Small applications that need total isolation |
| Selective isolation on a shared cluster: Signadot, and in narrower forms Okteto Divert and mirrord preview environments | Only the services the change touches, plugged into the shared environment | Real and current, shared, with a database or topic of its own when a change needs one | Seconds | Grows with the changed services only | Many services, many parallel pull requests and agent runs |
Local clusters are the right tool for Kubernetes-facing code. kind runs a cluster in Docker containers and its own docs say it was built mainly for testing Kubernetes itself, while minikube and k3d target local development. They stop working as a test environment once the application needs more services than a laptop or a runner can hold. The guide to lightweight Kubernetes environments compares them.
Namespaces and virtual clusters per pull request give real isolation, and Kubernetes namespaces were designed for exactly this kind of partitioning. Either way, every environment holds a complete copy of the application, so cost and start time scale with the system’s size times the number of open changes. Namespace vs cluster for test environments goes through the tradeoffs.
Full copies offer the simplest mental model and the highest bill. Brex found that 99.8 percent of what a duplicated environment cost was spent on services no one was testing, and moving off duplicated environments saves it about $2 million a year.
Selective isolation deploys only what a change touches and plugs it into the real, shared environment around it. Signadot is built on this model. Each change gets an ephemeral environment on the existing cluster: the changed workloads are deployed next to the stable versions, and a routing key carried in request headers, in OpenTelemetry baggage, decides which requests reach them. Requests with the change’s key go to its version of the service, and everything else goes to the shared one. Hundreds of these environments share one cluster without seeing each other’s work, and each starts in seconds, since the rest of the system is already running. Routing uses the service mesh already in the cluster, Istio natively, the Kubernetes Gateway API, or a lightweight sidecar with Linkerd or no mesh, and services need to pass the routing header along, something OpenTelemetry instrumentation handles out of the box for most languages. What a Kubernetes sandbox is covers how the routing works.
Data, queues and workflows on a shared cluster
Sharing a cluster raises the question of shared state. On Kubernetes the answers are cluster-native. Tests share a database with each run’s data kept apart, or a resource plugin creates a temporary database, schema or branch for a change that alters the schema and deletes it when the environment ends. Because a plugin step is just a script run in a pod, it can also create things outside the cluster, such as a managed queue, a storage bucket or a VM. Messages through a shared Kafka, RabbitMQ, Pub/Sub, SQS or NATS broker carry the routing key so only the right consumers process them, and Temporal workers share a task queue the same way. Why synchronous calls, asynchronous messages and durable workflows each make microservices hard to test is covered in the complete guide to microservices testing, and the isolation patterns in the ephemeral environments guide.
How to run integration and end-to-end tests on Kubernetes from CI
Put together, the pattern most teams converge on keeps the CI system as the trigger and the scoreboard, makes Kubernetes the place tests run, and gives each change its own environment to run them against. The tests are your own, run by whatever already runs them:
- A pull request opens. CI builds container images for whatever it touched, on hosted runners or runner pods.
- CI creates an isolated environment for the change on the shared cluster, holding the new images and sharing everything else.
- The integration and end-to-end suites start as jobs inside the cluster, aimed at that environment by its URL or routing key.
- Results, logs and artifacts flow back to the pull request.
- The environment is deleted on merge, on close, or after a time limit.
Kubernetes integration testing done this way catches the failures mocks hide: a field another team renamed, a timeout that only appears behind a sidecar, a consumer that rejects a new message shape. Kubernetes end-to-end testing drives a whole user journey through the frontend or API gateway, and the same environment serves API testing, front end testing on Kubernetes and acceptance testing by people while the suite runs. Three details decide whether the results can be trusted:
- Run the suite inside the cluster. A test pod resolves the same cluster DNS names and passes through the same network policies and mesh as the service, and does not depend on a tunnel from a runner staying up.
- Test against current versions. A long-lived integration namespace drifts. The environment should point at whatever is currently deployed for everything except the change.
- Keep changes apart. Two pull requests that deploy the same service into one environment overwrite each other, and both report on code that is not theirs. Shared state is also the usual root cause behind flaky suites, as how to fix flaky tests explains, and behind integration tests that pass while staging breaks.
Kubernetes performance testing follows the same pattern on a schedule rather than per change: the k6 Operator or a JMeter or Gatling job runs against a pre-production cluster sized like production, with a short latency check per pull request to catch the worst regressions early. Running the service under change on a laptop or in an agent’s workspace, connected to the same cluster, extends the pattern to before the push. Shift-left testing in Kubernetes covers that practice, and the local development guide weighs the tools.
What coding agents change about Kubernetes testing
Coding agents affect Kubernetes testing twice over: they raise the number of changes that need test infrastructure, and they use that infrastructure themselves.
The volume is already measurable. CircleCI’s 2026 data puts the year-over-year throughput gain at 59 percent, and the gain is lopsided: the top 5 percent of teams came close to doubling throughput, and the bottom quarter gained nothing. About three in ten merge attempts fail, and the median time to recover has climbed 13 percent to 72 minutes. The teams that absorb a 10x surge in pull requests are the ones whose test infrastructure scales with it. Fifty engineers opening two or three pull requests a day each produce 100 to 150, and pipelines were sized for that. With agents, the same team can see 1,000. On hosted runners that means a much larger minutes bill and a queue behind the plan’s concurrency cap. On Kubernetes it means more pods.
Agents also test differently. Claude Code, Cursor, Codex and Copilot work in a build, test, fix loop: write a change, run the tests, read the failure, try again, often ten times for one task. Unit tests run fine in the agent’s workspace. Integration and end-to-end suites, the ones that would catch a broken contract, need a cluster with the real services, on every iteration, in seconds, with no person in the loop to book a slot.
That moves Kubernetes testing ahead of review. If the agent can run the integration and end-to-end suites against real dependencies before it opens a pull request, the reviewer reads code that already works against the real system. If it cannot, the reviewer becomes the test environment, and review queues grow with every agent added.
Isolation matters more with agents than with people. Ten agents testing in one shared environment produce failures nobody can attribute, and batching their changes into one run means one bad change fails all ten. An environment per agent task keeps every failure attached to the change that caused it.
Cost and cleanup need guardrails. Environments for agent tasks should start in seconds, carry a time limit, and delete themselves, so a stalled agent does not leave services running for a week. Deploying only the changed services is what keeps a thousand runs a day affordable.
Agents reach these environments the same way developers do. Signadot’s CLI, its MCP server and its agent skills let an agent create an ephemeral environment, run tests in it and read the results without a person in between. Validating AI-generated code on Kubernetes walks through the whole agent workflow.
Kubernetes testing best practices checklist
- Do unit tests, contract tests and builds stay on CI runners, where they are cheapest?
- Do integration, end-to-end and load tests run on Kubernetes, inside your network, rather than against mocks on a runner?
- Do CI runners on Kubernetes take one job each and get removed, on a dedicated node pool?
- Are self-hosted runners kept away from public repositories?
- Do network policies and scoped service accounts limit what test pods can reach?
- Does runner and test capacity autoscale, including down to zero when idle?
- Does every pull request, and every agent task, get its own isolated environment on the cluster?
- Do those environments start in seconds and point at current versions of everything except the change?
- Do test suites run as jobs inside the cluster, in parallel, with results kept in one place?
- Does a failing test point at one change, never a batch of several?
- Do test environments carry a time limit and delete themselves when a change merges or stalls?
- Do performance tests run in an environment sized and configured like production?
Where to go next
If you are picking tools, the Kubernetes testing tools comparison sorts them into test automation and environment platforms.
If you want to understand what makes distributed systems hard to test in the first place, read the complete guide to microservices testing. If shared staging is your bottleneck, begin with the complete guide to staging environments.
If you want every pull request and coding agent to get its own Kubernetes test environment on the cluster you already run, with suites running in the cluster next to the services, see Kubernetes test environments with Signadot.
Related reading
- Best Microservices Testing Tools for Kubernetes in 2026
- Guide to Shift-left Test Approach in Kubernetes
- Kubernetes Namespace vs Cluster: Pros and Cons for Test Environments
- The Ultimate Guide to Lightweight Kubernetes Environments
- What Ephemeral Environments Cost, and How Teams Keep the Bill Under Control
- Integration tests pass with mocks but staging still breaks: how to catch it earlier
- How to Fix Flaky Tests
- 2026 CircleCI Report: The Agent Validation Gap Is Here
- How Brex Uses Signadot to Scale Developer Testing Across 100s of Engineers and Coding Agents
- The Complete Guide to Microservices Testing: From Unit Tests to Production
- Staging Environments: The Complete Guide
- Ephemeral Environments: The Complete Kubernetes Guide
- What Is a Kubernetes Sandbox?
- Local Development on Kubernetes: The Complete Guide
- Validating AI-Generated Code Against Real Kubernetes Dependencies
Frequently asked questions
What is Kubernetes testing?
Kubernetes testing means using Kubernetes as the platform your tests run on: test runners as pods, test environments as workloads in a cluster, and the services under test running next to them. It moves integration, end-to-end and performance tests off CI runners and into infrastructure shaped like production. The phrase is also used for validating a cluster itself, which is a separate job.
Should you run tests on Kubernetes or on CI runners like GitHub Actions?
Use both, for different tests. Hosted CI runners suit unit tests, linting and builds: they need nothing private and finish in minutes. Integration, end-to-end and load tests belong on Kubernetes, where they can reach private services and databases, scale with the cluster, and run against the same images and configuration as production. Most teams keep CI as the trigger and Kubernetes as the place tests run.
Is it cheaper to run CI tests on Kubernetes than on hosted runners?
Usually, at volume. GitHub charges $0.012 a minute for a 4-core hosted Linux runner, while self-hosted runners cost nothing from GitHub and you pay only for the nodes. On a well-packed Kubernetes node priced at AWS on-demand rates, the same compute costs about a quarter as much. The saving shrinks if nodes sit idle or your team spends much time operating the runners.
Is it safe to run CI jobs on self-hosted runners in a Kubernetes cluster?
For private repositories, with care. GitHub advises that self-hosted runners should almost never serve public repositories, because anyone can open a pull request that runs code on them. Use ephemeral runners that handle one job and are removed, a dedicated node pool, network policies that limit what test pods can reach, and service accounts with only the permissions the tests need.
What is Actions Runner Controller?
Actions Runner Controller, or ARC, is GitHub's Kubernetes operator for running self-hosted GitHub Actions runners in your own cluster. It watches for queued jobs, starts a runner pod for each one, and removes the pod when the job finishes, so runner capacity follows demand. It is the usual way to move Kubernetes testing workloads off GitHub-hosted runners without leaving GitHub Actions.
How do you run integration tests in Kubernetes?
Deploy the changed service into a cluster next to current versions of the services it calls, then run the suite as a pod in the same cluster so it resolves the same DNS names and passes through the same network policies and mesh. Give each change its own isolated environment, or two pull requests testing the same service at once will overwrite each other's deployments.
How do you run end-to-end tests on Kubernetes in CI?
Let CI trigger and Kubernetes run. The pipeline builds images for what the pull request touched, creates an isolated environment for it in the cluster, starts the Playwright, Cypress or API suite as a job inside the cluster, posts the outcome to the pull request and deletes the environment. The run is as fast as the environment is to create, so avoid copying every service.
Do you need a separate test cluster for every pull request?
No. A cluster or namespace per pull request copies every service, so cost and start time grow with the size of the system. Most teams run one shared pre-production cluster and give each pull request an isolated environment on it, holding only the services that changed and sharing the rest. A separate cluster is worth it only when the change is to the cluster itself.
How do coding agents test their changes on Kubernetes?
An agent such as Claude Code, Cursor, Codex or Copilot calls an environment platform's CLI or MCP server, such as Signadot's, to spin up an isolated environment holding only the services it changed, runs integration and end-to-end tests against the real services in the cluster, reads the failures and fixes the code. Each attempt in that loop needs an environment in seconds, without waiting for a shared one.
How do you stop AI-generated pull requests from overwhelming test infrastructure?
Run their tests on Kubernetes, where capacity scales with the cluster rather than a runner plan's concurrency cap, and give every agent task its own short-lived environment instead of a turn on a shared one. Failures then point at one change, environments delete themselves after a time limit, and cost grows with the services that changed rather than with the number of agents.