Your CI runner isn't just compute.
It's where your source code, your secrets, your tokens, and your build artifacts all sit out in the open while a job runs. Now picture another company's job running on that same machine.
That's the whole problem with shared runners.
Shared Runners Are Shared Risk
Persistent runners hold onto state between jobs. Leftover files, cached credentials, environment variables from the last run, a cache someone could poison, a process that never exited. It all stays put.
On a shared runner, jobs from different orgs can land on the same box. A malicious or compromised job doesn't need a clever exploit. It just reads whatever is already sitting there.
Containers narrow the gap, but they share a kernel with everything else on the host. One escape and the wall is gone.
Our Answer: A Fresh VM for Every Job
Every job request spins up its own virtual machine. The job runs, and then the VM is destroyed.
It isn't a container sharing a host. It's a full VM with its own kernel and a hardware boundary around it. One job, one VM, one tenant. Nothing leaks between tenants because nothing is shared between them in the first place.
What Ephemeral Actually Buys You
A clean slate on every run. No leftover files, no cached credentials, no state from the last job, whether it was yours or somebody else's.
No cross-tenant reach. Two jobs from two orgs never share a machine, so there's no common surface to go after.
Secrets that actually disappear. When the VM is torn down, the checkout, the tokens, and the secrets all go with it.
Nothing for an attack to persist on. A compromised job has nowhere to hide and nothing to come back to, because the machine it ran on no longer exists.
But Isn't a New VM Every Time Slow?
It sounds like you'd eat a cold start on every run. You don't.
We keep a warm pool of VMs ready to go, so a job gets a clean, isolated machine quickly, without paying for a full boot each time. You're not trading speed for isolation here.
Himanshu Sharma