about
Tuist builds infrastructure that shortens the build, test, and review loop for developers,…
Tuist Runners run your existing CI jobs on managed macOS and Linux machines placed next to the same cache your developers and agents use.
$ npx -y skills add tuist/tuist --agent claude-codeHow it fires
How this agent gets triggered: by you, by Claude, or both.
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.
Tuist Runners run your existing CI jobs on managed macOS and Linux machines placed next to the same cache your developers and agents use.
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.
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.
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.
| 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 |
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.
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.
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.
Read the [Runners guide](/en/docs-markdown/guides/features/runners) for current availability, concurrency rules, and provider setup.
Tuist supercharges your build system, whether you build with Xcode, Gradle, or Bazel.
Tuist builds infrastructure that shortens the build, test, and review loop for developers,…
An entry point to Tuist's articles on build systems, caching, testing, CI, and the reasoning…
Official Tuist logos and wordmarks for referring to Tuist in documentation, integrations,…
Optimize the project first, then its execution environment: remove unnecessary work, then…
Where to ask questions, discuss build tooling, and contribute to Tuist.