GitLab runners on your own Hetzner Cloud account

Two bills. Manage Runners charges your organization's plan: Basic is $5.99/month for unlimited runners, and Pro at $19.90/month adds schedules and autoscaling. Hetzner bills your Hetzner account directly for each runner's server, by the hour up to a monthly price; see Hetzner's pricing. A paused runner has no server, but Hetzner may still charge for its kept IP addresses. See our pricing.

GitLab's hosted runners use compute minutes (see GitLab's pricing), while Hetzner bills a server by the hour up to a monthly price, however many jobs it runs. Which is cheaper depends on how much CI you run and how many hours your runners are active; see the GitLab CI cost comparison. On your own server, Docker images and the local CI cache can be reused between jobs, subject to automatic cleanup, and are lost when the server is recreated. You also choose the server type, location and firewall rules.

It depends on how many minutes you use. Beyond what your plan's included compute minutes cover, GitLab.com bills $10.00 per 1,000 job minutes on the small Linux runner and up to $120.00 on 2xlarge. A Hetzner server costs the same however many jobs it runs. For example, at prices as of 19 October 2026, the cheapest server matching the small runner, CX33 in Germany/Finland, costs $10.59 a month including IPv4, plus $5.99 for the Basic plan. Always on, that is cheaper than hosted minutes from about 1,658 small-runner job minutes a month beyond those the quota covers; below that, hosted runners cost less. Compare your own usage with the calculator.

Yes, for GitLab runners on the Pro and Enterprise plans. Autoscaling adds burst runners, extra Hetzner servers, when few of a runner's job slots are free, and drains them when the load falls. It reacts within a few minutes, not seconds, and never stops the runner you set it up on. Hetzner bills each burst runner by the started hour, including time spent draining. See Autoscaling. To stop paying for idle hours, pause runners by hand or with a schedule (Pro and Enterprise plans).

As many as its concurrency, GitLab Runner's global concurrent setting. Choosing a server type in the dashboard sets it to twice the server's vCPU count; lower it for memory-hungry jobs. Changing it recreates the server. See Concurrency.

Pausing deletes the runner's Hetzner server and keeps its configuration and its IPv4 and IPv6 addresses. You can let running jobs finish first: the runner takes no new jobs, and the server is deleted once they are done, at the latest after an hour, so Hetzner bills it until then. After that, Hetzner stops billing for the server but may still charge for the kept IP addresses; see Hetzner's pricing. Resuming creates a fresh server with the same addresses.

Cancelling doesn't delete your runners' servers: they stay in your Hetzner project, and Hetzner keeps billing them. Burst runners added by autoscaling are the exception: once the plan ends, none are added, and existing ones start draining in the last 15 minutes of a paid hour and get up to one hour to finish running jobs before they are deleted. Enabled schedules keep pausing runners at their stop times, which deletes the server, but scheduled starts stop without an active plan. To keep a runner running on its own, delete its schedule before the plan ends; schedules can't be changed afterwards. To stop Hetzner's charges, delete the runners with the CLI or API, which deletes their servers and IP addresses.

Active runners keep running jobs: GitLab Runner on your server takes jobs from your GitLab, not from us. Until Manage Runners is back, the dashboard, CLI and MCP server are unavailable, schedules don't pause or resume runners, autoscaling adds and removes no burst runners, and the dashboard records no metrics. Metrics your runners send to your own OpenTelemetry endpoint keep going.

Yes. Manage Runners creates no firewalls, but the labels you give a runner become Hetzner server labels, so a firewall that applies to a label selector covers your runners. GitLab Runner only makes outgoing connections, so you can block all incoming traffic, apart from SSH if you log in. Outgoing, the server needs your GitLab, the Debian, Docker and GitLab Runner package repositories for setup and automatic updates, Manage Runners during setup and for metrics, your OpenTelemetry endpoint if you send metrics there, and whatever your jobs reach. See Labels and firewalls.

No. Only the SSH keys you select from your Hetzner project are added, for root, and password login is disabled. Manage Runners adds no keys of its own.

During setup, the server reports when it starts configuring and when GitLab Runner is registered, so the dashboard can show its state. After that it contacts Manage Runners only for metrics, if you turn them on: about once a minute its CPU, RAM, swap and disk usage and number of running jobs for the dashboard, or, if it only sends metrics to your own endpoint, the result of its last export. Your jobs, code, logs and CI/CD variables are never sent.

Every Hetzner Cloud server type that Hetzner has not deprecated and offers in at least one location, with x86 (Intel or AMD) or ARM CPUs. Hetzner's locations are Falkenstein, Nuremberg, Helsinki, Singapore, Ashburn and Hillsboro; not every type is offered everywhere, and the dashboard shows where each one is available and at what price.

Yes, with GitLab.com and self-managed GitLab. Create a runner in GitLab to get its runner authentication token (glrt-…) and enter your instance's URL. The instance must be reachable from the runner's IP addresses, which stay the same when you pause and resume, so you can allow them in your firewall. See GitLab setup.

Manage Runners is run by Detech Digital Co., Ltd. in Hanoi, Vietnam (legal notice). According to the privacy policy, your data is hosted by Hetzner Online GmbH in data centers in Germany, administrators in Vietnam may access it for support and service delivery under Standard Contractual Clauses, and Cloudflare protects and delivers the website. Payments go through Dodo Payments. Your CI jobs, code and logs stay between your GitLab and your server.