# Supported workloads (/docs/getting-started/availability)



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 [#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 [#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.

[Choose a runner](/docs/ci-runners) · [Troubleshoot a queued job](/docs/ci-runners/troubleshooting)