For general builds with similar needs, instance runners are efficient. For deploy jobs that need credentials, GitLab suggests project runners, which are available only to the projects you assign. Group runners sit in between and serve every project in one group. The more sensitive the job, the narrower the runner scope.
The three scopes
| Aspect | Instance | Group | Project |
|---|---|---|---|
| Available to | All groups and projects on the instance | All projects and subgroups in one group | Only assigned projects |
| Who creates it | Administrators | Group Owners | Project Maintainers |
| Job queue | Fair usage, favors projects with fewer running jobs | First in, first out | First in, first out |
GitLab's own guidance: use instance runners when many jobs have similar requirements, group runners when all projects in a group should share a set, and project runners for jobs with special requirements, such as a deploy job that needs credentials, or for projects with heavy CI activity that benefit from isolation.
Why scope matters for security
A runner executes whatever jobs it is given. If one runner serves many projects, then a job in a low-trust project runs on the same machine, or the same host, as a job in a high-trust one. Whether that is a problem depends on how the runner executes jobs and how clean each job's environment is. A narrow scope reduces who can land code on the machine that holds your deploy credentials.
Practical rules
- Put deploy jobs on project runners, limited to the project that deploys.
- Lock a project runner so it cannot be enabled elsewhere. GitLab says instance and group runners cannot be locked.
- Use runner authentication tokens, not the old registration tokens. GitLab says registration tokens were disabled in all instances in 17.0 and that the token workflow gives full traceability of runner ownership.
- Remove runners you no longer use. Deleting a runner in GitLab does not remove its configuration from the host, and the host keeps contacting GitLab until you unregister it.
- Watch for stale runners. GitLab marks runners with no contact for more than seven days as stale.
What runner scope does not fix
Scope limits who can use a runner. It does not isolate one job from the next on the same runner. For that you need an executor and setup that gives each job a clean environment, and protected variables so deploy credentials only reach protected branches and tags.
Quick check
Can I make an instance runner private to one project?
No, instance runners serve the whole instance. Register a project runner instead.
Who can register a project runner?
A Maintainer of the project, according to GitLab's documentation.
Safeguard can enforce policies and gates on the code that goes through these runners, and scan its dependencies. Try the free scan.
Sources
Last reviewed: 19 October 2026.
