Unity CLI and Pipeline 0.9: Automate Mobile Builds and Tests

Unity now has a real command-line tool, and its companion package can drive a running Editor from a script. With the Pipeline package reaching version 0.9 this autumn, the pair has become usable for the boring parts of mobile game work: installing editors on a new machine, building Android and iOS players, running tests and checking that a scene still loads. This guide explains what each piece does, what changed in 0.9, and a setup a small Unity studio can try in an afternoon.

▶ Watch the video version (about 4 minutes):

Two tools, one unity command

Unity introduced the Unity CLI on its blog on July 20, 2026 together with an experimental package, com.unity.pipeline. They are easy to confuse, so it helps to separate them early.

• Unity CLI is a standalone binary called unity. It replaces the old Unity Hub headless mode for installing editors and modules, opening projects, signing in and diagnosing the environment. It does not need a project or a running Editor.
• Unity Pipeline package is installed into a project. When the Editor opens, it starts a small HTTP server on your machine, and the CLI sends commands to it: enter Play mode, run tests, build a player, create a prefab, take a screenshot. Unity's comparison page puts it simply: the CLI manages Unity, the package lets the CLI act inside the Editor.

Despite the name, the Pipeline package has nothing to do with render pipelines (URP/HDRP) or Unity's hosted build service. Unity Releases notes this separation explicitly, and it saves a lot of confusion in team chats.

The CLI is still labelled beta and the package is experimental. That status matters for how far you should trust it, which we come back to below.

What the Unity CLI does on its own

The CLI alone is already useful for anyone who has scripted Unity Hub before. According to the CLI documentation, the common tasks look like this:

unity install lts                              # latest LTS Editor
unity install-modules -e 6000.3.7f1 -m ios     # add the iOS module
unity editors -i                               # list installed Editors
unity open ./MyGame                            # open with the right version
unity doctor                                   # environment diagnostics

Three details make it fit for automation. Every listing can be printed as JSON or TSV (unity editors --format json). Errors go to stderr and exit codes follow a fixed contract: 0 for success, 1 for error, 130 for cancelled. And installs can run without prompts using --accept-eula --yes, while build agents authenticate with a service account through environment variables instead of a browser login.

