Skip to content

Gotchas

The host only runs two VMs at once

This is the most important operational limit. The executor can wait gracefully, but it cannot create extra host capacity.

Resource overrides happen after create when an image is used

This is not a bug in the docs. It reflects the current Jeballto API behavior. If an image is present, resources are patched after creation and before the VM starts.

Password SSH is assumed

The executor uses an SSH_ASKPASS flow with the configured password. If your image moves to a different authentication model, the current executor will not use it automatically.

A clean GitLab job failure is different from a host failure

  • script returns non-zero: build failure
  • API timeout, network issue, SSH transport failure: system failure

That distinction affects retries and operator expectations.

File locks are part of normal behavior

If you see .lock files under JEBALLTO_STATE_ROOT, that alone is not a problem. They are part of stage serialization and image pull deduplication.

Cleanup is best-effort, but stale local state still matters

Even when the Jeballto Agent auto-deletes a VM because it was created as ephemeral, stale local state can still confuse later hook stages. Keep an eye on both sides: the VM list and the state root.