Continuous integration runs code from branches, pull requests and third-party dependencies, at volume, with credentials attached. That combination deserves its own blast radius.
Why a separate account helps
- Build runners execute code that has not been reviewed yet.
- Dependency updates introduce new code continuously.
- Pipelines need credentials, and those credentials need narrow scope.
- Build workloads are spiky and should not compete with production capacity.
- Build costs are easier to understand when they are not mixed into production.
A workable topology
- A build account hosting runners, caches and the artifact registry.
- Separate deployment identities per target environment, each scoped narrowly.
- Production deployment gated by approval or a protected branch.
- Artifacts promoted between environments rather than rebuilt per environment.
- Ephemeral runners that are destroyed after each job.
Promoting the same artifact rather than rebuilding removes a class of “worked in staging” problems, because the bytes are identical.
Ephemeral runners are worth the setup
| Aspect | Persistent | Ephemeral |
|---|---|---|
| Contamination between jobs | Possible | Impossible |
| Start-up latency | Low | Higher; mitigate with caching |
| Cost when idle | Charged | None |
| Compromise persistence | Survives | Destroyed with the runner |
| Debugging a failed job | Easier | Needs deliberate log capture |
Keep build costs visible
Build spend grows quietly: more branches, more tests, larger caches. With the build account separate, the trend is legible in the invoice, and decisions about parallelism and retention can be made on evidence.
Summary
Give builds their own account, ephemeral runners, scoped per-environment deployment identities and a promotion model. The pipeline is powerful infrastructure; treat it that way.
