HexVM assigns a dedicated Mac mini physical node to every order—not a virtual machine. Keep your existing repositories, scripts, and release rules, while moving only macOS- and Apple Silicon-dependent stages to the cloud.
Code repository
Commit triggerDedicated node
Environment validationXcode
Build and testArtifacts
Archive and uploadNot every step needs to move. Select a use case to review the recommended workflow, required inputs, and pre-launch checks before deciding how many nodes you need and how to run them.
After a code commit, your repository platform schedules a self-hosted runner to execute dependency restoration, tests, archiving, and artifact uploads on a dedicated node. Your team defines the trigger rules, concurrency policy, and secret permissions.
View the iOS CI/CD workflowKeep validated Xcode versions, command-line tools, and dependency-cache policies on a fixed node. Run branch jobs in isolated working directories, clean temporary data after each build, and retain the required artifacts.
View the macOS automation approachFix model versions, runtime dependencies, input samples, and output baselines to validate tool compatibility, batch scripts, and recovery for long-running jobs. Resource limits depend on the selected available model.
View AI experiment limitsYour team controls access to certificates, provisioning profiles, and the keychain. The build node creates and validates archives; an authorized team member performs the final submission.
View the certificate and distribution workflowUse VNC for graphical tools and UI checks, and SSH for code synchronization, script execution, and long-running jobs. Verify node details on first connection and update temporary credentials immediately.
Read the remote access guideA dedicated physical machine is ideal for pipelines that need a fixed Xcode version, stable cache directories, and clear permission boundaries. Nodes do not share compute resources with other orders, but your team remains responsible for repository permissions, signing materials, and job cleanup.
Trigger jobs from a branch, tag, or pull request. First restrict, in the repository settings, who can trigger release workflows so ordinary test jobs cannot access signing permissions.
Acceptance: trigger rules are reproducibleAssign clear labels to the self-hosted runner, such as chip architecture, Xcode major version, and purpose. Evaluate single-node concurrency based on peak job memory and disk write volume.
Acceptance: jobs enter only the target nodePin dependency versions and run unit tests, UI tests, or static checks. When a job fails, retain the exit code, test report, and key logs instead of saving only the final screen of output.
Acceptance: failure causes are identifiableUnlock the required keychain only temporarily for release jobs, then close access immediately. Keep certificates and provisioning profiles separate by project and environment; do not leave them in plaintext in ordinary build directories.
Acceptance: permissions are minimizedUpload archives, test reports, and symbol files, recording the commit hash, build number, and toolchain version. After success, remove project-sensitive content from derived data.
Acceptance: artifacts are traceableTest Runners should not access release certificates; only archive jobs from protected branches should load signing materials. This limits credential exposure even if a script in an ordinary job fails.
A continuously running node can retain validated toolchains and download caches, but every job should still use an isolated working directory. Caches accelerate builds; they should never be a prerequisite for success.
Create a working directory for each job ID and remove temporary files when the build ends. Do not let concurrent branches modify the same dependency directory or output path.
Cache keys should include at least the dependency lockfile digest, toolchain major version, and architecture. If cache hits behave unexpectedly, allow a clean build with the cache bypassed in one step.
Store test results, notarization preparation materials, installers, and symbol files separately. Artifact names should include the version, build number, and commit identifier.
xcodebuild -version
xcode-select -p
swift --version
git rev-parse --short HEAD
xcodebuild test -scheme "Project" -destination "platform=macOS"Put version verification at the start of every build log. When environment drift appears, first compare toolchain paths, the project commit, and dependency lockfiles before deciding whether to clear the cache.
A cloud Mac is well suited to reproducing experiment environments, checking toolchain compatibility, and running recoverable batch jobs. Hardware capabilities are bounded by the two available configurations; do not extrapolate results to unlisted specifications.
Save the model version, sample digest, random seed, and runtime parameters. Compare outputs using the same inputs; do not treat a single run as complete validation.
Pin the runtime, dependencies, and model-conversion tool versions. Before upgrading, clone the environment and run regression samples to confirm changes in output and resource usage.
Write progress and results by batch for long-running jobs, resuming from the last confirmed batch after a process exits. Do not treat unpersisted in-memory state as the sole source of progress.
Record peak memory, disk growth, job duration, and failed samples. When the model reaches its hardware resource limit, first adjust batch size or queueing strategy.
Copy first, validate next, and switch last. Keep a local fallback until the cloud node consistently passes build, permission, and artifact checks.
Stage One
Copy project data primarily through your code repository, artifact storage, and encrypted transfer. Exclude caches, temporary build directories, historical logs, and credentials no longer in use.
Stage Two
Record the local Xcode version, command-line tool paths, package-manager lockfiles, environment-variable sources, and build-script entry points, then reproduce them in the cloud.
Stage Three
Start with non-release branches. Confirm scheduling labels, timeouts, logs, and cleanup rules before enabling protected branches and signing-and-archive jobs.
Complete at least one clean build, one failure recovery, one permission check, and one artifact trace-back before making the cloud node your primary execution environment.
HexVM provides dedicated physical nodes and remote access. Your team manages certificate requests, provisioning profiles, keychain permissions, release authorization, and final submission.
Define certificate purposes, protect export passwords, and restrict who can access them.
Import required materials in a controlled session; do not leave the keychain open indefinitely.
Certificate name, validity status, authorized members.
Maintain profiles by app identifier and release environment, and remove expired versions.
Validate the match before building; stop archiving if validation fails.
App identifier, team information, profile version.
Approve protected branches and release jobs, and control build parameters.
Run archiving, export, and integrity checks, producing explicit exit codes.
Commit hash, build number, archive summary.
Review version information, privacy materials, screenshots, and release scope.
Prepare validated artifacts and the upload-tool environment.
Submitter, artifact version, submission result.
Unlock access only during signing and close it immediately when the job ends. Use separate access policies for different projects or environments so test jobs do not inherit release permissions.
Check the app identifier, signing identity, version, build number, and export result. If any field is unexpected, stop the upload instead of manually ignoring the error.
Revoke the Runner registration, remove certificates and provisioning profiles, clean sensitive fields from repository credentials, build directories, and logs, and confirm that required artifacts have been transferred.
Each of the following six items should have a clear owner and acceptance record. Anything that still depends on a verbal agreement can create risk when a build fails, team members change, or a node is released.
Choose a region based on developer location, repository data paths, and artifact upload direction. Available regions are Singapore, Japan (Tokyo), South Korea (Seoul), Hong Kong, US East, and US West—a total of 6 regions.
Run a complete build with a real project first, then choose HexVM M4 or HexVM M4 Pro based on peak memory, disk growth, and concurrency patterns.
Separate node administration, daily development, CI execution, and release permissions. Revoke keys and repository access immediately when a team member leaves or responsibilities change.
Use deployment credentials or Runner authorization with limited scope, granting access only to the repositories required by the job. Scripts must not write tokens, private keys, or full credentials to logs.
Track job queues, success rates, failure causes, disk usage, and execution time. Long-running jobs should save recovery points and support safe retries after build failures.
Track productive build time, queue wait time, idle periods, and cache gains by node. Schedule short-term jobs by day or week, and compare monthly and quarterly cycles for continuous pipelines.
Use a real repository to complete clean and incremental builds, tests, archiving, and artifact uploads. If you need support to troubleshoot, prepare the node ID, region, time of occurrence, reproduction steps, and redacted logs.
Compare the two available models and rental terms, configure the region and add-ons, and place your order. All charges are settled in US dollars (USD); actual availability is returned in real time by the console.