Brex ran preview environments the way many fast-growing platform teams do. Any developer who wanted to test a change got a duplicated Kubernetes namespace running the entire application. At 800+ microservices, that model stopped working.
The environments were pushing the scaling limits of a single Kubernetes control plane, the compute bill for running hundreds of services per developer was enormous, and they broke often enough that teams stopped maintaining them and pushed their testing into staging instead.
Brex replaced that model with Signadot, which creates isolated sandboxes (lightweight ephemeral environments) inside a single shared cluster. Only the deltas of the one or two services a developer or a coding agent are working on get duplicated. Every other dependency is served by the shared cluster, with real data and real traffic patterns.
“Signadot for the preview environments use case fit what we were trying to do better than anything else. It was a more mature solution than the other stuff that we were looking at. And the return on the investment was obvious… just in infrastructure costs, it saves us about $2 million annually.” Phil Burrows · Head of Platform Engineering, Brex
Brex is the finance platform that startups and enterprises use to run corporate cards, expenses, bill pay, banking, and accounting in one system. Their product strategy is built around intelligent finance: AI that reads receipts, drafts expense reports, codes transactions to the general ledger, and enforces spend policy on its own, to the point where the majority of expenses on the platform are prepared with no human involvement at all.
Delivering that requires real engineering scale:
Brex is also at the forefront of agentic engineering inside its own organization, with autonomous coding agents and agent-driven workflows adopted deeply across the engineering team. Their engineering blog documents that work in posts like Building autonomous agents for technical tasks. Signadot is a big part of the infrastructure that supports it, giving engineers and agents alike realistic environments to validate their changes in.
Preview environments in Kubernetes namespaces were powerful when Brex first built them. Each one was a duplicated namespace that gave a developer an isolated copy of the application to test and experiment against. The model degraded as the service count climbed:
“The primary problem is just the cost of getting something wrong or breaking something in a preview environment was never high enough to prevent folks from leaving things broken. And so they were constantly in a state of disrepair.” Connor Braa · Software Engineering Manager, Brex
The downstream effect was that entire groups abandoned realistic testing. As Connor Braa, Software Engineering Manager at Brex, described it, “There was a group of teams building very important product features that just eschewed development against preview environments entirely, and instead focused on unit tests. After unit tests, it was tested on Staging, and were required to use feature flags way more heavily. It made the data quality and reliability problems with moving to staging way worse.”
When the first high-fidelity test of a change happens in staging, staging breaks more often, other teams get blocked, and delays compound across the org.
The reliability problems came with a bill attached.
“The other big problem is cost, having isolated environments for our internal software that’s hundreds of microservices solely for the purpose of testing gets insanely expensive. We’re talking about replicating 800+ services just so a developer can test changes on 1-2 services. That’s a great deal of compute and memory.” Connor Braa · Software Engineering Manager, Brex
There are hidden costs too. When a team does not feel like it is working at its best, that hurts retention, job satisfaction, and performance. Connor describes it as developers not feeling like they have the tools to ship the quality of software they want to ship. With engineering hires costing six figures, it is worth asking whether your team can afford to lose people because they are frustrated at not being able to ship.
Signadot changed what has to be duplicated. Instead of standing up a copy of the application per developer, a sandbox holds only the changed versions of the one or two services being worked on. Requests carrying a routing key are directed through those sandboxed services, and every other call is served by the stable version already running in the cluster.
Sandboxes spin up in seconds because there is almost nothing to start, and a time-to-live setting shuts them down automatically, so abandoned environments stop accumulating cost.
The switch did not require Brex to change how developers work, and that was part of the appeal. What it changed is where the first realistic test happens. Because a sandbox costs almost nothing to create and needs no upkeep, running integration tests alongside unit tests in the inner loop became the default rather than a luxury, and integration problems started surfacing before code review instead of after merge.
It also dissolved the maintenance problem that had killed the old preview environments. Staging is an environment with real consequences attached, so it stays healthy as a matter of course, and sandboxes inherit that health rather than depending on each team’s willingness to maintain a separate environment.
“Staging has always been a place where we have a bit higher standard. It needs to be working, and there are real business consequences when it breaks. Being able to run Signadot in Staging alleviates this pressure where no one wants to maintain a separate dev environment just for dev testing.” Connor Braa · Software Engineering Manager, Brex
Testing in staging also solved a problem that replicated environments never could: the data. Connor is direct about this. The data quality on staging and production is far higher than anything a replication environment offers, which makes testing there fundamentally more realistic.
Brex could have invested in making dev environment data realistic. But that would have required a huge cultural shift across every team to prioritize it, and in his words, changing everyone’s behavior is not a road a platform team wants to go down. With Signadot, realistic data is simply a property of the environment the sandboxes already live in.
Any engineering org larger than a few people tests code changes in two loops:
Brex wants as many bugs as possible caught on the inner loop. With Signadot, an individual developer or coding agent creates a sandbox and runs an accurate test of their service against every dependency it needs, on the shared cluster. Combined with unit tests, that pulls a large class of integration problems forward, ahead of the pull request rather than after it.
That matters more as agents write more of the code. An agent that can only run unit tests hands its work back to a person for real validation. An agent with its own sandbox can exercise the change against live dependencies and iterate until it passes, so what arrives at the pull request has already been checked.
With Signadot, only the services being tested are replicated. With duplicated environments, Brex was running 800+ services so that a developer could work on one or two of them.
Connor puts the waste in blunt terms: on the margin, 99.8% of a duplicated environment’s infrastructure cost went to services nobody was testing, a figure he notes sounds like an exaggeration but is not. Eliminating that waste is what produces the roughly $2 million in annual infrastructure savings, and it is why the return on investment was obvious to Brex’s platform engineering leadership from the start.
The cost savings changed the budget. The speed changed the day-to-day experience. Standing up a namespace-based preview environment meant deploying hundreds of services and waiting for all of them to become healthy. A sandbox deploys one.
“A typical deploy in our Signadot based tooling, end-to-end, is less than five minutes versus the 30-60 minute deploy times we would see with preview environments. Local sandboxes allow us to take that down to almost instantaneous testing.” John Salem · Senior Software Engineer, Brex
A preview in under five minutes keeps a developer in flow while the change is still fresh. For coding agents it matters even more, since a fast environment is the difference between validating every iteration and validating none of them.
For a platform team, the development org’s Customer Satisfaction (CSAT) score is the number that says whether the tooling actually works for the people using it. Brex measures CSAT on its internal platform tooling, and John Salem reports that the Signadot-based tooling scored 28 points higher than the older platform engineering tech it replaced.
Taken together with the cost and speed numbers, the platform team got something rare: an infrastructure change that saved money, sped developers up, and made them happier at the same time.
Moving preview environments to Signadot addressed the cost, reliability, and efficiency problems that had made Brex’s previous system unusable. Isolated sandboxes inside a shared staging cluster gave developers realistic testing without the overhead of maintaining hundreds of duplicated services, and without the risk of one person’s broken change blocking everyone else.
As coding agents become a bigger part of the workflow at Brex, the same isolation and speed that accelerated human developers now gives agents the infrastructure to validate their own changes autonomously. That is the piece that turns an agent from something that writes code into something that ships it.
To see how lightweight ephemeral environments can work for your team, sign up for free or book a demo.
Get the latest updates from Signadot
