Docker, Docker Autoscaler and Kubernetes executors give each job a clean environment and a protected runner file system. The shell executor does neither, so jobs can reach the runner's token and other jobs' code and cache. No executor is a perfect boundary, because GitLab warns container breakout is possible through flaws or certain configurations.
What each executor does
GitLab's executor page describes them like this. Shell runs builds on the runner host itself. Docker runs each build in a container. Docker Autoscaler wraps the Docker executor and creates instances on demand. Kubernetes creates a pod per job. Instance gives a job full access to a host instance, and suits jobs that need devices or the operating system. SSH, VirtualBox and Parallels are in maintenance mode and get only critical security updates.
Comparison
| Executor | Clean build per job | Runner file system protected |
|---|---|---|
| Docker | Yes | Yes |
| Docker Autoscaler | Yes | Yes |
| Kubernetes | Yes | Yes |
| Instance | Depends on setup | No |
| Shell | No | No |
| SSH | No | Yes |
The footnote that matters most: when the file system is not protected, "jobs can access the entire system, including the runner's token and other jobs' cache and code."
What that means in practice
On a shell runner, one job can leave a file for the next. A job from a less trusted project could read the runner's authentication token. GitLab's runner configuration page adds that an exposed token lets an attacker clone the runner and submit fake jobs, and recommends rotating tokens or recreating the runner.
Containers help, but the limits are real. Docker-in-Docker needs privileged mode, and socket binding gives the job control of the host daemon. Those are covered in our Docker build comparison.
A short decision guide
- Is the code trusted and the runner single purpose? A shell runner can be acceptable, with the host treated as disposable.
- Do several teams or forks share the runner? Use Docker, Docker Autoscaler or Kubernetes, and prefer fresh instances per job.
- Do deploy jobs hold production credentials? Put them on a dedicated runner that only takes jobs from protected refs. See instance, group or project runners.
- Do you need persistent state between jobs? Be explicit about it, and keep secrets out of the persistent area.
- Rebuild the runner image or host on a schedule. See ephemeral versus persistent runners.
Common mistakes
The common mistake is picking the shell executor for speed and later adding more teams to the same host. Another is assuming a container boundary is complete, then running privileged jobs on the same host as deploy credentials. A third is leaving old runners registered after a migration. List your runners each quarter, retire unused ones, and note which executor and trust level each represents.
Safeguard's asset discovery can help you see which repositories exist before you decide where jobs should run. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is a Docker executor always safe for untrusted code?
No. It isolates better than shell, but GitLab states container breakout is possible through flaws or certain configurations.
Should I keep using SSH or VirtualBox executors?
They are in maintenance mode with critical security updates only, so plan a move.
Sources
- GitLab Runner docs: Executors, fetched 19 October 2026.
- GitLab Docs: Configuring runners, fetched 19 October 2026.
Last reviewed: 19 October 2026.
