Vectis 0.3.0

Vectis 0.3.0

CI on Vectis is now steady and much faster. Runners recover from restarts and crashes on their own, lost GitHub webhooks are redelivered, the macOS two-VM limit is respected before a VM starts, and Windows jobs run in about a third of the time. New opt-in tools make startup nearly instant: derived environments with the runner preinstalled, a warm pool, per-repository cache volumes and GitHub runner scale sets.

Installed apps find this release within four hours, and the update waits for active work to finish. Nothing needs to be prepared again, but read Get the most out of it to pick up the speedups.

Get the most out of it

• Windows: provision a derived environment. vectis environment provision <new-id> --from <windows-id> --image-directory <dir> adds Git for Windows (bash, GNU tar), zstd, PowerShell 7, a Defender exclusion and quieter background services, with the runner preinstalled. It takes about a minute and leaves the original image untouched.
• Linux: prepare the environment again to use provisioning and cache volumes. Images prepared before 0.3.0 have no guest sudo and report provision_requires_guest_sudo or cache_volume_requires_guest_sudo. Fresh images also preinstall the runner.

Highlights

Runners that heal themselves

• After a service restart or crash, runners whose VM is confirmed stopped are reconciled and released automatically (runner_recovery_pending, then runner_interrupted).
• Every runner is released after five idle minutes, and a runner GitHub reports offline is stopped as runner_offline instead of holding a VM for hours.
• Transient GitHub errors are retried with backoff, honoring rate-limit headers, and are shown as GitHub degraded rather than a local failure. Side-effecting requests are never repeated.
• Only real failures count against a job's three attempts.

Scheduling that knows each environment

Each Mac reports free slots per environment, so the cloud waits for a free macOS slot instead of starting a VM that cannot run. Failed GitHub webhook deliveries are redelivered every two minutes, and webhooks with unexpected fields are accepted instead of rejected. The cloud connection no longer drops every five minutes.

A shared memory budget

VMs share one memory budget instead of reserving CPU one to one: vCPUs are overcommitted, memory uses each VM's measured footprint, and no new VM starts while the Mac is under memory pressure. Set the budget in Settings, with vectis machine configure, or through MCP.

Derived environments with the runner preinstalled

environment.provision builds a new environment from a ready one, optionally running a setup script, and preinstalls the pinned runner so jobs skip the download. Removing a parent waits until its children are gone.

Warm pool, cache volumes and scale sets

• Warm pool (opt-in per environment): booted, credential-free VMs that a runner takes over in well under a second.
• Cache volumes (opt-in per repository connection): a private block device per repository, forked per job. Changes are written back only for push, schedule and dispatch runs on the default branch of the same repository.
• Scale set capacity mode (preview, per repository connection): GitHub assigns jobs to this Mac's runner scale set and Vectis starts runners for the assigned level, with no workflow changes. Connections with a restricted access policy stay on demand mode.

See where the time goes

Every runner records phase timings (VM start, guest ready, registration, waiting for a job, job, cleanup), shown as a timeline in the desktop, in vectis activity get and through MCP. Status responses are bounded, with new operation and activity endpoints, and MCP status is compact.

Measured on a real Mac

• Windows job with a 679 MB pnpm store: about 3 minutes to 67 seconds; pnpm install 105 s to 28 s.
• Warm pool takeover: 0.0 s instead of a 9.6 s cold start.
• Three parallel macOS jobs ran two at a time with no failed attempt.

Compatibility

The cloud backend is deployed and stays compatible with 0.2.0 apps. Per-environment scheduling, scale sets, cache volumes and the other new features need 0.3.0 on the Mac. The app, CLI and service ship together.

Platform requirements and limitations

Apple Silicon Mac with macOS 15 or later. Ubuntu 24.04 ARM64 and macOS 26 ARM64 guests are supported; Windows 11 ARM64 is experimental. Guests are ARM64; Linux guests can run x86_64 tools through Rosetta when you opt in. Network egress is enforced only for Windows guests. Scale sets use GitHub's preview API.