v0.3.2

Compatibility and security notes

• GitHub JavaScript actions run on GitHub's Node 24 engine. A real Vectis job verified that a legacy using: node20 action runs on Node 24, while actions/setup-node can still select Node 20 for workflow commands.
• Node 20.20.2 accepted a known-compromised eMudhra certificate chain in our TLS test. Node 20 workflow compatibility is not a guarantee of TLS protection; use a runtime with verified trust fixes for TLS-sensitive work.
• Updating the app/service does not rewrite existing prepared VM images. Refresh their runner and guest trust configuration separately. Existing full-Xcode macOS environments should be preserved until a replacement is validated.
• Experimental Windows guests require separately installed QEMU, qemu-img, swtpm, ARM64 UEFI firmware, and the required Windows and driver installation media. These release assets do not bundle the optional Windows runtime.

What's Changed

Other changes

• fix(convex): cap connected Macs per account and expire stale jobs by @kerdofficial in #120
• fix(security): reject compromised eMudhra chains and default macOS guests to 27 by @kerdofficial in #118
• test(server): gate the macOS sync delay instead of comparing wall clocks by @kerdofficial in #126
• chore(deps): update dependencies with security fixes by @kerdofficial in #124
• chore(release): v0.3.2 by @kerdofficial in #127
• test(server): settle the provision helper deterministically under short deadlines by @kerdofficial in #128
• fix(security): tighten account CSP and update tooling dependencies by @kerdofficial in #129
• fix(deps): remove unused CLI and AsyncAPI dependencies by @kerdofficial in #130

Full Changelog: v0.3.1...v0.3.2

Release on GitHub

Vectis 0.3.1

Vectis 0.3.1

Linux environments can be prepared again, and Vectis's own CI is steadier on a busy Mac.

Installed apps find this release within four hours, and the update waits for active work to finish.

Fixes

• Linux preparation no longer fails at the packages step. 0.3.0 could stop with step=packages exit=100 when first-boot services held the apt lock. Preparation now waits for apt and dpkg locks, runs apt non-interactively, and replays the failing step's last lines on the console instead of losing them behind the login prompt. If a 0.3.0 preparation stopped this way, start a new one after updating.
• Release package verification checks the compact MCP status.
• Slow service test suites get enough time when the CI host is running other VMs.

Compatibility

No cloud changes. Works with the 0.3.0 backend.

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.

Release on GitHub

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.

Release on GitHub

Vectis 0.2.0

Vectis 0.2.0

Read job logs, see why a repository is not ready, decide who can start runners on your Mac, and rerun, cancel or dispatch GitHub runs from every surface. Linux guests can run x86_64 tools through Rosetta, Windows guests are kept off your local network, and runners that hang or lose their job clean up after themselves.

Installed apps find this release within four hours, and the update waits for active work to finish. Read Before you update first: Linux environments need to be prepared again, and run control needs an updated GitHub App permission.

Before you update

• Prepare Linux environments again. Each Linux instance now gets its own SSH host key. Images prepared with 0.1.x report action_required until they are prepared again. To keep the environment ID, its vectis-<id> runner label and existing repository connections, remove the old environment and prepare the new image under the same ID. Removing an environment keeps its image files on disk.
• Approve the GitHub App's Actions write permission to use run control. Until then, rerun, cancel and dispatch report github_app_permission_required. Everything else works without it.
• Windows: rebuild QEMU with both Vectis patches. Windows guests now start only with a QEMU build that supports network isolation (native/qemu/patches/0002-isolate-vectis-user-network.patch). Existing Windows base images do not need reinstalling.

Highlights

Job logs on every surface

Read a GitHub job's log from the desktop, vectis job logs <job-id> --binding <id> [--follow], or the MCP tool vectis_job_logs. Logs are fetched on demand with a byte cursor, so following a running job only transfers new output. The desktop opens a log panel under each job with follow, wrap and copy.

Readiness checks with the next step

vectis repository readiness, the MCP tool vectis_readiness and the desktop's connect dialog check everything a repository needs, one item at a time: cloud connection, linked GitHub account, App installation, administrator access, fork approval policy, environment and connection. Each problem carries a code and the next step, and the desktop jumps to the place where you fix it. vectis doctor reports coded checks for the host runtime too. A new onboarding checklist on the Overview walks a fresh Mac from environment to first job.

Decide who can start runners on your Mac

