Manage Runners

Admin Documentation

Scan the summaries below. Open sections to see details. No backend internals—only what admins need.

1) Getting Started — prerequisites and 60‑second quick start

▾
  • Prerequisites: Admin access; GitLab token with runner registration; Hetzner API token; Hetzner billing enabled.
  • Quick start: Sign in, verify email, connect GitLab, connect Hetzner, create your first runner template.
  • Best practice: Use separate tokens per environment (staging, production).

2) Authentication & Accounts — login, password policy, email verification, sessions, 2FA

▾
  • Login: Username/email + password.
  • Password requirements: Minimum length, mixed character sets; reject common/compromised passwords.
  • Email verification: New accounts must confirm email before admin access.
  • Sessions: Auto‑expire after inactivity; admins can revoke any active session.
Two‑Factor Authentication (2FA)

Enable TOTP‑based 2FA (e.g., Authy, Google Authenticator). Store and rotate recovery codes safely. Orgs may enforce 2FA for all admins.

3) User Management — registration, RBAC roles, session revocation

▾
  • Registration: Self‑service or invite‑only (recommended for small teams).
  • RBAC: Assign least‑privilege roles; restrict access to tokens, integrations, and scaling policies.
  • Session management: View/revoke active sessions and invalidate all sessions on credential changes.

4) Integrations — connect GitLab and Hetzner with least‑privilege tokens

▾

GitLab

  • Use a token with runner registration; scope to required groups/projects.
  • Runners will be registered and tagged automatically per your templates.

Hetzner Cloud

  • Use a project token limited to compute, network, and volume operations.
  • Select preferred regions and private networks for placement.
  • Rotate provider tokens regularly; remove unused tokens.

5) Runner Management — runners, hardware, locations, concurrency

▾
  • Names, tags, and executor: Docker or Shell.
  • Hardware: vCPU, RAM, storage size/type; save templates for reuse.
  • Locations: Regions and networks; enable ephemeral runners for isolation.
  • Concurrency: Set per‑runner concurrency based on workload and cost.

6) Scheduling & Scaling — schedules, auto‑scaling policies, safety caps

▾
  • Schedules: Business hours, weekends, and holiday rules.
  • Auto‑scaling: Min/max and cooldowns; reacts to queue length and durations.
  • Safety: Caps to prevent spend spikes; review actions in the activity log.

7) Monitoring & Dashboards — status, utilization/cost metrics, alerts

▾
  • Status: Runner health, queue depth, job throughput.
  • Metrics: Utilization, success/failure, and cost indicators.
  • Alerts: Optional thresholds with email notifications.

8) Security Features — token hygiene, RBAC, secrets handling, transport security

▾
  • Tokens: Store minimally scoped tokens, rotate regularly, revoke on suspicion.
  • RBAC: Separate operator, auditor, and admin duties.
  • Secrets: Never echo tokens in logs/UI; keep credentials encrypted at rest.
  • Transport: Always use HTTPS; pin your domain in CI settings.

9) Troubleshooting — onboarding, scaling, connectivity issues

▾
  • Runner fails to register: Check GitLab token scopes and permissions.
  • Scaling not triggering: Verify min/max, cooldowns, queue depth, and provider quotas.
  • Jobs can’t reach runners: Confirm network rules, tags, and executor compatibility.

10) Reference — glossary, limits, responsive UI, validation

▾
  • Terminology: runner, executor, template, schedule, policy, tag, concurrency.
  • Limits: Org‑wide max runners, per‑runner concurrency, and sensible defaults.
  • Responsive UI: Desktop + mobile; light/dark mode supported.
  • Validation: Inline form validation with clear error states.

Need more help?

Check the FAQ or contact your organization admin for elevated tasks.

Open FAQ Back to Home