Workers
Workers are the machines that execute your builds. iOS builds run on macOS workers with Xcode, and Android builds run in Docker containers. BuildMagic automatically assigns builds to available workers based on capacity.
How Workers Work
When you trigger a build, it enters a queue. The BuildMagic orchestrator picks up the queued build and assigns it to an available worker. The worker creates a clean build environment (a macOS VM for iOS or a Docker container for Android), executes your pipeline steps, and reports results back to the dashboard.
Each build gets its own isolated environment that is destroyed after the build completes. This ensures every build starts from a clean state.
Worker Status
You can see the status of all workers in the dashboard. Workers report their status via a heartbeat every 10 seconds.
| Status | Meaning |
|---|---|
| Online | The worker is connected and ready to accept builds. |
| Busy | The worker is running builds at its maximum capacity. |
| Offline | The worker has not sent a heartbeat recently. Builds will not be assigned to this worker. |
Build Environments
iOS Builds
iOS builds run inside macOS virtual machines powered by Tart. Each build gets a fresh VM clone with:
- macOS Sequoia
- Xcode 26.4.1 with Swift 6.3.1 and the iOS 26.4 SDK
- Flutter 3.47.0, plus FVM so a project can pin its own version
- CocoaPods 1.17.0, Swift Package Manager, fastlane
- Ruby 4.0.6
- Node.js and npm/Yarn/pnpm (for React Native projects)
The Xcode version is fixed by the machine image. An xcode: entry in your configuration is read but not applied — BuildMagic does not switch Xcode at build time. When the version you ask for is not the one installed, the build says so in its first lines rather than leaving you to discover it through a compiler error deep inside a dependency. The same holds for cocoapods, node, java and ruby.
Flutter is the exception: a project pins its own version and FVM installs it, so upgrading the image does not change which Flutter your builds use.
Android Builds
Android builds run inside Docker containers with:
- Android SDK with platforms 34 and 35, and matching build tools
- Gradle 8.5, Java 17 (OpenJDK)
- Flutter stable, switched per project when a version is pinned
- Node.js 20 with npm, Yarn and pnpm through corepack
- Python with the Google Play publishing libraries
A different image can be used for a build by setting CM_DOCKER_IMAGE.
Build Queue
If all workers are busy when you trigger a build, the build enters a queue with status Pending. As soon as a worker becomes available, the next build in the queue is picked up automatically.
Builds are processed in the order they are triggered (first in, first out).
Scaling
Build capacity scales with the number of workers. Adding more workers increases the number of builds that can run in parallel. There is no limit to the number of workers that can be connected.
Each worker can run multiple builds in parallel (typically 2 per machine, depending on hardware). The recommended configuration is 2 concurrent builds per Apple Silicon Mac Mini with 16GB RAM.