# Flexible runner profiles and capacity Approved direction: choose CPU, RAM and temporary disk independently. Service rollout is pending; existing runner labels and prices apply today. ## Approved, awaiting rollout Coming soon: flexible runner profiles are approved but not enabled in production. The CLI commands and technical reference are published. That publication does not confirm production API or portal activation. Published standard label names and preset prices are unchanged, including the existing 6-vCPU presets. Approved standard CI ceilings are Free/Developer 6 vCPU, Team 16 and Business 32, with Enterprise custom. Size enforcement is live for every workspace. There is no grace period or grandfathering for new job admission. [Use current runner labels](https://runzivo.dev/docs/runners/) ## Choose resources independently The approved model separates CPU, RAM and temporary disk instead of fixing their ratios. Offered combinations depend on compatible Runzivo execution-host capacity. - CPU options: 2, 4, 8, 16 and 32 vCPU. - RAM options: from 4 to 128 GiB, selected independently of CPU. - Temporary disk options: from 16 to 256 GiB, selected independently of CPU and RAM. This is job storage, separate from persistent sandbox disks. - Approved examples include 16 vCPU with 16 GiB RAM and 32 vCPU with 16 GiB RAM. Temporary disk is a separate choice. These are target combinations, not profiles available to run today. ## Save a reusable profile The approved Runner Templates and runner-selection flow will let you choose CPU, RAM and temporary disk separately, inspect the equivalent-minute rate, save a reusable custom profile and copy its workflow label. Standard labels remain in the catalogue, with their approved plan requirements, without creating a large catalogue of default combinations. The CLI's custom-profile commands and detailed guide are published on GitHub. Production service activation is not confirmed. Continue using current templates and labels until custom profiles are enabled. [Use current workflow templates](https://runzivo.dev/docs/runner-templates/) [Published custom-profile CLI reference on GitHub](https://github.com/Runzivo/rzv-cli/blob/main/docs/custom-runner-profiles.md) ## Read availability after rollout The approved selector will distinguish these states for a profile and region. The labels below describe the planned experience, not a live capacity report on this page. Supported choices stay visible while hosts are busy. Where a plan requirement applies, the selector will show CPU, RAM, required plan, estimated equivalent-minute rate and a direct upgrade action. Plan eligibility is separate from regional capacity. Standard CI and new custom profiles have separate approved ceilings: Free/Developer 6 vCPU for standard labels and 4 for custom profiles, Team 16 and Business 32 for both, with Enterprise custom. A new job on a locked size is refused with plan_required and names its required plan, including for an existing workspace or profile. Running jobs are preserved. No size-admission grace period or grandfathering applies. - Available now: compatible execution capacity is available for the selected resources. Capacity is checked again when admitting the job. - Busy, jobs will queue: the region supports the profile, but compatible hosts are temporarily occupied. The job waits fairly for capacity. - Not supported in this region: the region does not offer the selected resource combination. Choose another supported combination or region. ## Capacity and safe CPU overcommit The approved scheduler uses allocatable capacity and resource pressure after host operating-system headroom. Only registered, ready Runzivo execution hosts count toward offered capacity. CPU overcommit will be configurable per host or region. It changes the effective CPU admission budget, not the physical CPU count. The scheduler must use the overcommit-aware capacity reported by the host once, rather than multiplying an already adjusted figure again. Admission must guard against excessive CPU contention. RAM and disk need safe reservations and host headroom. CPU overcommit does not authorize memory exhaustion or disk overcommit. Resource pressure and compatible host capacity determine whether work starts or queues. ## Concurrency and fair queueing The approved model removes artificial plan-based concurrency restrictions. Compatible execution capacity and fair queueing determine admission. Busy hosts do not mean that a supported profile is unsupported in the region. This scheduling policy is awaiting service rollout. Size eligibility is enforced independently of the future scheduling model. No immediate start time, unlimited physical capacity or zero-queue guarantee is promised. [Read current usage and limits](https://runzivo.dev/docs/usage-limits/) ## Equivalent-minute billing Flexible profiles will use the existing unified equivalent-minute allowance and prepaid credit. The displayed rate will account for the selected CPU, RAM and temporary disk. Resource pricing will be published before flexible profiles become available and will agree across the portal, API, CLI and documentation. Published preset prices continue to apply to current labels. [Review current preset pricing](https://runzivo.dev/pricing/) ## Compatibility and rollout checks The service rollout must preserve existing GitHub workflows, provider integration paths and CLI/API actions. GitLab is not available for general customer use yet; this announcement does not change its availability. Before flexible profiles are offered, verification must cover saving a custom profile, copying its label, seeing a consistent equivalent-minute rate and running different CPU/RAM combinations. This includes 16 vCPU with 16 GiB RAM and 32 vCPU with 16 GiB RAM where supported. Queueing on busy compatible hosts, unsupported-region messages and existing labels must also be checked. On this page and page tools