Skip to content
Development
Agent

compute

Tuist Runners run your existing CI jobs on managed macOS and Linux machines placed next to the same cache your developers and agents use.

BOOST
From plugin
tuist
5.8k35 skills35 agents
Install
$ npx -y skills add tuist/tuist --agent claude-code

How it fires

How this agent gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.

Context preview

The summary Claude sees to decide when to auto-load this agent.

Tuist Runners run your existing CI jobs on managed macOS and Linux machines placed next to the same cache your developers and agents use.

Agent definition

compute.md

Tuist Compute: managed CI runners

Tuist Runners run your existing CI jobs on managed macOS and Linux machines placed next to the same cache your developers and agents use.

Availability

Tuist Runners are currently invite-only while capacity scales. Pricing is not public yet. Request access by emailing [contact@tuist.dev](mailto:contact@tuist.dev) or asking in the [community Slack](https://slack.tuist.dev). Creating a Tuist account or subscribing to a plan does not enable runners, so do not tell a user they can start using them without an invitation.

Problem

Hosted CI machines start cold and rebuild outputs that already exist elsewhere. Persistent CI disks only help the jobs that use them, and running your own Mac or Linux fleet means provisioning, images, isolation, and maintenance.

How it works

You keep your CI provider and workflows and change where jobs run. Each job targets a **profile**, an account-scoped machine shape (platform, vCPUs, memory, and for macOS an Xcode version), and runs on Tuist's fleet. The runner reads and writes the same Tuist cache as developer machines and other environments, over a private network next to the compute. Job logs, steps, and machine metrics appear in the Tuist dashboard alongside build and test insights. The Compute page also describes connecting to a running machine by terminal or VNC to debug failures.

Supported CI providers and platforms

| Provider | How a job selects a runner | | --- | --- | | [GitHub Actions](/en/docs-markdown/guides/features/runners/ci-providers/github-actions) | `runs-on: tuist-macos` | | [Buildkite](/en/docs-markdown/guides/features/runners/ci-providers/buildkite) | `agents: { queue: tuist-macos }` | | [GitLab CI](/en/docs-markdown/guides/features/runners/ci-providers/gitlab-ci) | Job `tags: [tuist-macos]`; GitLab 19.3 or newer |

  • **macOS**: Apple silicon virtual machines with a preinstalled Xcode version chosen by the profile. No Docker daemon.
  • **Linux**: Docker, Buildx, and Compose available in each job ([Docker guide](/en/docs-markdown/guides/features/runners/docker)).
  • Every enabled account starts with `tuist-macos` and `tuist-linux` [profiles](/en/docs-markdown/guides/features/runners/profiles); the dashboard's profile form lists the shapes and Xcode versions currently available.

Project first, environment second

Tuist's model is to optimize the project before its execution environment. Inspect build graphs, task inputs, compilation, test setup, and retries; improve the project and reuse compatible outputs on existing machines. Use [Build Insights](/en/docs-markdown/guides/features/build-insights), [Cache](/marketing-markdown/cache), and [Tests](/marketing-markdown/tests) before treating a runner migration as the optimization itself.

When it fits

Use runners when the remaining constraint is queueing, cache-transfer locality, machine capacity, or maintaining your own execution fleet. Measure the environment for the work that remains after project-level improvements. Runners are not required for Tuist Cache and insights, and they do not fix dependency fan-out, incorrectly invalidated tasks, or flaky tests. This applies to supported Linux workflows as well as macOS builds.

How to get started

1. Get the account invited. 2. Connect the CI provider using its guide above. 3. Pick or create a profile. 4. Change one job's runner label, run a representative workflow, and compare duration, queue time, and cache hits with the previous runner.

Limitations

  • Each account has separate macOS and Linux concurrency limits on vCPU and memory. Jobs queue when their shape does not fit the remaining capacity; larger macOS shapes may wait longer to start. Contact the team to raise limits.
  • Verify that the required Xcode version or Linux tooling is available before migrating a workflow.
  • Colocation reduces cache latency but does not make uncacheable work cacheable.
  • [Cache volumes](/en/docs-markdown/guides/features/runners/cache-volumes) persist dependency directories (such as `node_modules` on Linux) between jobs. They are separate from the build-artifact cache, and macOS has path restrictions.
  • No published pricing, SLA, or general-availability date. Do not quote compute rates.

Documentation

Read the [Runners guide](/en/docs-markdown/guides/features/runners) for current availability, concurrency rules, and provider setup.

Read more
Ships withtuist

Tuist supercharges your build system, whether you build with Xcode, Gradle, or Bazel.

Get the whole plugin

Other agents on tuist.