Skip to main content
Last updated on Oct 8, 2026 Incredibuild supports acceleration for Unity Addressables content builds and Player builds on Windows. This requires Incredibuild 10.38.1 or later. For Addressables content builds, Incredibuild uses Build Cache. For Player builds, Incredibuild uses Build Cache and also distributes compilation across your grid. Shader variants and C# scripts that Unity would compile, one machine at a time, are sent to Helper Agents instead. Helper Agents need only Incredibuild installed; they do not need Unity. Your Unity installation is not modified. If a remote compile fails or the grid is saturated, that compilation starts over locally and the build continues. On a sample project, a rebuild with Build Cache went from roughly two hours to about 40 minutes: the content build went from an hour to 30 minutes, and the Player build went from an hour to ten minutes.

​
Requirements

  • Incredibuild 10.38.1 or later, installed on the Initiator and on the Helper Agents. Helper Agents do not need Unity. See Standard Installation.
  • Unity Editor on the Initiator, one of the verified versions below.
  • Windows.
  • A build launched through BuildConsole from the command line, not from the Unity GUI.
  • For Addressables content build acceleration: Addressables and Scriptable Build Pipeline (SBP), one of the verified versions below.
If the version you use is not listed, contact Incredibuild.

​
Supported versions

Incredibuild verifies specific tuples of Unity Editor, Addressables, and SBP versions together—not each component in isolation. Using other versions that were not verified may not accelerate as expected. Incredibuild still attempts acceleration on other combinations; see Unverified versions. Unity Editor
  • 6000.0.53f1 LTS Verified
  • 6000.0.58f2 Verified
  • 6000.0.62f1 LTS Verified
  • 6000.0.76f1 LTS Verified
  • 6000.0.82f1 LTS Verified
  • 6000.3.23f1 LTS Verified
  • 6000.5.10f1 LTS Verified
  • 6000.5.0b1 Verified
Addressables
  • 1.21.12 Verified
  • 2.7.6 Verified
SBP
  • 2.4.0 Verified
  • 2.4.3 Verified
  • 2.5.0 Verified
  • 2.6.1 Verified

​
Unverified versions

If your exact Unity Editor, Addressables, and SBP tuple is not verified, Incredibuild still tries to run the accelerated content build. Results can vary; check the build log for one of these messages: For any issues, contact Incredibuild.

​
Addressables content builds and Player builds

When building a game with Addressables, there are two types of builds:
  • Content build builds the Addressables.
  • Player build builds the game, such as the game.exe file. This process also compiles shaders and C# scripts.
The content build must finish successfully before you can start the Player build. Incredibuild supports acceleration for both build types. Each type has its own BuildConsole command. Use each command as written. Do not copy Unity flags from the Player command onto the content command, or the other way around.

​
Configure Addressables

Under AddressableAssetSettings > Build Addressables on Player Build, set the option to Do not Build Addressables content on Player Build. See Build Addressables on Player Build in the Unity documentation. Unity can start a content build automatically when you run a Player build. An accelerated content build requires its own BuildConsole invocation, so a content build started automatically by Unity is not accelerated. Run the content build and the Player build separately, using the commands below.

​
Accelerate an Addressables content build

  1. Confirm Incredibuild is installed. BuildConsole.exe is typically at:
  2. Open Command Prompt.
  3. Run:
Where:
  • <YOUR_UNITY_INSTALLATION_PATH> is the Unity Editor installation path for the version used for the project.
  • <YOUR_UNITY_PROJECT_PATH> is the project path, usually the root of the game’s Git repository.
Wait for the content build to finish successfully before starting the Player build.

​
Accelerate a Player build

​
Run the build with the Unity profile

Incredibuild supports custom tool distribution through XML profiles. Specify the profile on the BuildConsole command line with /profile. For Unity Player builds, use the supplied profile:
Using an absolute path avoids ambiguity about where the profile file is resolved from. Example:
Where:
  • <YOUR_UNITY_INSTALLATION_PATH> is the Unity Editor installation path for the version used for the project.
  • <YOUR_UNITY_PROJECT_PATH> is the project path, usually the root of the game’s Git repository.
  • N is the Unity worker count (see Set the Unity worker count).
  • <YOUR_BUILD_PLAYER_ARGUMENT> is the Unity argument that builds the Player for your platform, such as -buildWindows64Player. For platforms without a build argument, replace <YOUR_BUILD_PLAYER_ARGUMENT> \"<YOUR_PLAYER_OUTPUT_PATH>\" with -executeMethod <YOUR_BUILD_METHOD>, where <YOUR_BUILD_METHOD> is the static method in your build script that builds the Player, such as MyBuildScript.BuildPlayer.
  • <YOUR_PLAYER_OUTPUT_PATH> is where Unity writes the built Player.
For the available build arguments, see Unity Editor command line arguments in the Unity documentation.

​
Optional Unity Editor arguments

You can add the following arguments inside the /command="..." string, after \"<YOUR_UNITY_PROJECT_PATH>\":
  • -buildTarget <YOUR_BUILD_TARGET> opens the project on the given platform, such as Win64. A build argument such as -buildWindows64Player already sets the platform, so you need this only when you build with -executeMethod <YOUR_BUILD_METHOD>.
  • -logFile \"<YOUR_LOG_FILE_PATH>\" writes the Unity log to the given path. Without it, Unity writes to its default log file, %LOCALAPPDATA%\Unity\Editor\Editor.log. To show the log in the BuildConsole output instead, use -logFile -.

​
Set the Unity worker count

Set Unity’s worker count on the Unity Editor command line:
Unity’s worker count limits how many shader compilation jobs it can issue concurrently. If the value is too low, the Incredibuild grid can have unused capacity even when Helper Agents are available. Size N high enough to expose the shader-compilation parallelism you want on the grid. For a grid where you intend to make roughly 120 cores available to shader compilation:
Start with a worker count at least as large as the total grid capacity you intend to use, then validate utilization and build behavior in Build Monitor. This is a Unity-workflow tuning recommendation, not a general Incredibuild requirement.
This completes the distribution setup. If you share a cache between machines, complete the Build Cache configuration below.

​
Build Cache

If Build Cache is enabled, Unity shaders caching is enabled by default. An unchanged shader is restored from the cache instead of being recompiled. No extra configuration is required for a cache used by a single machine. To share a cache across Initiators, also configure a Build Cache endpoint, then add the path alias below so cache entries match across machines.

​
Share a cache between machines

To share a cache across Initiators, each machine must tell Build Cache where its Unity installation lives. Without this, cache entries record the full path to your Unity installation, so a machine with Unity in a different folder never finds them—and there is no warning, only a low hit rate. Edit:
If the file already contains other settings, leave them in place. Add or update a UnityEditor entry inside knownPaths so it points at the folder that contains the version folders on that machine:
If Unity is installed elsewhere, use that path instead:
Ensure that:
  1. The name UnityEditor is identical on every machine. The value is the machine’s specific path. This allows a machine using the Hub default path and a machine using D:\unity_editor\ to share the same cache entries.
  2. Point at the parent folder, not a version folder, and keep the trailing backslash. Backslashes are doubled because the file is JSON.

​
Check that caching works

  1. Clear the Build Cache store, delete Unity’s Library folder, and build. Expect close to 100% misses, and a high “tasks added to cache” count.
  2. Delete the Library folder again, leave the Build Cache store untouched, and build again. Most tasks are restored with a much shorter build time.
To confirm that the cache invalidates correctly rather than just being fast:
  1. Change a constant in an .hlsl or .cginc that shaders include.
  2. Rebuild without clearing the store. Only the shaders that depend on it recompile.