Vectis 0.1.1

Vectis 0.1.1

A reliability release: runners start reliably in parallel, failed runners are retried, jobs that wait for approval run once approved, and an idle Mac costs the cloud far less.

Updating from 0.1.0 is automatic. Installed apps find this release within four hours, and the update waits for active work to finish.

Highlights

Parallel runners start reliably

With several automatic runners, two jobs could start virtual machines within milliseconds of each other. The second start failed because the first, still booting, was treated as an interrupted VM that needed inspection. The affected GitHub jobs then waited until GitHub cancelled them.

A booting VM is now tracked as Starting. Admission counts the CPU and memory of starting VMs, so concurrent starts cannot over-commit the Mac. A genuinely interrupted VM still blocks new VMs, and runner capacity now reports no free slots while one exists, so the cloud stops handing out runners that cannot start. The app shows these VMs as Starting.

Failed runners are retried

A runner that failed before GitHub gave it a job was never retried, so the job kept waiting. Vectis now retries it after a minute, within the existing limit of three attempts per job. Cancelled, unfinished and action-required attempts are still not retried.

Jobs that wait for approval now run

Jobs gated by an environment approval report the GitHub status waiting, and GitHub also uses requested and pending. Vectis rejected these, so such jobs were never picked up after approval. They are now stored as Waiting and get a runner as soon as GitHub queues them. A runner that finds its job still waiting ends as cancelled without booting a VM. A person's cancellation of an unchanged job stays final. The app shows these jobs as Waiting.

A much quieter idle Mac

One idle Mac used enough Convex database bandwidth to exhaust a free plan within a week. Heartbeats now write liveness and runner capacity to a separate table instead of rewriting the machine record, job scan times no longer rewrite repository bindings, and the app asks the cloud for a small change marker instead of the full job list, fetching the list only when something reads it. In our measurements an idle machine's database traffic dropped by more than 90 percent. Scheduling behavior is unchanged.

Diagnostics when a runner loses its guest

When the guest connection is lost or the runner process exits unsuccessfully, Vectis now collects evidence before stopping the VM and keeps it on the failed operation: the runner's last output or the SSH error, the host's network view of the VM and, if the guest still answers, uptime, memory, the kernel log tail and the runner log tail. The text is capped at 16 KiB and scrubbed of the runner configuration. The app shows it in the activity details, and the CLI and MCP include it in the operation result. Windows guests report only uptime and the runner log, which is untested.

Security updates

Dependencies undici and devalue moved past their patched versions, which closes the open Dependabot alerts.

Compatibility

The cloud backend is already deployed and stays compatible with 0.1.0 apps. A 0.1.0 app cannot decode a job list that contains a Waiting job, so update the app on every Mac to see those jobs. The app, CLI and service ship together.

Platform requirements and limitations

Unchanged from 0.1.0: Apple Silicon Mac with macOS 15 or later; Ubuntu 24.04 ARM64 and macOS 26 ARM64 guests are supported; Windows 11 ARM64 is experimental. All guests are ARM64, so workflows that require x86-64 binaries do not run unchanged.