From One Staging Environment to Fifty: Scaling Infrastructure for Teams Using AI to Code

The Short Version

A team adopts an AI coding assistant expecting to ship faster. Code generation does get faster. What quietly does not scale with it is test infrastructure, specifically a single shared staging environment that was sized for the PR volume of a smaller, slower-moving team. Within a few weeks, the bottleneck that used to be "how fast can we write this" becomes "how long until staging is free," and the team is not meaningfully faster than before AI, just further along in the pipeline before it stalls.

Why This Sneaks Up on Teams

Nobody decides to keep a single shared staging environment after 10x-ing their PR throughput. It happens because the staging environment was never the thing anyone was actively managing. It was set up once, worked fine for years at a stable PR volume, and nobody had a reason to revisit it, because it was not the constraint.

AI coding assistants change the equation on one side only. A developer using an assistant can produce a working PR for a small feature or fix in a fraction of the time it used to take, and can iterate on review feedback just as quickly. Multiply that across even a handful of developers, and PR volume climbs well before anyone updates a capacity plan for the infrastructure receiving those PRs.

Why Headcount Is the Wrong Variable to Watch

Most capacity planning instincts key off team size, more engineers means more infrastructure, planned roughly proportionally. This instinct actively misleads teams adopting AI coding tools, since the variable that actually drives infrastructure demand, PR volume and concurrent review load, decouples from headcount once a meaningful share of the team is using an assistant that multiplies individual output.

A team that stayed at ten engineers but each now produces two to three times the PR volume they used to needs infrastructure sized for something closer to twenty five engineers' worth of PR volume, not ten. Anyone watching headcount as the trigger for a capacity review will miss this entirely, since headcount never changed. The actual signal to watch is PR arrival rate and review queue depth, tracked directly, not inferred from team size.

The Progression, Stage by Stage

It helps to walk through what actually happens as volume climbs, since the failure is not a single cliff, it is a series of small degradations that compound.

Stage one: occasional contention. A handful of times a week, two people want staging at once. Someone waits, or a deploy gets held. Mildly annoying, not a crisis.

Stage two: contention becomes routine. With AI-accelerated PR volume, "someone else has staging" stops being occasional and becomes the normal state during working hours. Developers start timing their pushes around when they expect staging to be free, which is itself lost productivity nobody is tracking as a metric.

Stage three: people route around the process. Developers start skipping staging verification for changes they're fairly confident about, just to avoid the wait. This is the most dangerous stage, since it looks like things are still working right up until a skipped verification lets a real bug through.

Stage four: it becomes visibly the bottleneck. Someone finally notices that the team's actual throughput, PRs merged per week, has not improved much despite AI tooling, and traces it back to time spent waiting on one shared environment.

Most teams intervene somewhere in stage two or three, which is later than ideal, since the workarounds from stage three (skipped verification, batched changes to reduce staging trips) tend to stick around even after the underlying infrastructure gets fixed.

What Actually Needs to Change

The fix is not a bigger staging environment. A bigger single instance still serializes access, just with a slightly higher ceiling before contention starts. The fix is removing the single-shared-instance model entirely.

Per-PR ephemeral environments. Every pull request gets its own full-stack environment automatically, so PR volume and staging contention stop being coupled at all. See Automated PR Environments for E2E Testing for the create-deploy-test-destroy mechanics.

A primary environment as the template, not the shared instance. The environment everyone used to deploy to directly becomes the blueprint that per-PR copies are spawned from, not something anyone deploys to for routine verification anymore. See One Staging Blueprint, Infinite Ephemeral Copies.

Cluster capacity sized to actual peak concurrency, not to the old team's habits. This is the part teams most often skip, assuming the existing cluster has headroom without checking.

$ bns environments list --project <PROJECT_ID> -o json | \
    python3 -c "import json,sys; d=json.load(sys.stdin); print(len([e for e in d if e.get('operationStatus')=='running']))"

Run this at a few different points across a normal week (mid-morning, end of sprint, right after a big feature lands) to get a real peak number instead of a guess. A cluster or autoscaler ceiling sized for the old team's typical two-or-three-concurrent-environment pattern will start rejecting or queuing deploys the first time real AI-accelerated volume hits it.

The Cost Question, Addressed Directly

A reasonable worry: doesn't running many more environments simultaneously cost meaningfully more than one shared staging instance. In raw compute terms, yes, proportionally to how many are actually running at once. Two things keep this from being as expensive as it sounds.

First, auto-destroy on merge means environments only exist for the duration of active review, not indefinitely, so the cost scales with concurrent in-review PRs, not with total PRs ever opened.

bns environments update-settings --id <PRIMARY_ENV_ID> --destroy-ephemeral-on-pr-close

Second, the actual comparison that matters is not "one environment's cost versus many," it's "many environments' cost versus the engineering time lost to contention." A team of ten paying even thirty minutes a week per developer in staging-wait time is losing far more in salary cost than the incremental compute of running isolated environments, especially once AI-accelerated PR volume makes that wait time worse, not better.

Node Pools and Cluster-Level Scaling

Beyond the environment-management layer, the underlying Kubernetes cluster itself needs headroom that scales with concurrent environment count, not with team headcount, since those two numbers now diverge once AI tooling is in the picture. Dedicating a node pool specifically to ephemeral PR workloads, separate from any production or long-lived infrastructure sharing the cluster, keeps a burst of concurrent PR environments from competing with anything else for capacity, and gives you a single, clean autoscaler target to size against your measured peak.

