Manage GitLab Runners on Hetzner effortlessly
Your runners are servers in your own Hetzner Cloud account: you pay Hetzner directly for the servers, and a flat monthly fee for Manage Runners. Create, duplicate, pause and schedule them from one dashboard.
How it fits together
Manage Runners sets up and looks after GitLab runners in your Hetzner Cloud project. Your CI jobs run between your GitLab and your own server.
Your GitLab
GitLab.com or self-managed. Holds your code and pipelines and hands jobs to the runner.
Registers as a runner and fetches jobs
Server in your Hetzner project
Debian with Docker and GitLab Runner. Runs your CI jobs. Hetzner bills you for it directly.
Creates, pauses and resumes it with your Hetzner API token
Manage Runners
Dashboard, CLI and MCP server. Configures the server, schedules it and shows its status.
-
Your jobs never pass through us
GitLab Runner on your server fetches jobs from your GitLab and runs them there. Code, job logs and CI/CD variables stay between GitLab and your server.
-
Only what your Hetzner token allows
Manage Runners creates, pauses, resumes and deletes runner servers through the Hetzner Cloud API. It creates no firewalls, networks, volumes or SSH keys.
-
No SSH access for us
Only the SSH keys you select from your Hetzner project are installed. After setup, the server contacts Manage Runners only to report metrics, if you turn them on.
Designed for every team
Whether you're a solo developer or managing CI for hundreds of engineers, Manage Runners has you covered.
Create runners quickly
With a GitLab runner token and a Hetzner API token at hand, fill in one form and your runner is online in under 3 minutes. No manual SSH sessions, no complex configuration files.
Duplicate runners
Copy any of your runners with one click, keeping the same configuration and GitLab runner token. The copy gets its own server and is ready in under 3 minutes, so adding capacity takes no setup.
Cost-efficient scheduling
Set up intelligent schedules to start and stop runners based on business hours, saving you money on weekends and after-hours. Reduce costs by 80% without sacrificing performance. Available on the Pro and Enterprise plans.
Optimized for Hetzner
Fine-tuned for Hetzner Cloud's full lineup: CX, CPX, CAX, CCX — choose from Intel, AMD, or ARM CPUs in any size, across all supported locations. Pair with Hetzner Firewalls for security.
Updated by default
Runners automatically receive OS package updates and GitLab runner service updates. Rest easy knowing your infrastructure is always patched and running the latest stable version.
Static IP address
Every runner gets a persistent, fixed IP address. Even when paused and resumed, the same IP is retained — crucial for allowlisting in Hetzner firewalls or external CI target systems.
Manage runners from your AI assistant
Manage Runners is a remote MCP server. It works with Claude, Claude Code and other MCP clients that support Streamable HTTP and MCP authorization. Add it, sign in with your account and choose what your AI assistant may do. Nothing to install, no token to copy, available on every plan.
-
Ask about your runners
List runners, caches and metrics connections, read CPU, RAM and disk metrics and schedules, and compare Hetzner server types and prices.
-
Confirm before it costs money
With the permissions you grant, your assistant can pause, resume, duplicate, update and delete runners and, on the Pro and Enterprise plans, set schedules. Creating, resuming or duplicating a runner, or an update that replaces its server, shows the current net list price first and only happens after you confirm. Changing a shared cache or metrics connection lists the runners that get a new server, at unchanged prices, for you to confirm.
-
Secrets never pass through the AI
Changes that need new credentials (a GitLab runner token, a Hetzner API token, an S3 secret key or metrics header values) come with a short-lived dashboard link where you enter them yourself. A metrics connection without header values is created directly.
Connector URL
https://api.managerunners.com/mcpClaude Code
claude mcp add --transport http manage-runners https://api.managerunners.com/mcpIn Claude, add the URL as a custom connector. In other MCP clients, add it as a remote server (Streamable HTTP) and sign in when your client asks.
Sign in on the Manage Runners consent page. Read access is preselected; permissions that change runners or cost money stay off until you select them. Disconnect any time under Connected apps.
3 steps to your first runner
Starting from scratch? If you already have Hetzner Cloud and GitLab accounts, the quick start takes you from sign-up to your first CI job in about 15 minutes, including creating the two tokens. After that, every new runner takes under 3 minutes.
Connect GitLab & Hetzner
Create a runner token in GitLab and an API token in your Hetzner Cloud project, then add both. We validate permissions immediately so there are no surprises on first use.
Configure your runner
Pick a server type, location, and optional scheduling. Advanced users can configure firewalls, private networks, and SSH keys — all from the dashboard.
Start building
Your server is provisioned and registers itself with GitLab in under 3 minutes. Then your CI jobs pick it up and start executing. No manual steps required.
What changes with Manage Runners.
Most teams pay for runners around the clock — even when no jobs are running. Here's how we fix that.
SSH into VMs to configure each runner manually — slow, error‑prone, and unrepeatable.
Fill in one form in the dashboard and the runner is online in under 3 minutes.
Paying for idle servers 24/7 — no way to pause infrastructure when no jobs are running.
Schedules (Pro and Enterprise plans) shut runners down during off-hours, cutting bills by up to 80%.
IP addresses change on every restart, breaking firewall rules and allowlists.
Every runner keeps a fixed IP that persists across pause and resume cycles.
Manual OS updates and security patches — easy to forget, risky to skip.
Auto-updates keep packages and the GitLab runner service always patched automatically.
No centralised visibility into runner health, status, or utilisation.
Runner status, Hetzner costs and CPU, RAM and disk usage at a glance in one dashboard. Runners can also push their metrics via OpenTelemetry to your own monitoring, such as Grafana Cloud or OpenObserve.
Frequently Asked Questions
Cost: Hetzner’s CPX instances are
a fraction of the cost of managed CI runners. Fixed
monthly rate—no per-minute accumulation.
Performance: Dedicated VMs with
Docker executor and local caches reduce cold starts
and pull times.
Control: Full control over regions,
firewalls, and networks in your own Hetzner account.
It comes down to Fixed vs. Variable pricing. GitLab SaaS and major clouds (AWS/GCP) charge a premium for "on-demand" convenience, often costing $10 per 1,000 minutes. On Hetzner, you rent the entire server for a flat monthly fee (starting at ~$4/month). Since a month has roughly 43,000 minutes, your cost per minute drops from $0.01 to $0.0001. If you run more than 500 minutes of CI/CD per month, the savings cross the 80% threshold immediately. 80% is already an understatement.
If you pause a runner in our dashboard, we will delete the Hetzner server, but keep its IP address. So you won't be charged for the server, but you will still be charged for the IPv4 address.
You won't be able to login to your account, but your runners will continue to run until you delete the VMs in your Hetzner account. Since scheduling is done by Managerunners, they will be no longer automatically started and paused.
Yes, you can! You can block all inbound traffic if you like. Blocking outbound traffic is tricky, because you need to make sure that during runner initialization, the runner can reach the Managerunners API. As soon as your runner is ready, we will not contact the Managerunners API anymore. Also you need to make sure that apt can fetch packages from the internet, and your CI jobs can reach whatever they need to reach.
No. We will only provision the SSH keys from your Hetzner project that you select. No other keys will be deployed.
During initialization of your runner we will call a Managerunners API endpoint to signal the state of your runner, so that you can see the state in your dashboard. Once the runner is "Ready", it only contacts us for metrics, and only if you turn them on: its CPU, RAM and disk usage for the dashboard, or just whether its last export to your own endpoint succeeded. Your jobs, code and logs are never sent.
All mainstream cloud types (CX, CAX, CPX, CCX), meaning both x86 and ARM where available. Not all types are supported in all datacenters, but you can choose all supported locations for each type.
Yes, it works with GitLab.com and self‑managed GitLab. You'll create a runner registration token and off we go.
Ready to take control of your CI?
Join teams who have cut cloud bills and reduced manual ops with Manage Runners.