Limits and boundaries
The numeric limits, timeouts and retention windows Vectis applies today.
These values describe the current release. Settings you can change are marked as such.
Runners and capacity
| Limit | Value |
|---|---|
| Time a runner waits for and runs a job | 6 hours |
| Time allowed for installing the runner in the guest | 10 minutes |
| Idle runner drain when capacity is no longer needed | 5 minutes, including manual runners without a requested job |
| GitHub reports a listening runner offline or missing | 2 consecutive minutes |
| Continuous runner status read failures | 15 minutes before offline recovery |
| Automatic interrupted-runner cleanup | 24 hours, retry delays doubling from 1 minute to 30 minutes |
| Concurrent VMs | 5 by default, 1 to 16 with vectis machine configure --max-runners or Concurrent VMs in the app |
| CPU ceiling per VM | At most the host’s CPU cores; summed vCPUs may exceed host cores |
| Shared VM memory admission budget | 75% of host RAM by default; machine configure --memory-budget-mib accepts 2048 MiB to total host RAM |
| Startup memory estimate | Linux 2048 MiB; macOS and Windows 4096 MiB; capped by each VM’s ceiling |
| Host memory pressure | Warning or critical blocks new starts; unknown is reported and treated as normal |
| Concurrent macOS VMs | 2 (an Apple limit) |
An automatic runner also waits while an environment is being prepared, while the Mac is paused, or when unresolved instances leave insufficient capacity. A runner that has been accepted holds its slot and startup memory estimate before its VM starts. Each non-stopped VM commits the larger of its measured process RSS and startup estimate; failed measurements fall back to its configured ceiling. Probes are cached for five seconds. runnerCapacity.budget reports the effective memory budget, committed memory, host RAM, pressure and whether pressure is known. The budget gates admission; it does not reclaim memory or stop VMs that later grow beyond it.
Environments
The warm pool is opt-in: environment configure <id> --warm-pool <N> accepts 0 to 4, default 0. Idle pool VMs consume host RAM and disk space under the same admission budget and pressure gate as other VMs. Pool filling leaves one runner slot and a startup memory estimate free, so the actual size can be smaller than requested, including zero at a one-runner limit. Owned warm VMs yield to jobs and count as reclaimable capacity, while their memory stays visible in runnerCapacity.budget. They contain no runner registration, JIT configuration or job credentials. Idle VMs are recycled after 30 minutes and drained on pause, disable or service shutdown. See Runners and jobs.
| Environment | Default CPU | Default memory | Default disk |
|---|---|---|---|
| Ubuntu | 2 | 4096 MiB | 32 GiB |
| macOS | 2 | 4096 MiB | 64 GiB |
| Windows | 4 | 8192 MiB | 96 GiB |
Override them with --cpu, --memory-mib and --disk-gib. Minimum disk sizes are 16 GiB for Ubuntu, 40 GiB for macOS and 64 GiB for Windows. A VM’s configured memory ceiling can never exceed 75% of host memory. Ceilings remain fixed for a running VM, but unused memory is allocated lazily and summed ceilings may exceed host RAM. For a suitable host, consider Linux 8 vCPUs / 12288 MiB, Windows 8 / 16384 MiB, and macOS 6 / 12288 MiB; preparation defaults are unchanged. See Storage and resources.
Cloud and automation
| Limit | Value |
|---|---|
| Connected Macs per account | 100 |
| Active runner leases per Mac | 100 |
| Lifetime of a runner’s just-in-time configuration | 15 minutes |
| Automatic runner failures per job | 3 |
| Total automatic runner attempts per job | 10 |
| Wait after an action-required or missing operation | 10 minutes |
| Wait after a failed attempt | 60 seconds |
| Unclaimed automatic runner request, Mac offline | Expires after 2 minutes |
| Unclaimed automatic runner request, Mac online | Expires after 10 minutes |
| Scan for jobs Vectis missed | At most every 5 minutes per repository connection |
| Jobs listed per repository connection | The latest 100 |
| Lines returned by one service log read | At most 1000 |
| Runner diagnostics | At most 16 KiB |
| Pairing requests | Expire after 10 minutes |
| Controller grants | Expire after 90 days |
History and retention
On the Mac, finished activity history expires after 30 days. Beyond the newest 300 completions, entries older than 24 hours expire too. Unfinished work stays. See Troubleshooting.
In the cloud:
| Record | Kept |
|---|---|
| GitHub webhook deliveries | 30 days |
| Jobs, finished or not | 90 days since the last update |
| Operations | 90 days |
| Runner leases | 30 days |
| Controllers | 30 days after the grant expires |
| Expired pairing and GitHub link requests | 1 day after they expire |
| Workflow migration previews | 24 hours |
Operations and runner leases that have not finished are not removed. GitHub ends every job long before 90 days, so a job record that has not changed in that time is removed even if Vectis never saw it finish.
Hosts and guests
- The host is an Apple Silicon Mac running macOS 15 or later. Intel Macs are not supported.
- Guests are ARM64 only: Ubuntu 24.04, macOS 26 or 27, and Windows 11 ARM64. A macOS 27 guest needs a macOS 27 host.
- Windows support is experimental.