Scaling

ImpVMRunnerPool supports three scaling modes driven by spec.scaling.mode.

Modes

Mode	Behavior
webhook	Scale from GitHub webhook demand signals
polling	Scale by polling GitHub API for queued jobs
hybrid	Use both signals, take the higher demand

hybrid is recommended for most deployments.

Configuration

spec:
  scaling:
    mode: hybrid
    minIdle: 2          # always-ready runners
    maxConcurrent: 10   # hard cap on simultaneous VMs
    scaleUpStep: 2      # max new VMs per reconcile cycle
    cooldownSeconds: 60 # wait after scale-down before scaling up again

Scheduling Math

1. Start at minIdle pre-registered runners.
2. Raise by queue depth (polling) or webhook demand signal — whichever is higher in hybrid.
3. Cap by maxConcurrent.
4. Add at most scaleUpStep VMs per reconcile.
5. After scale-down, wait cooldownSeconds before scaling up again.

Monitor

kubectl get impvmrunnerpool ci-pool -n default -o yaml
kubectl get impvm -n default -l imp.dev/pool=ci-pool

Required Secrets

Create a secret with a GitHub PAT or app token scoped to runner registration:

kubectl create secret generic github-runner-token -n default \
  --from-literal=token=<github-pat>

Capacity Visibility

GitHub shows runner capacity only after VMs register. minIdle controls how many are pre-registered and ready for immediate job pickup.