Ephemeral container CI reduces what an attacker can keep, since each job starts clean and ends in deletion. A monolithic server concentrates state, credentials and plugins in one place. Ephemeral CI shifts the work to image maintenance, caches and logging, so it is a trade, not a free upgrade.
The comparison
| Area | Monolithic CI server or long-lived agents | Ephemeral container jobs |
|---|---|---|
| State between jobs | Accumulates in workspace, home directories and caches | None unless you restore it deliberately |
| Persistence after compromise | A foothold can last until someone notices | Ends when the runner is deleted |
| Credentials | Often stored on the server or agent | Injected per job, ideally short lived |
| Patching | Patch the running machine | Rebuild the image |
| Blast radius | The whole server and everything it can reach | One job's access, if scoped well |
| Tool versions | Drift per agent | Same everywhere, from the image |
| Logs and history | Local, easy to find | Must be shipped out |
| Debugging | Log in and look | Reproduce or attach carefully |
| Operational effort | Run servers | Run an image pipeline and orchestrator |
| Failure mode | Slow decay | Sudden cold start or cache miss problems |
What improves
GitHub's guidance on ephemeral runners says they limit exposure of sensitive resources from previous jobs and reduce the risk of a compromised runner receiving new jobs. GitLab's security guidance makes the same point from the other side: non-ephemeral runners shared across projects mean a job from one repository with malicious code can compromise other repositories serviced by that runner.
What does not improve on its own
- Code in a job can still use every credential the job holds while it runs.
- Poisoned dependencies and caches still flow in.
- Over-broad permissions on the CI platform stay over-broad.
- Plugins and third party actions still execute with job privileges.
What gets harder
Logs must leave the runner before it disappears. Image supply chain becomes your responsibility: a bad base image reaches every job. Cache design needs care, because a cache is now the one shared thing and therefore a target. Debugging needs a plan.
A reasonable path
- Start with the pipelines that handle the most sensitive credentials, since they gain most from isolation.
- Make the image pipeline as strict as a production pipeline.
- Keep a monolith for jobs that cannot yet move, and isolate that server from the rest.
- Use the migration checklist before each cutover.
Quick check
Is ephemeral CI always more secure?
It removes persistence and shared state, which are real gains. A badly scoped ephemeral job can still leak whatever it holds, so scoping credentials remains essential.
Can I mix both?
Yes. Many teams run both during migration. Keep the long lived agents isolated and move the most sensitive jobs first.
Sources
Last reviewed: 19 October 2026.
