A long-lived CI agent quietly keeps five kinds of state: installed tools, dependency caches, stored credentials, workspace leftovers and local logs. Ephemeral runners discard all of them every job. Some of that loss is a security win. Some of it breaks builds or audit evidence unless you replace it deliberately.
Why this matters before you migrate
Teams moving from a monolithic CI server to container-based jobs often discover that the old setup worked because of things nobody wrote down. A tool installed by hand in 2021. A cache that made a ten minute build feel like two. A credential file in a home directory. When the new job starts from a blank image, each of those becomes a failure or, worse, a quiet workaround such as baking a secret into the image.
The inventory
| State on the old agent | What happens on an ephemeral runner | What to do |
|---|---|---|
| Installed compilers and CLIs | Gone unless in the image | Put them in a versioned runner image |
| Dependency and layer caches | Gone unless restored from shared storage | Use a keyed cache with controlled write access |
| Credentials in home directories or config files | Gone, which is the point | Inject short-lived credentials per job |
| Workspace files from earlier builds | Gone | Pass only declared artifacts between jobs |
| Local logs and build history | Gone with the runner | Ship logs to external storage |
| Background services and cron jobs | Gone | Move to scheduled pipelines or a managed service |
How to find it
Walk one busy agent as if you were a new hire. List installed packages, check the home directory of the CI user for dotfiles, look at environment files and the credential store, and read the cron table. Then compare two builds of the same commit, one on the old agent and one in a clean container. Every difference points to hidden state.
Pay special attention to credentials. GitLab's runner security guidance warns that on shared runners you should not run docker login as the runner user, because every credential kept in the runner host's configuration files is available to every job the runner executes. Any file like that on your current agents is a candidate for removal, not for copying into an image.
Decide keep, replace or drop
Sort each item into three groups. Keep means it moves into the image or pipeline definition. Replace means a safer mechanism takes over, such as per-job credentials or a shared cache with write limits. Drop means nobody can explain why it exists, so it stays behind until someone complains. Record the decision with an owner and a date.
Quick check
Is losing state always a problem?
No. Losing leftover credentials and workspace files is the main security benefit. The problems come from state that builds silently depend on, such as tools and caches.
Should I copy the old agent's home directory into the new image?
No. That copies stale credentials and configuration into something many jobs can read. Rebuild the image from a written definition instead.
Sources
Last reviewed: 19 October 2026.
