Runners {#runners}

[!IMPORTANT] Invite-only

Tuist Runners are currently invite-only while we scale capacity. Reach out or ping us in the community Slack to request access for your account. Pricing isn't public yet; we'll announce it later this year, when Runners become generally available.

Tuist Runners are managed macOS and Linux runners for your GitHub Actions workflows. Instead of running jobs on GitHub-hosted runners, you point runs-on at a Tuist <.localized_link href="/guides/features/runners/profiles">profile</.localized_link> and your jobs run on Tuist's fleet, next to the same <.localized_link href="/guides/features/cache">cache</.localized_link> your team already uses, with no runner agent to install and no infrastructure to maintain.

Adopting them is usually a one-line change to your workflow:

 jobs:
   build:
-    runs-on: macos-latest
+    runs-on: tuist-macos
     steps:
       - uses: actions/checkout@v4
       - run: tuist test

Concurrency limits {#concurrency-limits}

Each account has independent vCPU and memory concurrency limits for macOS and Linux. Before Tuist admits a job, it checks the job's <.localized_link href="/guides/features/runners/profiles#machine-shapes">machine shape</.localized_link> against all jobs currently running on that platform. The job starts only when both its vCPU and memory fit within the remaining capacity; otherwise it stays queued until capacity becomes available. Work on one platform never consumes the other platform's capacity.

The Concurrency section of the Runners dashboard shows the peak admitted vCPU and memory usage for every hour. A red bar means usage reached the configured limit at some point during that hour. Usage cannot exceed the line because jobs that would take either resource over its limit remain queued.

Your current limits are shown alongside each chart. If your workflows regularly reach them and spend time queued, contact us with your account handle, platform, and expected parallel workload. We'll review the required capacity and help raise the limits.

Why Tuist Runners {#why-tuist-runners}

Most CI runner providers make jobs faster by giving you beefier machines and a persistent cache, typically a shared volume mounted back into your CI runs. That helps, but a volume is just a disk: it carries whatever previous CI runs happened to leave on it. It isn't replicated to keep just the freshest artifacts close to where builds run, and it never reaches the other places your code gets built.

Building doesn't happen in one place anymore. The same code is compiled on developer laptops, across CI, and increasingly by coding agents and other automated environments. Tuist Runners are different because they share the same <.localized_link href="/guides/features/cache">cache</.localized_link> all of those environments already read from and write to, whatever build system you use. Artifacts that a teammate warmed on their laptop, that an agent produced, or that an earlier build left behind are a hit on the runner, and vice versa. There's no separate CI cache to warm up, and the speedup isn't limited to CI.

On top of that, the cache is colocated with the runner on the same private network, so cache reads and writes stay internal and close to the compute instead of crossing the public internet.

Put together:

• Shared across every environment. The runner reads and writes the same cache as your developer machines, CI, and coding agents, so work done anywhere warms the cache everywhere.
• Colocated with the compute. Cache traffic stays on the internal network next to the runner, not over a public ingress.
• One system, not bolted-on. Caching, <.localized_link href="/guides/features/selective-testing">selective testing</.localized_link>, <.localized_link href="/guides/features/test-sharding">test sharding</.localized_link>, and <.localized_link href="/guides/features/build-insights">build insights</.localized_link> all run against the same project and account, so the runner isn't a separate silo of build data.