Each repository connection now has an access policy: anyone who can run workflows, or only listed GitHub users, and automatic or manually approved capacity. Jobs from other actors never get a runner, and jobs that need approval wait in Needs you until you approve them. Because GitHub can hand a runner a different queued job than the one it was started for, a job-started hook inside the guest checks the assigned job against the policy before any step runs, and stops the runner if it does not match.

Rerun, cancel and dispatch

vectis run rerun-failed, vectis run cancel and vectis workflow dispatch, their MCP commands, and the job menu in the desktop control GitHub runs directly. Every request is idempotent: Vectis records it before contacting GitHub, never resends a request whose outcome is unknown, and reports such outcomes as unconfirmed instead of guessing.

x86_64 Linux tools through Rosetta

Opt in per Linux environment with vectis environment configure <id> --x64 rosetta. The guest then runs x86_64 binaries and docker run --platform linux/amd64 images through Apple's Rosetta, shared read-only into the guest. The runner stays ARM64 and keeps its labels, so workflows choose this explicitly.

Network egress for Windows guests

Windows guests are limited to the internet by default: connections to the Mac, its local network, loopback and link-local addresses are refused, while DNS and internet traffic work. Linux and macOS guests report their egress as not enforced on every surface, because Apple Virtualization's NAT cannot restrict it yet.

Runners clean up after themselves

• A runner requested for a job that no longer needs it is released after 10 minutes of inactivity, reported as runner_idle.
• An automatic runner request that a Mac never picks up expires after 2 minutes if the Mac went offline, or 10 minutes if it stayed online, so another connected Mac can take the job.
• When GitHub still holds a runner on a job that died, cleanup is retried automatically for up to 30 minutes instead of waiting for a manual reconcile.
• A request that lost its cloud lease can now be reconciled after its VM is confirmed stopped.
• A job the access policy refused ends as runner_assignment_rejected, not as a plain cancellation.

See what is happening

• Jobs show the runner's stage next to their GitHub status: preparing, registering, waiting for a job, cleaning up, released.
• The desktop sends a macOS notification when Vectis needs you or work fails, even while its window is hidden. Clicking it opens the activity. Turn it off in Settings.
• A failed GitHub job now shows an error toast, even when its runner finished cleanly.

Workflow migration

Migration rewrites only the runs-on values it moves, byte for byte, and keeps comments and formatting. The desktop shows which jobs move to Vectis, which stay, and why, instead of two plain file previews.

Security

• Account linking and host isolation were hardened: each Linux instance has its own SSH host key, private fork policies are checked before a runner is registered, and Windows guests run with network isolation.
• Credentials are redacted from logs, operation details and stored diagnostics, including Windows bootstrap diagnostics.
• @modelcontextprotocol/sdk and sharp were updated.

Fixes

• Exit evidence is kept when VM file cleanup fails, so an instance can still be reconciled.
• Windows bootstrap failures keep their diagnostics.
• Jobs that GitHub reports with runner 0 are recognized as unassigned again.
• Jobs inherit the guest's normal umask, so files they create are no longer private to the runner user.
• A removed environment's ID can be prepared again.
• Requesting a runner for a job GitHub does not know reports job_not_found.

Documentation

New guides cover limits and boundaries, readiness, access policies, job logs, run control, Rosetta, egress, idle drain and request expiry, and the agent skill describes all of them.

Compatibility

The cloud backend is deployed and stays compatible with 0.1.x apps. Run control, job logs and readiness need 0.2.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.

Release on GitHub

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.

Release on GitHub

Vectis 0.1.0

Vectis 0.1.0

The first release of Vectis: disposable GitHub Actions runners on your own Apple Silicon Mac.

Each job runs in a fresh ARM64 virtual machine on your Mac. Vectis registers a just-in-time runner for that job, then removes the VM and runner registration when the work is done.

Highlights

One job, one disposable VM

Every job starts in a fresh VM cloned from a prepared environment. The runner accepts one job, then Vectis removes the VM and runner registration so later jobs start clean.

Automatic runners are opt-in for each repository connection. Vectis watches for matching queued jobs and checks that work is still queued before allocating a VM. The default concurrency limit is five runners and can be configured from one to sixteen. Actual capacity depends on the CPU and memory assigned to environments; at most two macOS VMs run at once.

You can also start a runner manually. Vectis reports runner operation status separately from the GitHub job result, so completed cleanup is not mistaken for a passing workflow.

