Reusable Build Blueprints

See how cloud Macs fit into your delivery pipeline

These workflows are reference architectures, not customer case studies or unverified performance claims. They separate triggers, tasks on dedicated physical machines, signing responsibilities, log locations, and artifact destinations—so your team can adapt them to its repositories and access model.

Rent a Cloud Mac View the Getting Started Guide
5 workflows For builds, delivery, and experiments
1 dedicated node Runs workloads sequentially through a queue
4 boundaries Code, credentials, logs, and artifacts managed separately
BUILD PASSPORT iOS Release / Main
RUN-042
01
Code commit Repository event triggers a run
Received
02
Dependencies & cache Restored from lockfiles; cache hit recorded
Complete
03
Xcode Archive Archiving on a dedicated physical machine
Running
04
Checks & handoff Verify signing, then export controlled artifacts
Pending
Batch queue MAIN → RELEASE → HOTFIX Each job uses its own working directory
Signing health check Configuration matched The team manages sensitive assets
How to use these examples

Define ownership first, then adapt the automation

These reference architectures describe how tasks flow. Your team remains responsible for repository access, signing assets, developer accounts, release approvals, and artifact retention.

Reproducible environment

Pin Xcode, Command Line Tools, dependency lockfiles, and cleanup commands. To change versions, validate them in a separate working directory before switching the production queue.

Versions & lockfiles

Keep credentials out of repositories

Inject tokens, certificates, and provisioning profiles through controlled channels. Keep only the logs needed to troubleshoot, and scrub paths, tokens, and private repository URLs before sharing output.

Least privilege

Give every artifact a clear destination

Name Archives, export packages, symbol files, and test reports separately, and attach the commit identifier. After handoff, remove temporary copies from the node according to your team’s policy.

Controlled exports
Automated app builds

Five handoff stages, from commit to review-ready artifact

Register a CDNMac M4 as a self-hosted runner, trigger jobs from repository events, and send the resulting artifacts to your team for review or to a downstream distribution system.

01
Code commit Triggered by: developer or merge workflow

A push to the main branch or a release tag starts the queue. The job records the commit hash, branch, trigger, and target scheme without printing sensitive variables to the logs.

Destination: isolated working directory on a dedicated physical machine
02
Restore dependencies Triggered by: run script

Restore Swift packages, CocoaPods, or other dependencies from lockfiles. Cache keys should include at least the lockfile hash and tool versions to prevent stale caches from carrying across versions.

Destination: versioned cache directory and dependency logs
03
Xcode Archive Triggered by: build job

Archive with an explicitly specified workspace, scheme, configuration, and destination. On failure, retain the exit code, key logs, and result bundle.

Destination: Archive directory tagged with the commit identifier
04
Signing checks Triggered by: release job

Check the Bundle Identifier, team, certificate validity, and provisioning profile match. Your team always manages its developer account and signing assets.

Destination: review checklist; never export credentials in plain text
05
Archive artifacts Triggered by: handoff script

Export the installable package, symbol files, build summary, and checksums, then copy them to team-controlled storage. Remove temporary directories after confirming the handoff.

Destination: controlled storage and team review queue
Prepare your first node with the guide
Multi-branch queue

One dedicated physical machine, three branch types queued by policy

Dedicated resources don’t mean every job runs in parallel. On a single CDNMac M4, set clear priorities, working directories, and cleanup boundaries so release jobs don’t interfere with routine validation.

MAIN Continuous validation

Main branch

After a merge, run unit tests, static checks, and a baseline Archive. Reuse caches where appropriate, but isolate DerivedData by project and Xcode version.

Priority
Normal
Working directory
work/main
Cleanup on exit
Remove untracked files
RELEASE Release candidate

Release branch

When a release job enters the queue, pause nonessential jobs for the same repository. Use separate signing checks and export settings, and have the team review the artifact summary.

Priority
High
Working directory
work/release
Cleanup on exit
Delete temporary keychain
HOTFIX Manual approval

Hotfix branch

Add the job to the queue once an owner approves it. Restore only the caches needed to resolve the issue. After the build, clear temporary variables and record a rollback baseline.

Priority
Manual approval
Working directory
work/hotfix
Cleanup on exit
Restore queue and baseline
Queue policy

Release jobs don’t preempt jobs currently writing artifacts. On failure, collect logs before releasing the working directory. Run idempotent cleanup at the end of every job.

MAIN RELEASE HOTFIX CLEAN
FLUTTER IOS

Track cross-platform dependencies separately from Xcode stages

Flutter iOS build time is often split across dependency restoration, CocoaPods, and Xcode. Breaking the workflow into stages helps your team assess cache effectiveness and pinpoint which layer failed.

Stage boundaries

Each stage produces its own logs and exit code. The next stage reads its artifacts only after the previous one succeeds, so dependency issues aren’t mistaken for Xcode compilation failures.

  • Check the Flutter SDK version against project requirements first.
  • Include the lockfile hash in the cache key.
  • Invalidate Pods and Dart caches separately.
  • Hand off export packages and symbol files separately.
01
Restore dependencies

Restore project dependencies and record the SDK version and lockfile hash.

Cache: Dart package directory
02
CocoaPods

Install native iOS dependencies from Podfile.lock. Don’t reuse mismatched Pods.

Logs: CocoaPods installation output
03
Xcode build

Run Archive with an explicitly specified workspace, scheme, and configuration.