Installation is a one-line script (curl -fsSL https://unity.com/install.sh | bash on macOS and Linux, a PowerShell script on Windows), and Unity's technical walkthrough also lists a Homebrew cask: brew install --cask unity-cli. Supported systems are macOS 14 or newer, Windows 10 21H1 or newer, and Linux distributions with glibc 2.34 or newer (Ubuntu 22.04, RHEL 9). Older build boxes on Debian 11 or Amazon Linux 2 are not supported, which is worth checking before you plan a CI change.

What the Pipeline package adds

The package turns a running Editor into something you can call. Setup, from the package guide, is four commands run from the project folder while the Editor is open:

unity auth login
unity pipeline install     # adds com.unity.pipeline, Editor recompiles
unity pipeline list        # should show "Pipeline: Installed"
unity command              # list what this Editor can do

It requires Unity 6.0 or later. The built-in command set is large: assets and import settings, scenes, GameObjects and components, prefabs, materials, animation and Timeline, lighting and NavMesh bakes, Package Manager, console logs, screenshots, builds and tests. For a mobile team, the build and test commands are the ones that pay off first:

Mutating commands follow a confirm or dry-run convention: build run without confirm=true is refused, and dry_run=true checks the target, output path and scene list without building. Long operations return immediately and you poll a status command, which survives the domain reload that a recompile or platform switch causes.

Two more features stand out. You can expose your own static methods as commands with a [CliCommand] attribute, so "bump bundle version, build Android, copy the AAB to the shared drive" becomes one call. And unity command eval runs a C# snippet inside the live Editor, compiled with Roslyn on the main thread, without a project recompile. It is gated by a per-project security token, and Unity's own walkthrough says to treat it like remote code execution.

What changed in 0.9

Version 0.9.0-exp.1 shipped on September 22, 2026, and 0.9.1-exp.1 on October 22. The changes that affect anyone who started scripting earlier:

• Commands are now grouped. You run unity command <group> <name>, for example unity command build run or unity command editor.playmode start. The old flat names no longer work, so scripts written against 0.8 need updating.
• Build Profiles from the terminal. New commands list the platforms a profile can target, create a profile and edit its scene list and scripting defines.
• Play mode keeps running when the Editor is unfocused. An Editor driven from a terminal is usually in the background, and without Run In Background its player loop stops after the first frame. A new command and a project setting fix this for Play mode only; builds keep the project's own value.
• Per-command timeouts, and status requests that answer while another command is running.
• Mobile build fix in 0.9.1. Before it, building for Android, iOS or any non-Standalone target threw an exception in the package's pre-build step and skipped baking its runtime settings into the build. If you tried earlier versions on mobile and gave up, this is the reason to try again.
• Security. The server only answers requests addressed to its own 127.0.0.1 address, which blocks DNS-rebinding attacks from a web page, and it caps queued or running commands at 100.

One known limitation is documented: build run --profileName still builds the global Build Settings scene list even when the profile overrides it. Until that is fixed, pass scenes explicitly with --scenes.

A practical setup for a small mobile studio

Here is the order we would follow, starting with low-risk steps.

1. Install the CLI on every dev machine and run unity doctor. Replace any Hub headless scripts with unity install and unity install-modules so a new laptop gets the exact editor and Android/iOS modules in one script.
2. Pin the editor version your games ship on. Store it in the repo and have the setup script install that version, not "latest".
3. Add the Pipeline package on a branch first, not straight into main. Check the diff in Packages/manifest.json and confirm it stays out of release builds. Since 0.9, development player builds only include its runtime part with the debug, checked or instrumented managed code variants.
4. Script the daily checks: recompile, run EditMode tests, then build run with dry_run before a real Android build. Read totalErrors, totalWarnings, totalSizeBytes and buildTimeMs from build status and post them to your team chat. Tracking build size per commit catches the classic mobile mistake of an uncompressed texture or a forgotten test asset.
5. Write two or three custom commands for things people do by hand every week, such as switching ad SDK test mode, setting the version code, or exporting a store screenshot scene.
6. Only then try an AI agent. Unity ships a plugin with a unity-cli skill for Claude Code, Codex and Grok, and the commands are also available in an MCP mode. Give the agent named commands first and keep eval for local experiments.

A runtime server can also be enabled in development builds through a Runtime Pipeline Manager component, letting you pause or slow time, read logs or tweak values in a running test build. It is localhost-only, off by default and meant for development and QA builds, never production.

Limits and risks to keep in mind

• Experimental means breaking changes. The 0.9 rename of every command shows how fast the API still moves. Pin the package version and read the changelog before upgrading.
• It needs a running Editor. For clean, reproducible release builds on a CI server, the classic batch-mode build with an -executeMethod build script is still the safer path. Pipeline shines on a developer machine or a dedicated build Mac that keeps the project open.
• Local only by design. The server binds to the local machine. Exposing it over a network is your responsibility and your risk.
• Agents act with your permissions. Unity's walkthrough compares giving the CLI to an agent with giving an assistant access to your computer. Keep secrets such as keystore passwords out of commands and logs.

Our take

At Lightning Games we ship Unity mobile titles from Da Nang with a small team, and most lost hours are not in gameplay code. They are in switching platforms, waiting for imports, rebuilding after a small fix, and checking by hand that a build still opens. The Unity CLI is worth adopting now for editor installs and machine setup, because it is simple and its output is predictable. The Pipeline package is worth a trial branch, especially since 0.9.1 fixed mobile builds, but we would not put an experimental package in the release path yet. Our plan is to use it for nightly test-and-size reports and a few custom commands, keep release builds on batch mode, and revisit when it leaves experimental status.

Sources

• Meet the Unity CLI: manage Unity from your terminal (Unity blog, July 20, 2026)
• Use the Unity CLI (Unity Docs)
• Unity Pipeline package setup (Unity Docs)
• Unity Pipeline changelog, 0.9.0 and 0.9.1
• Build, compilation and test commands (Unity Pipeline 0.9 manual)
• Unity Pipeline and Unity CLI technical walkthrough (Unity)
• Compare the Unity CLI and the Pipeline package (Unity Docs)
• What's new in Unity Pipeline (Unity Releases)

Want to see what we build with Unity? Visit Lightning Games.

Cover photo: Programmer at work (Unsplash).jpg) by Crew, CC0 1.0, via Wikimedia Commons (cropped).