Skip to content

Jeballto Actions Runner

Run GitHub Actions jobs on fresh macOS VMs without keeping a static runner fleet alive.

The controller listens for queued jobs, provisions an ephemeral VM through the Jeballto Agent, launches an Actions runner inside that VM, and tears everything down when the job is done.

Why this exists

GitHub Actions works best when runners feel native to the platform, but macOS capacity is expensive and hard to isolate. This controller gives you:

  • disposable macOS VMs per job
  • native GitHub Actions execution inside the guest
  • poll mode for simple NAT-friendly deployments
  • webhook mode for lower latency and lower API usage

Documentation map

First success

Start with Getting Started, then run the first host through Quickstart.

Operate safely

Use Configuration and Concepts to understand modes, labels, and limits.

Debug production issues

Keep How It Works, Troubleshooting, and Gotchas close when investigating queue stalls or cleanup drift.

Requirements at a glance

  • Apple Silicon host
  • macOS 26.0+
  • running Jeballto Agent
  • GitHub repository or organization where runners will be registered
  • an image that already contains the GitHub Actions runner binaries

Mental model

queued GitHub workflow_job
  -> controller sees the job
  -> label selects a VM image and sizing profile
  -> controller provisions VM through Jeballto
  -> runner boots inside the VM
  -> GitHub assigns the job to that runner
  -> controller deletes the VM after completion

The controller supports three operating modes:

  • poll: query GitHub on an interval, no inbound webhook needed
  • webhook: react to workflow_job webhook events
  • both: run both mechanisms and deduplicate by state