Artifacts: Archive and result bundle
04
Export artifacts

After signing checks pass, export the artifacts and generate a commit identifier and checksum summary.

Destination: team-controlled storage

A cache hit means the corresponding directory and key can be reused; it doesn’t guarantee a faster end-to-end build. Revalidate cache boundaries after upgrading Flutter, CocoaPods, Xcode, or lockfiles.

TESTFLIGHT DELIVERY

Team review comes before distribution

The cloud Mac builds and checks artifacts, but it doesn’t replace your team’s release approval process. Your team manages developer accounts, signing assets, version details, and distribution decisions.

  1. 01

    Generate a candidate build

    Archive and export from the release branch, including the commit hash, version, build number, symbol files, and checksum summary.

  2. 02

    Review as a team

    An owner checks the change scope, signing match, privacy details, permission use, and test results. If anything fails review, rebuild from the relevant commit.

  3. 03

    Start distribution

    After approval, a team-controlled release job uses restricted credentials for upload. Don’t store sensitive assets in the repository or ordinary build logs.

  4. 04

    Record the handoff

    Save the artifact identifier, review outcome, and necessary logs. After handoff, remove temporary exports and credentials from the node.

Handled by the CDNMac node Builds, archiving, signing checks, and artifact export
Handled by your team Account management, signing assets, release approval, distribution details, and compliance decisions
APPLE SILICON AI EXPERIMENTS

Test model compatibility without making throughput claims

The CDNMac M4 includes an M4 chip, 16GB RAM, and a 256GB SSD. It’s suited to local model compatibility checks and prototyping. First, confirm that the model, context, data, and memory requirements fit your use case.

A

Prepare your data

Sync only the data subset needed for the experiment, and record its source and version. De-identify sensitive data first, and use separate directories for raw data, intermediate files, and outputs.

Input
Versioned samples
Rollback point
Read-only copy of raw data
B

Validate the runtime environment

Record the macOS, runtime, framework, and model format. Test loading, inference, and memory use on a small sample before expanding the experiment.

Check
Versions & available memory
Rollback point
Pinned dependency list
C

Export results

Include experiment parameters, a results summary, and necessary logs; don’t put sensitive data in full in the report. Copy any results you need to controlled storage before your rental ends.

Output
Parameters, summary, and logs
Boundary
No specific throughput guaranteed
Check your configuration

If the model, context, and intermediate data can’t run reliably within 16GB RAM, or you need a chip or memory configuration not listed, contact the service team first. A successful prototype doesn’t prove production capacity.

Discuss your experiment setup
Team debrief examples

Describe workflow value in verifiable engineering terms

These role-based statements are examples for internal reviews. They aren’t customer testimonials, ratings, or endorsements.

“What matters most to me is whether the queue is exclusive to our team and whether failures leave logs we can use to find the cause. Clearly documenting working directories and artifact destinations is more useful than making vague claims about build speed.”

Mobile engineering lead

“When branch jobs share one physical machine, the real design decisions are priorities, cache keys, and cleanup policies. Dedicated resources give us a baseline for isolation, but we still define the pipeline ourselves.”

CI platform engineer

“When connecting across time zones, I want remote access, background builds, and artifact exports to work independently. That way, a brief network interruption on my end won’t affect a running build.”

Independent developer
Copy the workflow

Requirements, environment variables, and rollback points

Before adapting a workflow, build the smallest version that runs end to end. You can rename environment variables to match your team’s conventions, but never commit sensitive values or print them directly to build logs.

Implementation checklist for five reference workflows
Workflow Requirements Environment variables Rollback point
Automated app builds Repository access, Xcode version, scheme, dependency lockfiles, export settings REPO_REF
BUILD_SCHEME
EXPORT_PATH		 Keep the result bundle and commit identifier, delete the temporary keychain, and return to the last buildable commit
Multi-branch builds Branch priorities, separate working directories, concurrency limits, idempotent cleanup script BRANCH_NAME
RUN_PRIORITY
WORK_ROOT		 Stop the remaining queue, save current logs, restore a clean working tree and the original queue order
Flutter iOS Flutter version, Podfile.lock, Xcode workspace, cache key policy FLUTTER_ROOT
PODS_CACHE_KEY
IOS_SCHEME		 Invalidate caches by stage, keep reusable logs, and resume from the last successful stage
TestFlight delivery Release approval, version details, signing match, artifact validation, team-controlled credentials RELEASE_VERSION
BUILD_NUMBER
ARTIFACT_PATH		 Stop the distribution job, revoke temporary credentials, return to the review checklist, and generate a new candidate build
AI experiments Model format, small sample dataset, runtime version, memory monitoring, export directory MODEL_PATH
DATASET_PATH
RESULT_PATH		 Keep the parameter list and results summary, restore pinned dependencies, and return to the read-only copy of raw data
01 Start with a minimal job

Use one repository, one scheme, and one output destination to confirm the node can complete the full workflow.

02 Then add sensitive variables

Inject least-privilege credentials through a controlled channel, then verify log redaction, expiration, and rotation.

03 Expand the queue last

Before adding branches, set priorities, timeouts, failure recovery, and working-directory cleanup rules.

Open the Getting Started Guide View build troubleshooting support

Run the reference workflow on a dedicated cloud Mac

Choose a rental term and node, then follow the guide to verify connectivity, the Xcode environment, repository access, and your first Archive. Check the console for the latest availability and delivery details.

Rent Now View Plans