Supported workloads
Check compatibility before changing your runner labels.
Public self-service signup is open to anyone. The supported workloads are narrower than the signup policy:
| Capability | Current offering |
|---|---|
| Repository ownership | GitHub organizations |
| Repository visibility | Private |
| Operating system | Ubuntu 24.04 Linux |
| CPU architecture | AMD x64 |
| Runner sizes | 2, 4, 8 and 16 vCPU |
| Balanced memory | 4 GiB per vCPU |
| Memory optimized | 8 GiB per vCPU |
| GitHub Actions | Official Actions runner; existing compatible actions and services |
| Job isolation | One disposable EC2 VM per job |
| Payment | Prepaid top-ups; optional Build subscription |
| Automation | CLI, local stdio MCP and Management API |
Public repositories, fork pull requests, personal-account installations, ARM, Windows, macOS and GPU runners are not supported in the current launch. Do not point those workflows at BerryBox labels.
Capacity and starts
BerryBox scales runner capacity down to zero when idle. A new job may need a cold VM launch. Spot capacity is preferred; on-demand is a fallback at the same listed customer rate. Available capacity and account quotas can affect start time.
There is no unlimited-concurrency promise, guaranteed sub-five-second startup or uptime SLA. Your plan, runner settings, prepaid credit, runtime reservations and fleet capacity determine what can start.
Runner behavior
Machines and job disks are destroyed after the job. Keep artifacts and dependency caches in GitHub's supported storage; do not expect a previous job's local filesystem or Docker layers to be present.