Prepare Ubuntu, macOS or Windows environments

Guided setup is available for:

• Ubuntu 24.04 ARM64: downloads and verifies a pinned Ubuntu image, then prepares Git, Docker, SSH and the official runner's required dependencies.
• macOS 26 ARM64: downloads and verifies Apple's restore image, installs it into a local guest bundle and guides you through guest setup and SSH verification.
• Windows 11 ARM64: installation is available as an experimental path using media you provide.

Choose CPU, memory, virtual disk size, image directory and VM storage location for each environment. Setup operations are durable and can resume after interruptions.

Connect GitHub and schedule work

Pair a Mac with your Vectis account through browser approval. Link and verify a GitHub account, install the Vectis GitHub App for the repository owner, then connect a repository to an environment. Each connection provides a runs-on label such as vectis-ubuntu.

Automatic scheduling starts disabled and can be enabled per connection. Vectis receives GitHub job events and can scan GitHub for missed queued or running jobs. If a successful run leaves its original job queued, Vectis makes a bounded number of additional attempts. Failed, cancelled or interrupted runs are not retried automatically.

Repository and account controls include:

• Connect and disconnect repository bindings.
• Inspect recent GitHub job states and refresh missing or stale job records.
• Verify organization repository administrator access before privileged operations.
• Require maintainer approval for outside contributors before admitting public-repository jobs.
• Leave fork approval and workflow review to GitHub maintainers.

Review ARM workflow migrations

Preview one workflow file or analyze workflows in a connected repository. Vectis proposes supported ARM64 label changes and reports jobs that need human review. It does not assume x64 jobs will work on ARM64.

After Vectis observes a successful job on the same repository binding and environment revision, it can open a regular pull request containing only changed workflow files. Review and merge it through GitHub as usual; Vectis never merges it. Dynamic expressions, complex matrices, reusable workflows and privileged event patterns may need manual review.

Control Vectis from the app, CLI or MCP

The native Mac app, vectis CLI and vectis-mcp server use the same typed command contract.

The app manages environments, repositories, runner operations, activities, diagnostics and settings. Its background service continues working when the window closes. The app also includes a signed and notarized installer, an update path that waits for active work to finish, and an option to install matching CLI and MCP launchers.

The CLI returns structured JSON, stable error codes and actionable next steps. MCP lets agents inspect capabilities, issue the same commands, read operation state and wait for results. The release also includes a Vectis agent skill and Claude Code plugin.

Control other Macs remotely

Connect multiple Macs to one account and use the app, CLI or MCP to control an authorized host. Browser approval verifies each controller; access expires after 90 days and can be revoked.

Hosts collect remote commands over an outbound connection, so they do not need an inbound port. Commands for an unavailable remote host do not fall back to running locally.

Recover safely after interruptions

The local service stores operations in SQLite and uses caller-provided keys to make command retries idempotent. Accepted, running, action-required and completed states remain distinct.

Setup downloads can resume. After a service or host interruption, Vectis reconciles VM state only after it has evidence that the process exited. It stops only processes it started and tracks, and cleanup removes the owned VM and runner registration.

Security boundaries

Build work runs on your Mac. The Vectis cloud coordinates account identity, GitHub access and remote commands; it does not run workflow code. VM disks and build files stay on the host, while GitHub receives logs, artifacts and caches that workflows upload.

Guest VMs receive no host folders, Docker socket, GitHub App private key or general host credentials. A guest receives only the single-use runner registration needed for its job. Each Mac maintains an outbound connection and does not expose an inbound service port.

Platform requirements and limitations

Environment	Status	Requirements and notes
Vectis host	Supported	Apple Silicon Mac with macOS 15 or later. Intel Macs are not supported.
Ubuntu 24.04 ARM64 guest	Supported	Guided setup. Project-specific runtimes and tools are installed by workflow steps or containers.
macOS 26 ARM64 guest	Supported	Complete guest setup locally. Install Apple's Command Line Tools or Xcode in the guest; Xcode is not installed automatically.
Windows 11 ARM64 guest	Experimental	Requires your own Windows and VirtIO media, a valid Windows license, and a separately installed QEMU build with the Vectis TPM patch, firmware and software TPM.

All Vectis guests are ARM64. Workflows that require x86-64 binaries or x64 runner labels do not run unchanged.

Release on GitHub