Shared runners

Instead of dedicating specific runners to individual projects, SHIP-HATS team offers and manages a pool of runners to handle jobs from any project that is configured to use them.

Benefits of shared runners

• Created on-demand.
• Available for all SHIP-HATS users at no additional costs!
• No overheads for agencies as they do not need to maintain runners.

For more details, refer to Shared runners vs Agency-hosted runners.

Types of shared runners

Following shared runners are available:

• CStack runners
• Docker runners
• GitLab-hosted runners
• Windows runners

Types of Docker runners

To ensure efficient and fair usage of our shared CI/CD resources, we provide Docker runners in two architecture types:

• ARM64 Docker runners
• AMD64 Docker runners

Choose the appropriate architecture based on your workload requirements, and then select a runner size based on job complexity.

ARM64 Docker runners

- As part of our pilot initiative, this runner will be available from 19 June 2025.
- This docker runner is currently free to use, but may become billable in the future.
- Only one variant is available for ARM64 runners and that is ARM64 - Small.

AMD64 Docker runners

Following are the three variants for AMD64 runner:

• Small
• Medium
• Large

Choose the right Docker runners

Step 1: Start by choosing the right architecture

• Use ARM64 runner only if your workload targets ARM-based systems (e.g., AWS Graviton) or you’re using ARM-specific container images.
• Use AMD64 runners for all other jobs, choose AMD64 runners as they are suitable for most jobs.

Step 2: Choose the right size

• Only one variant is available for ARM64 runners and that is ARM64 - Small.

• If you are choosing, AMD64 runners: ✅ Start with the Small Docker runner - Ideal for jobs that usually complete under 10 minutes. Monitor the performance and if you experience delays, switch to a larger runner.

  ⏱️ Move to the Medium Docker runner if your job consistently exceeds 10 minutes or hits CPU/memory limits while using the Small docker runner. It’s better suited for moderately heavy workloads or jobs.

  🔧 Use the Large Docker runner if your job consistently exceeds 60 minutes or hits CPU/memory limits while using the Medium docker runner. Ideal for resource-intensive builds, end-to-end testing with high concurrency, or jobs that require significantly more CPU and memory.

- If no runner tag is configured, by default, CStack runners are used for your job.
- We also provide you a dashboard to monitor the performance of shared runners.
- Currently, you can view the performance of the shared Docker runners offered by SHIP-HATS.

GitLab-hosted shared runners

GitLab-hosted runners offer a secure, scalable environment to execute CI/CD jobs efficiently.

Key features

• Autoscaling: GitLab-hosted shared runners automatically scale using AWS EC2 instances located in the same region as your GitLab dedicated instance, ensuring low latency and better performance.

• Job isolation: Each CI job runs on a freshly provisioned virtual machine (VM), providing complete isolation and improved security.

• Sudo access: While using GitLab-hosted shared runners, the VMs offer passwordless sudo access, enabling jobs to execute privileged commands when needed.

• Docker-in-Docker Support: GitLab-hosted shared runners run in privileged mode to enable Docker-in-Docker, allowing jobs to build Docker images or run multiple containers inside the job environment.

Note that the virtual machine’s storage is shared with the operating system, pre-installed tools, and your project files.

GitLab-hosted runners on Linux

GitLab-hosted runners on Linux for GitLab Dedicated use the Docker Autoscaler executor. Each CI/CD job runs in a fully isolated, ephemeral virtual machine (VM), using the latest version of the Docker Engine.

To support diverse workloads and hardware environments, GitLab offers runners for the following architectures:

• Linux - ARM64
• Linux - x86-64

Based on the computing resources allocated to the GitLab-hosted runner, following are the variants available.

Windows runners

SHIP-HATS supports multiple Windows runner images for different Visual Studio (VS) versions. Commonly used images include VS 2017, VS 2019, and VS 2022. For details, refer to VS versions and image tags.

If your CI pipeline depends on a specific VS version, be sure to update your runner configuration accordingly. For details, refer to Libraries.

If you do not specify an image version, by default, GitLab Windows runner will use VS 2022.

If your project requires a different image than those listed, you may also use a custom image.

VS versions and image tags

Specify required image tag

1. Open the gitlab-ci.yml file in your project.

2. To use VS2019, add the following line in the image option:

   image: registry.sgts.gitlab-dedicated.com/wog/gvt/ship/ship-2/gitlab-windows-docker:vs2019

3. To use VS2017, add the following line in the image option: image: registry.sgts.gitlab-dedicated.com/wog/gvt/ship/ship-2/gitlab-windows-docker:vs2017

4. If you are using a version other than VS2022, ensure your project’s environment variables are corresponding to the VS image version you are using.

Libraries

Following section lists the paths to set the required libraries for your build.

Related topics

• SHIP-HATS Runner Insights
• Best practices