GitLab Runner: Automate with the CLI

Start GitLab-Runner, retrieve its credentials, and modify its configuration programmatically using the Stackhero CLI

👋 Welcome to the Stackhero documentation!

Stackhero offers you an easy-to-use GitLab Runner cloud solution, designed to efficiently run your GitLab CI/CD jobs. Here’s what you can benefit from:

  • Unlimited CI/CD minutes: there’s no per-minute billing, so your pipelines can run whenever you need them.
  • Concurrent jobs: run multiple jobs in parallel to speed up your entire pipeline.
  • The Docker executor with Docker-in-Docker support: simplify building and pushing your container images.
  • Compatible with GitLab.com as well as any self-managed GitLab instance.
  • A private, dedicated VM powered by fast NVMe/SSD disks for reliable, consistent builds.
  • Available in both 🇪🇺 Europe and 🇺🇸 USA regions.

Save time: connect your first GitLab Runner and start running pipelines in just a few minutes!

This guide demonstrates how to create a GitLab-Runner service, read its credentials, and update its configuration entirely via the command line, with no need to click through the dashboard. This approach is ideal for scripts, CI pipelines, and AI agents.

We will use the Stackhero CLI for all operations. If you have not already installed it, you can do so with:

curl -fsSL https://www.stackhero.io/install.sh | sh

The simplest way to get started is to log in via your browser. When you run the login command, the CLI opens a web page where you can approve access. No passwords or 2FA codes are entered into the CLI itself.

stackhero login

Once logged in, your credentials are stored locally and will be used automatically by subsequent CLI commands.

For fully automated environments such as scripts or CI pipelines, you may prefer a non-interactive access token. You can create one from your dashboard (Account > Access tokens), then export it as an environment variable. The CLI, as well as any script you run, will automatically detect it.

export STACKHERO_TOKEN="usr-xxxxxx:your-token"

Next, you will want to list the GitLab-Runner service stores available to your account. The CLI accepts the store name (gitlab-runner) directly, so there is no need to look up or copy any IDs.

# List GitLab-Runner service stores (add --organization if you manage more than one)
stackhero services-store-list --name="gitlab-runner"

You can use the store name gitlab-runner in subsequent commands, or select a specific svs-xxxxxx ID from the list if you prefer.

# List instance sizes for your service store (use the NAME column for --instance)
stackhero instances-store-list --service-store=gitlab-runner

# List available regions (names such as "europe")
stackhero regions-list

Below is an example script that creates a stack, adds your GitLab-Runner service to it, waits for it to start, retrieves its configuration (including generated credentials), and then applies a new configuration.

#!/bin/bash
set -e

export STACKHERO_TOKEN="usr-xxxxxx:your-token"

serviceStore="gitlab-runner"   # The GitLab-Runner service store name (see step 2)
instance="..."                # An instance size from step 3
region="europe"               # A region name from step 3

# Create a stack for your service (uses your default organisation; add --organization if needed)
stackId=$(stackhero --format=script stack-create \
  --name="My GitLab-Runner stack")
echo "Stack created: ${stackId}"

# Add GitLab-Runner to the stack (names are resolved automatically)
serviceId=$(stackhero --format=script service-add \
  --stack="My GitLab-Runner stack" \
  --service-store="${serviceStore}" \
  --instance="${instance}" \
  --region="${region}")
echo "Service added: gitlab-runner"

# Wait for the service to be fully operational (this may take a few minutes)
stackhero service-wait-for --service="gitlab-runner"

# Retrieve the service configuration, including generated credentials
stackhero service-configuration-get --service="gitlab-runner" --format=json

The service-configuration-get command returns the complete configuration for your service, including automatically generated passwords and connection details. The output is in JSON format, making it easy to use in scripts and automation.

stackhero service-configuration-get --service=svc-xxxxxx --format=json

You can review an example configuration schema and then apply your own settings. When you update the configuration, the service may restart to apply the changes.

# View the configuration schema and an example for your service
stackhero service-configuration-example --service=svc-xxxxxx

# Apply a custom configuration (the service restarts if necessary)
stackhero service-configuration-set \
  --service=svc-xxxxxx \
  --configuration='{ "...": "..." }'

# Wait for the new configuration to be applied
stackhero service-wait-for --service=svc-xxxxxx

That is it. You have now seen the full lifecycle: start a service, retrieve its credentials, and reconfigure it, all in a scriptable, automated manner. To explore further, refer to the full CLI documentation, which also covers the non-interactive STACKHERO_TOKEN authentication demonstrated here.