Ideal for lightweight single-project builds, unit tests, and low-concurrency archives. Clean dependency caches regularly to prevent the working directory from filling local storage.
Rent ZoneMini M4 Core
Connect Your Engineering Workflow
Put post-commit engineering tasks on a Cloud Mac
ZoneMini provides dedicated physical Cloud Mac Hosts that run continuously—not virtual machines. Send code commits to fixed nodes, then return test reports, archives, model results, or finished media to your existing delivery pipeline.
- Resource model
- One order corresponds to the selected dedicated physical node
- Catalog size
- 3 configurations, 5 available nodes
- Access options
- SSH, macOS GUI, and CI Runner
BUILD ROUTE
Fixed-node execution
-
01Code commit Repository events, scheduled jobs, or manual triggers enter the queueINPUT
-
02Build execution Restore dependencies, run tests, sign, and create an archiveRUN
-
03Artifact delivery Return IPA files, logs, reports, model metrics, or media filesOUTPUT
Six reproducible stages from repository trigger to IPA verification
Reliable iOS cloud builds involve more than an Archive command. Use a fixed toolchain, controlled caches, restricted signing access, and clear artifact checks. Every stage should leave traceable logs so failures can be attributed to dependencies, compilation, signing, or export.
-
01
Receive repository trigger
Trigger builds through a main-branch merge, release tag, or manual job. Write the branch name, commit hash, version, and build number into the job context so artifacts remain traceable to source.
-
02
Restore locked dependencies
Install Swift Package, CocoaPods, or JavaScript dependencies from lockfiles. Partition caches by project, tool version, and lockfile digest so branches do not reuse incompatible dependencies.
-
03
Grant signing access
Unlock only the certificates and provisioning profiles required during the build, and restrict Runner read access. Close temporary access when the job ends; never write private keys, tokens, or full passwords to logs.
-
04
Run tests and archive
Run static checks and unit tests first, then call Xcode Archive. Stop signing immediately on test failure and retain test results, compiler output, and failed cases.
-
05
Export IPA
Generate the IPA with a versioned export configuration while saving the dSYM, archive, and export logs. Keeping only the final install package leaves crash analysis and version tracing without evidence.
-
06
Run pre-upload checks
Verify the Bundle ID, version, build number, signing result, privacy manifest, and package changes. Hand artifacts to the upload or release-approval stage only after all checks pass.
Choose a configuration by workload
Three catalog tiers for three build workloads
Start with peak memory, concurrency, and job duration before choosing a machine. Do not judge by project name alone or mistake growing disk caches for compute demand.
Ideal for daily development, multi-branch pipelines, React Native or Flutter native builds, and teams that need to retain more dependency cache.
Rent ZoneMini M4 PlusIdeal for high-load parallel builds, large-model inference, heavier media workloads, and long-running batch jobs. Validate high-memory workloads on this tier first.
Rent ZoneMini M4 ProTreat multiple fixed Runners as schedulable resources—not shared workstations
A build farm is not about sending every job to any machine. Define stable node responsibilities. Design labels, queues, cache boundaries, log retention, and regional placement together so failures are traceable and capacity is measurable.
RUNNER ASSIGNMENT
Labels determine job placement
ios-light
Commit validation and unit tests
Prioritize short jobs, limit concurrency, and release the queue immediately on failure
ios-release
Signing archives and release candidates
Use a fixed toolchain and permission boundary; retain complete export records
cross-platform
React Native and Flutter
Separate JavaScript, CocoaPods, and native build caches
high-memory
Model inference and large parallel jobs
Bind to ZoneMini M4 Pro and record peak memory and output directories
Split queues by duration and permissions
Do not put commit validation, release archives, and high-memory jobs in one undifferentiated queue. Give long jobs dedicated labels so short tests do not wait indefinitely.
Isolate caches by project and version
Cache keys should include at least the project, branch strategy, tool version, and lockfile digest. If cache hits become abnormal, clear only the affected project—not the entire node.
Archive failure logs consistently
Save the commit identifier, Runner label, Xcode version, dependency summary, failed stage, and redacted logs. Set a retention period and exclude access tokens.
Place nodes near repositories and teams
Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US East Coast are available node locations. Prioritize repository location, team time zones, and artifact delivery routes.
React Native and Flutter bottlenecks usually sit in the native layer
JavaScript or Dart can be developed in many environments, but iOS dependency resolution, simulator testing, signing, and archiving still require macOS and Xcode. A fixed Cloud Mac moves this work from personal computers into the team pipeline.
React Native
Manage JavaScript and native dependencies separately
- Dependency restore:Install Node.js packages from the lockfile, then enter the iOS directory and restore CocoaPods dependencies.
- Cache boundaries:Use separate keys for package-manager, Pods, and DerivedData caches; never cache the entire working directory.
- Test order:Run type checks and JavaScript tests first, then native unit tests or simulator checks.
- Signing build:Use a fixed Scheme on the release branch to generate the Archive, IPA, dSYM, and export logs.
- Multi-branch strategy:Use feature branches for validation only; grant signing access only to candidate branches to avoid producing a release package for every commit.
Flutter
Record Dart and Xcode stages separately
- Environment check:Pin Flutter, Dart, CocoaPods, and Xcode versions, and output a version summary at the start of each job.
- Native dependencies:Restore iOS plugin dependencies and check whether plugins require additional system permissions or a higher minimum deployment target.
- Simulator testing:Separate component tests from iOS simulator tests, retaining test reports and screenshots on failure.
- Signing archive:Generate the iOS Archive with controlled configuration, then verify export options and signing results.
- Branch isolation:Use separate working directories for stable and experimental branches to prevent build artifacts and caches from overwriting one another.
CHECK 01
Is the lockfile updated with the commit?
When dependency declarations change without a lockfile update, differences between local success and CI failure become difficult to reproduce.
CHECK 02
Does the native module require a newer toolchain?
Before upgrading a plugin, confirm the Xcode version, deployment target, and CocoaPods requirements, then update the fixed node.
CHECK 03
Can the cache be safely invalidated?
Every cache must be rebuildable after deletion; never treat a cache as the sole dependency source.
Put high-memory nodes to work on continuous model experiments
Cloud Mac Hosts are well suited to model preparation, inference runs, metric tracking, and result export in a fixed Apple Silicon environment. They do not replace a training platform; they are better for validating local inference paths, running batch experiments, and observing resource behavior on macOS targets.
Recommended high-memory configuration
ZoneMini M4 Pro
M4 Pro · 64GB · 2TB
01
Prepare the model and verify files
Record the model version, source, file digest, quantization method, and runtime script version. Verify large files before moving them into the experiment directory.
02
Isolate the runtime environment
Create an independent environment for each experiment and pin Python packages and native dependencies. Do not let temporary upgrades change a validated baseline.
03
Run batch inference
Increase load gradually by batch size, input length, and concurrency. Record peak memory, runtime, failed samples, and retry counts.
04
Export metrics and results
Export parameters, environment summary, output files, and redacted logs together. Do not keep only the final average; anomalous samples also need tracking.
Leave long transcodes to fixed nodes and return finished media to your archive
Audio and video jobs often consume processor, memory, and disk simultaneously. A sound workflow separates input synchronization, temporary processing, quality checks, and final delivery instead of using the Cloud Mac working disk as a permanent media library.
Sync media and verify file digests
Sync source files, subtitles, audio tracks, and processing parameters from the job manifest. Check file sizes or digests after transfer so long jobs never start with incomplete media.
- Input
- Source video, audio tracks, subtitles, parameter sheet
- Record
- File digest, encoding requirements, output naming
Transcode and generate proxy files
Split jobs by resolution, codec, or project batch. When waveforms, proxy files, or thumbnails are needed, save generation parameters in the same job record.
- Process
- Batch transcodes, waveforms, proxy files, thumbnails
- Isolation
- Independent temporary directory and failure list for each batch
Automated checks followed by manual sampling
First verify duration, resolution, audio-track count, and output completeness, then manually sample key clips. Rerun only the affected batch for failed files.
- Automated
- Duration, dimensions, audio tracks, file integrity
- Manual
- Picture, sound, subtitles, and key clips
Return finished media and clean the temporary disk
Return finished files, processing logs, and the failure list to the team’s designated storage. Clean temporary files after confirming delivery to prevent long-term disk accumulation.
- Artifacts
- Finished files, logs, failed-job list
- Boundary
- The working disk is not a long-term archive
Turn pre-submission checks into pipeline gates
A successful archive does not mean an app is ready for submission. Verify version information, signing, privacy manifests, archive validation, screenshot assets, and release notes before delivery. ZoneMini provides the execution environment, not the distribution platform’s review rules.
RELEASE GATE
Pass all six checks before delivering the candidate package
Save check results, commit hash, version, and build number for every candidate build. When an issue appears, return to the relevant stage instead of making unrecorded configuration changes before final submission.
-
01
Version and build numbers
Confirm they match the release branch, change record, and candidate package, with no duplicate build number.
-
02
Signing and provisioning profiles
Verify that the Bundle ID, signing identity, permission declarations, and export method match the target.
-
03
Privacy manifest
Check privacy declarations included by the app and its dependencies, and confirm new SDKs are within the review scope.
-
04
Archive validation
Save validation output and resolve missing symbols, permission mismatches, or unsupported build settings.
-
05
Screenshots and metadata assets
Prepare screenshots, descriptions, and update content for the target devices, language, and version; verify file names.
-
06
Pre-submission regression
On the candidate package, check launch, sign-in, core flows, network failures, and upgrade scenarios.
Separate execution environments from review rules
Cloud Mac Hosts can continuously run builds, validation, and artifact organization, but app content, metadata, compliance requirements, and final review results are governed by the applicable platform rules. Teams should retain their own release approver and rollback process.
Combine nodes by queue, permissions, and collaboration scope
Node count should not be based on team size alone. Confirm concurrent workload, independent signing boundaries, cache-sharing needs, and member and repository distribution before choosing one node or several.
1 continuous node
Independent developer
Use one fixed environment for daily development, testing, and candidate-package archiving. Store dependency versions, signing steps, and cleanup scripts in the repository to reduce differences between local and remote environments.
- Start lightweight single projects on ZoneMini M4 Core
- For cross-platform projects or larger caches, prioritize ZoneMini M4 Plus
- Export archives, logs, and project materials that must be retained regularly
2 job queues
CI team
At minimum, separate commit validation from release archiving. Add nodes by label as volume grows, rather than making a signing-enabled Runner handle every routine test.
- Give short-test queues priority; route long archives to a dedicated queue
- Isolate node caches by project and archive failure logs consistently
- Bind high-memory or parallel jobs to ZoneMini M4 Pro
5 nodes available
Distributed team
Choose among Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, and the US East Coast based on proximity to repositories, core team members, or delivery routes. Do not distribute solely by member location.
- When repository interaction is frequent, prioritize proximity to the repository
- For frequent GUI collaboration, also consider primary operators
- Use the same toolchain inventory and log format across nodes
First, confirm
Workload type and concurrency peak
List whether build, test, inference, and media jobs will run simultaneously.
Then, confirm
Memory, storage, and duration
Choose a configuration from the three catalog tiers based on actual peaks, not the project name.
Finally, confirm
Node, term, and payment method
All orders are billed in USD. Supported payment methods are USDT-TRC20 and Visa / Mastercard / Amex (via Stripe).
Before ordering
Choose a node and configuration based on workload
Prepare your use case, concurrent job count, target node, rental term, and storage needs. For connection options, see the remote access guide; for configuration recommendations, contact the team.