Early access — The platform is open but still being completed; features and prices may change before general availability.

Runners

Every deployment runs on a runner you bring — registered from your machine, or created on your targets.

Deploys and destroys execute as GitLab pipelines, and pipelines need runners. The platform's position is deliberate: customers bring their own runners. Your infrastructure changes run on machines you control, with credentials that never leave your side of the fence.

Two ways to have one

  • Register an existing runner from any machine of yours: the project's runners page gives you the registration details; you run the GitLab runner wherever you like (a spare box, a container, your workstation) with the project's tag.
  • Create a managed runner through the platform, on your own targets: a VM on your Incus server or an EC2 machine in your AWS account shaped by you, or the GitLab runner chart in your Kubernetes cluster. Its registration token travels once, as a protected parameter — never in values or logs — and a destroyed runner's token is deleted rather than left behind. OpenStack projects register their own runner instead: Nova's user data is readable through the API, so there is no safe channel for the platform to hand a token to a machine it boots — a refusal, stated rather than worked around.

What happens without one

Nothing — and the platform says so rather than let a pipeline wait silently. A project with no runner cannot deploy: the Deploy button waits, and every pipeline submission refuses with "register a runner first". Your pipelines run only on runners you operate; the platform never runs them on its own.

Lifecycle

Runner activity is visible in the project dashboard; managed runners deploy and destroy exactly like components — automatically after your typed confirmation, with the same cascade guarantees.

© 2026 FMJConsulting. All rights reserved.