Runners and concurrency

Use shared system runners

Composal provides globally registered Modal system runners that organizations can use. They are a shared platform pool, not a private pool reserved for the Composal organization. An available explicitly configured pool takes precedence; otherwise eligible runs use the platform default pool.

Runner availability and candidate concurrency are different limits. One candidate can create several workflow jobs, and raising its queue’s concurrency does not reserve that many system runners. Inspect job waiting and startup time before increasing parallel work.

Keep the runner environment explicit

Use runs-on in your workflow and install the tools your commands need. For self-hosted runners, keep the Composal CLI current: dependency cache restore at the cache step requires 1.17.16 or later, and long dependency archive paths require 1.17.17 or later. See Caching for upgrade and cold-cache behavior.

Set candidate concurrency

Open Merge queue → Queue policy to adjust CI candidate concurrency. Organization owners and administrators can choose 1–20 with the slider, then Save concurrency (or Save queue policy for a synced repository).

Start with 8 when changes are waiting and runners have spare capacity. This controls concurrent candidate validations; each workflow can create several jobs. Shared system runner capacity and workflow concurrency groups still apply.

Native queues save this setting for each target bookmark. Changing it preserves existing candidate CI and lets running work finish. More parallel candidates can shorten waits, but a failure or changed input earlier in the queue may cause followers to repeat CI. Compare waiting time, runner use, and retries as you increase it. GitHub-primary queues remain limited to 1 so every PR validates after its predecessor lands.

Increasing concurrency does not itself combine entries into one shared CI run or landing batch.

After a successful automatic landing, the queue schedules its next pass as soon as the current worker releases the queue lease. An already-validated follower can then advance without waiting for the periodic recovery sweep. It still needs current passing checks and landing permissions; paused queues and changes awaiting manual landing remain stopped.

Next: inspect queue wait and run duration, or configure stack landing and priority.