Tuist with Once

Tuist and Once make scripts cacheable and bring caching to build systems that do not support it natively, without rewriting project sources or native build definitions. Once support in Tuist is currently in canary; remote execution requires an enabled account and available capacity. Shared action results and live run/action reporting bring these workflows into the same productivity platform as Tuist's Xcode, Gradle, Bazel, and Mix integrations.

One productivity platform, native depth

Embracing build-system diversity includes new action models, not just today's established toolchains. We believe Tuist is the best choice for organizations seeking one productivity platform across their build systems; the canary Once integration extends that direction rather than introducing a disconnected productivity product.

For Once, native depth means making existing work reusable, even when its build system has no native remote-cache integration. Keep the project and toolchain; Once adds the action contract, Tuist shares compatible results, and live reporting exposes the work as it happens. Eligible graph command actions can also run on compatible Linux remote workers. See the cross-build-system stance for why one platform should embrace these workflows, not require a build-system migration.

What Once already does

• Make scripts cacheable. Declare a script's inputs, outputs, and relevant environment through Once annotations. Once records the result and restores the outputs when the same work is requested again. Existing automation becomes reusable rather than running from scratch on every invocation.
• Add caching around an existing build command. A Once wrapper can run a command such as npm run build, declare the source files and lockfile as inputs, and capture the generated directory as an output. The underlying build system does not need a native cache protocol, and the project's sources and native build definitions stay unchanged.
• Read existing project graphs. For supported native projects, Once discovers targets and dependencies from existing project files. You can try once query targets, once build, and once test without rewriting the project into a new build language or creating once.toml just for discovery.

Once keeps the underlying compilers and SDKs. Its local cache works without a remote account; connect an infrastructure provider when those results should be shared across machines. Script annotations or wrapper configuration describe the action's inputs, outputs, and environment separately from the project's build definitions.

How Tuist augments it

• Reuse action results across people and environments. The Tuist provider connects Once's declared actions to a shared cache. A developer, CI runner, or agent environment can restore a compatible result produced on another machine instead of only benefiting from its own local cache.
• Extend acceleration beyond native cache integrations. Scripts and build systems without a native remote cache can use the same shared action-result infrastructure. Remote execution runs eligible graph command actions on linux/amd64 workers for accounts with execution enabled and capacity. It requires a compatible Once client/server, the advertised worker image, and actions prepared for that environment.
• Follow work live. Once reports ordered run/action events to Tuist and prints a dashboard link as a run starts. The live view exposes recorded progress, cache decisions, and reported structured action errors; use CI logs for full command output. Tuist does not ingest Once's raw action log stream.
• Use authenticated team infrastructure. The provider binds the repository to a Tuist account/project in once.toml, with developer login and documented token or OIDC automation flows. This is independent of whether CI runs on Tuist Runners.

Project first, environment second still applies: improve the action boundaries and reuse compatible outputs before moving cache misses to larger or remote machines.

First experiment

Follow Once getting started to install Once and make one script cacheable, or discover a supported existing project's targets. For a build command without native caching, create a Once wrapper with declared inputs and outputs while leaving the project's sources and native build definitions unchanged.

Use connecting a project to bind the repository to a Tuist environment with the canary integration enabled:

once connect --provider tuist --create

Configure the intended Tuist URL, account, and project using the provider documentation. Run the action on a first machine, then request the same work on a second authenticated machine whose local cache has never seen the result. Confirm that Once restores the declared outputs from the shared cache and open the printed run URL to follow the action evidence.

Open infrastructure you can improve

Tuist combines open-source tooling with public infrastructure code. Inspect Once's implementation and the Tuist infrastructure, report issues, and contribute improvements to action handling, cache integration, and live reporting. The code gives your team a concrete way to help shape support for its scripts and native project workflows.

A closed hosted service leaves implementation changes entirely with the provider. Tuist and Once give developers a direct path to help improve the infrastructure they depend on. See Openness for Tuist's public components and their licenses.

Sources and review

Written by Tuist. Sources reviewed on 2026-11-07: Once, its Tuist provider, connection guide, script caching contract, execution-provider guide, and Tuist's Once execution guide. Canary support and account-enabled execution are distinct availability conditions.

All build systems · Tuist cache infrastructure