<p>Thanks for your conclusion, it fits in mine too. </p>

<p>In my situation, I have projects of different types like pure Java, .NET and some packaged in Docker. For the moment, the number of jobs to build is not consequent but I'm afraid about some jobs creation peak for specific project before a major release for example... </p>

<p>I only configured shared runner with tags (dotnet, java, docker,...) and the project specifies the correct tag in their .gitlab-ci.yml :</p>

<pre><code>job:
 tags:
  - java
</code></pre>

<p>If I detect/anticipate a peak of job creation, I can <a href="https://docs.gitlab.com/ee/ci/runners/README.html#locking-a-specific-runner-from-being-enabled-for-other-projects" rel="nofollow noreferrer">assign</a> temporary a runner to a project. Of course the peak detection and the lock/unlock can be automatized with <a href="https://docs.gitlab.com/ce/api/runners.html" rel="nofollow noreferrer">Runner API</a> but it's not my case for the moment.</p>

CC BY-SA 3.0
2018-01-26T16:50:32.010Z
2018-01-26T16:50:32.010Z
Nicolas Pepinster
<p>After some research i found out that shared runners are good for the projects that are very much the same, and specific runners are better for the projects that are not like any project. </p>

<p>Shared runners can eat all resources available in the end with its queue's which makes specific runners more interesting.</p>

<p>My choice now is more like a little bit of both, so shared for all small and likewise projects, and specific for the large new projects as the documentation recommends.</p>

<p>From <a href="https://docs.gitlab.com/ee/ci/runners/README.html" rel="nofollow noreferrer">Shared vs specific Runners</a>:</p>

<blockquote>
  <p>... The main differences between a shared and a specific Runner are:</p>
  
  <ul>
  <li><strong>Shared Runners</strong> are useful for jobs that have similar requirements, between multiple projects. Rather than having multiple
  Runners idling for many projects, you can have a single or a small
  number of Runners that handle multiple projects. This makes it easier
  to maintain and update them. Shared Runners process jobs using a <a href="https://docs.gitlab.com/ee/ci/runners/README.html#how-shared-runners-pick-jobs" rel="nofollow noreferrer">fair
  usage queue</a>. In contrast to specific Runners that use a FIFO
  queue, this prevents cases where projects create hundreds of jobs
  which can lead to eating all available shared Runners resources.</li>
  <li><strong>Specific Runners</strong> are useful for jobs that have special requirements or for projects with a specific demand. If a job has
  certain requirements, you can set up the specific Runner with this in
  mind, while not having to do this for all Runners. For example, if you
  want to deploy a certain project, you can setup a specific Runner to
  have the right credentials for this. The <a href="https://docs.gitlab.com/ee/ci/runners/README.html#using-tags" rel="nofollow noreferrer">usage of tags</a> may be
  useful in this case. Specific Runners process jobs using a <a href="https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)" rel="nofollow noreferrer">FIFO</a>
  queue.</li>
  </ul>
  
  <p>A Runner that is specific only runs for the specified project(s). A
  shared Runner can run jobs for every project that has enabled the
  option <strong>Allow shared Runners</strong> under <strong>Settings ➔ CI/CD</strong>.</p>
  
  <p>Projects with high demand of CI activity can also benefit from using
  specific Runners. By having dedicated Runners you are guaranteed that
  the Runner is not being held up by another project's jobs.</p>
  
  <p>You can set up a specific Runner to be used by multiple projects. The
  difference with a shared Runner is that you have to enable each
  project explicitly for the Runner to be able to run its jobs.</p>
  
  <p>Specific Runners do not get shared with forked projects automatically.
  A fork does copy the CI settings (jobs, allow shared, etc) of the
  cloned repository.</p>
</blockquote>

<p>Still i would like to know everyone's mindset about this, as im still interested about your way of doing it!</p>

CC BY-SA 3.0
2017-10-10T13:48:22.937Z
2017-10-10T13:56:27.410Z
2017-10-10T13:56:27.410Z
SurudoiRyu
<p><strong>What do we have:</strong><br>
We have a Gitlab EE with multiple projects running on a droplet, next to that we have a runner server for the CI runners. All projects are Docker projects and 4 runners can be busy at the same time.</p>

<p><strong>What we need to know:</strong><br>
Now is my question, is it better to have like 4 runners on the runner server for all the projects OR is it better to have 1 runner per project?</p>

<p>I know when the CI gets stuck, the runner will be stuck too and it will mean that it is missing 1 runner till it gets reset. So at that point single runner per projects seems better, but it will make a large list of runners which perhaps use some idling resources from the server ?  </p>