What "Fifty" Actually Represents

The number in this guide's title is deliberately illustrative rather than a literal target every team should aim for. What it represents is the shift from thinking about staging capacity as a fixed, singular thing to thinking about it as something that scales with actual concurrent demand, whatever that number turns out to be for a given team on a given day. A five-person team with heavy AI tool adoption might genuinely peak at fifteen or twenty concurrent environments during a busy sprint. A fifty-person team with lighter AI adoption might peak lower than that. The right number is whatever your own measured peak concurrency turns out to be, recalculated periodically as usage patterns shift, not a number borrowed from a guide's title.

Signs You Have Not Actually Fixed It Yet

A few things worth checking honestly after making these changes, since "we switched to per-PR environments" does not automatically mean the underlying problem is solved.

• Are developers still batching unrelated changes into fewer, larger PRs out of old habit? That workaround should stop being necessary, and if it persists, the team culture around it needs an explicit nudge, not just the infrastructure fix.
• Is cluster capacity actually keeping pace with growing PR volume over time, or was it sized once and left alone again?
• Is auto-destroy actually firing reliably, or are ephemeral environments quietly accumulating because a webhook integration broke silently a few weeks in?

A Realistic Timeline for This Migration

Teams often assume this kind of infrastructure change requires a multi-quarter project. In practice, once the decision is made, the sequencing is closer to weeks than quarters, provided it's tackled in the right order.

Week one: measure before changing anything. Get real numbers on current peak concurrent staging usage, average PR-to-merge time, and how much of that time is attributable to waiting versus active work. Without this baseline, there is no way to confirm the change actually helped later.

Week two: stand up the primary environment as a proper blueprint. Take whatever the current shared staging environment's configuration actually is (including any undocumented manual tweaks it has accumulated) and capture it as a tracked bunnyshell.yaml, so the primary environment genuinely reflects reality rather than a stale, idealized version of it.

Week three: enable ephemeral creation for a subset of the team or a subset of repositories first. A full-team cutover on day one is riskier than necessary. Rolling it out to one team or one repository first surfaces integration issues (a webhook misconfiguration, an unexpected resource limit) against a smaller blast radius.

Week four: expand to the full team, with the old shared staging environment kept read-only or removed from the routine workflow but not yet deleted. Keeping it around briefly as a fallback lowers the stakes of the cutover; removing it later once confidence is established is a much lower-risk decision than removing it on day one.

What Changes for Individual Developers

It's worth being explicit about the day-to-day experience change, since this is ultimately what determines whether the migration actually delivers the intended velocity improvement, not just an infrastructure diagram improvement.

Before: open a PR, wait for a slot on shared staging, hope nobody else's change breaks what you're testing, manually coordinate around known busy periods.

After: open a PR, get a URL within a couple of minutes, test against a genuinely isolated copy of the application, never coordinate with anyone else's schedule for this specific step. The coordination overhead that used to be implicit and constant (checking if staging is free, asking in a channel, timing pushes around known contention windows) simply stops being a category of thing anyone has to think about.

This is the actual payoff of the migration, not a lower cloud bill (which may or may not materialize depending on how well auto-destroy and stop scheduling are configured) but the removal of a recurring tax on every developer's day that most teams had stopped noticing because it had become normal.

A Note on Tooling Choice

This guide describes the migration in general terms deliberately, since the specific mechanics (defining a stack once, connecting a cluster, enabling ephemeral-on-PR settings) are what matters more than which specific platform implements them. Whether a team builds this with a managed platform or assembles it from CI scripts and raw Kubernetes tooling, the underlying scaling math and the migration sequencing described above apply the same way. See How to Set Up Preview Environments for Every Pull Request on Kubernetes for a direct comparison of both approaches if that decision hasn't been made yet.

Handling Pushback During the Transition

A predictable objection during rollout: "our shared staging environment has months of accumulated manual configuration nobody documented, we can't just replace it." This is a legitimate concern, and the right response is not to dismiss it but to address it directly as part of week two above: export the actual current state of the shared environment as the starting definition, not a clean-room rewrite of what it's supposed to look like. Any genuinely undocumented behavior surfaces during this export process, which is itself valuable, since undocumented environment behavior nobody can explain is a liability regardless of whether this migration happens at all.

A second common objection: "we don't have platform engineering capacity to manage this many environments." This is usually based on an assumption that more environments means proportionally more manual management, which is true for a DIY approach but is specifically what a managed platform's automatic lifecycle (create on PR, update on push, destroy on merge) is designed to remove as a manual burden in the first place.

Related Reading

For the exact mechanics of the per-PR environment automation this migration depends on, see Automated PR Environments for E2E Testing. For the underlying math explaining why contention gets worse faster than intuition suggests as PR volume climbs, see Staging Environment Capacity Math.

Checklist

• Per-PR ephemeral environments replace the single shared staging instance
• Cluster capacity is sized against measured peak concurrent environments, re-checked periodically as AI-driven PR volume grows
• A dedicated node pool absorbs ephemeral PR workload spikes without competing with other infrastructure
• Auto-destroy is confirmed working, not just configured once and assumed fine
• Old workaround habits (batching PRs to avoid staging contention) are actively discouraged now that the constraint is gone