<p><em>See here nothing is running or doing work:</em>
<a href="https://i.sstatic.net/psRCa.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/psRCa.png" alt="enter image description here"></a></p>

<p>Anybody can tell me what is better in your opinion and why it is better in your opinion as both ways seem legit in my opinion and i want to know others experience.</p>

<continuous-integration><gitlab><docker-in-docker>
Multiple runners for all projects OR single runner per project
SurudoiRyu
# Multiple runners for all projects OR single runner per project

(Asked by: username_0 on 2017-10-10)

**What do we have:**  
We have a Gitlab EE with multiple projects running on a droplet, next to that we have a runner server for the CI runners. All projects are Docker projects and 4 runners can be busy at the same time.

**What we need to know:**  
Now is my question, is it better to have like 4 runners on the runner server for all the projects OR is it better to have 1 runner per project?

I know when the CI gets stuck, the runner will be stuck too and it will mean that it is missing 1 runner till it gets reset. So at that point single runner per projects seems better, but it will make a large list of runners which perhaps use some idling resources from the server ?

*See here nothing is running or doing work:*
[![enter image description here](https://i.sstatic.net/psRCa.png)](https://i.sstatic.net/psRCa.png)

Anybody can tell me what is better in your opinion and why it is better in your opinion as both ways seem legit in my opinion and i want to know others experience.

**Tags:** continuous-integration, gitlab, docker-in-docker


---

## 2 answers

### Answer by username_0 on 2017-10-10. Score: 4 | Accepted answer

After some research i found out that shared runners are good for the projects that are very much the same, and specific runners are better for the projects that are not like any project.

Shared runners can eat all resources available in the end with its queue's which makes specific runners more interesting.

My choice now is more like a little bit of both, so shared for all small and likewise projects, and specific for the large new projects as the documentation recommends.

From [Shared vs specific Runners](https://docs.gitlab.com/ee/ci/runners/README.html):

> ... The main differences between a shared and a specific Runner are:
>
> * **Shared Runners** are useful for jobs that have similar requirements, between multiple projects. Rather than having multiple
>   Runners idling for many projects, you can have a single or a small
>   number of Runners that handle multiple projects. This makes it easier
>   to maintain and update them. Shared Runners process jobs using a [fair
>   usage queue](https://docs.gitlab.com/ee/ci/runners/README.html#how-shared-runners-pick-jobs). In contrast to specific Runners that use a FIFO
>   queue, this prevents cases where projects create hundreds of jobs
>   which can lead to eating all available shared Runners resources.
> * **Specific Runners** are useful for jobs that have special requirements or for projects with a specific demand. If a job has
>   certain requirements, you can set up the specific Runner with this in
>   mind, while not having to do this for all Runners. For example, if you
>   want to deploy a certain project, you can setup a specific Runner to
>   have the right credentials for this. The [usage of tags](https://docs.gitlab.com/ee/ci/runners/README.html#using-tags) may be
>   useful in this case. Specific Runners process jobs using a [FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))
>   queue.
>
> A Runner that is specific only runs for the specified project(s). A
> shared Runner can run jobs for every project that has enabled the
> option **Allow shared Runners** under **Settings ➔ CI/CD**.
>
> Projects with high demand of CI activity can also benefit from using
> specific Runners. By having dedicated Runners you are guaranteed that
> the Runner is not being held up by another project's jobs.
>
> You can set up a specific Runner to be used by multiple projects. The
> difference with a shared Runner is that you have to enable each
> project explicitly for the Runner to be able to run its jobs.
>
> Specific Runners do not get shared with forked projects automatically.
> A fork does copy the CI settings (jobs, allow shared, etc) of the
> cloned repository.

Still i would like to know everyone's mindset about this, as im still interested about your way of doing it!


---

### Answer by username_1 on 2018-01-26. Score: 0

Thanks for your conclusion, it fits in mine too. 
In my situation, I have projects of different types like pure Java, .NET and some packaged in Docker. For the moment, the number of jobs to build is not consequent but I'm afraid about some jobs creation peak for specific project before a major release for example... 
I only configured shared runner with tags (dotnet, java, docker,...) and the project specifies the correct tag in their .gitlab-ci.yml :
job:
 tags:
  - java

If I detect/anticipate a peak of job creation, I can assign temporary a runner to a project. Of course the peak detection and the lock/unlock can be automatized with Runner API but it's not my case for the moment.


---

